Тимур Шемсединов

UPD: поможет флаг в cookie или localstorage, например: localStorage.lastResult = "error";

Рядом с complete в вызове $.ajax добавьте еще error: function() {} или error: functionName если она уже где-то была определена.

По той ссылке, что Вы дали и лежит решение, т.к. на венике могут встречаться файлы и каталоги с разными правами доступа, то нужно выделять из общего потока ошибок EPERM и игнорировать их. Полное игнорирование ошибок: finder.on('error', function (err) {}); Если глушить только EPERM то наверно так:

finder.on('error', function (err) {
    if (err.code !== 'EPERM') finder.stop();
});

Посмотрите вот этот мой развернутый ответ: Подсоветуйте фреймворк для node?
Инструментов можно набрать тут: nodeframework.com и тут https://github.com/sindresorhus/awesome-nodejs и тут https://github.com/vndmtrx/awesome-nodejs

По БД рекомендую MongoDB, если у Вас данные аморфные, сложной или часто изменяющейся структуры с этими драйверами: https://www.npmjs.com/package/mongodb А если данные имеют редко меняющующуюся структуру и хорошо ложатся в таблицы, то берите реляционку, лучше PostgreSQL, с драйверами: https://www.npmjs.com/package/pg Но я не люблю и не рекомендую ORM, обычно от них больше проблем, тормозов и дополнительной работы больше, чем выгоды от их внедрения. Если уж приспичит, то для монги есть mongoose: mongoosejs.com это ODM, аналог ORM для документных баз, а для PG есть много вариантов, которые основаны на том же драйвере pg.

Паттерн MVC он вообще изначально был изобретен для графических интерфейсов пользователя, и там он еще как-то себя оправдывает, да и то кривенько, почитайте эти мои статьи: habrahabr.ru/post/204958 и habrahabr.ru/post/117791 Для ноды это вообще противоестественно. GUI и бекенд должны быть разделены сетевым API, на которое вешаются что мобильные приложения, что браузерные, что оконные, это уже без разницы.

Сравнение не совсем корректное. Если Вы пишете серверную сторону на JavaScript под Node.js, то используете встроенный http сервер (express это надстройка над встроенным сервером, мало имеющая отнощения к веб-серверу вообще), а если пишете на PHP или другом языке, работающим через CGI с Apache, то используете Apache.

Развертывание - дело десятое, осваивайте JavaScript, если с этим все в порядке, то посмотрите видеоуроки и беритесь за Node.js API, а потом пройдите лабораторки на nodeschool. Параллельно нужно собрать все свои знания в стек технологий, на одной ноде Вы напишете только сервер, а на клиенте что? Нынче времена такие, что одного jQuery уже не хватит, посмотрите React, вот тут серия статей: habrahabr.ru/post/229655 и подберите СУБД для своих нужд, например, рекомендую MongoDB, если у Вас данные аморфные, сложной или часто изменяющейся структуры. Рекомендую PostgreSQL, если данные имеют четкую, редко меняющуюся структуру и хорошо ложатся в таблицы. Все это прекрасно ставится на локальной машине, но если у Вас виндовс, то рекомендую завести виртуалку с CentOS или другим линуксом.

Когда Вы делаете MongoClient.connect с использованием драйвера mongodb то создается пул соединенний с базой, они открываются и закрываются по мере необходимости, так что, не волнуйтесь и используйте одно соединение с БД для всех запросов к БД. И если у Вас платформа для игр, то храните все в одной БД, потом будет проще бекапить и восстанавливать, а если хорошо подумать, то и какая-то обобщенная структура со временем наметится.

А стрим тут и не нужен, делайте fs.readFile, потом ставьте fs.watch и при изменении fs.readFile в другую переменную и сравнивайте, только нужно создать еще очередь сравниваний, потому, что файл может меняться чаще, чем закончится предыдущее сравнивание (но это чисто теоретически, если по специфике задачи известно, что он меняется с малой периодичностью, то это можно и опустить). Результат fs.readFile это объект Buffer, для сравнения двух буферов, скорее всего, если они содержат текст их можно перегнать в строки .toString() и парсить. А вот понять, идентичны ли буферы, можно при помощи Buffer.compare(buf1, buf2).

Часто применяется для:

1. Локальные приложения и утилиты командной строки

• Сборщики и трансляторы
  
• Пакетная обработка и сценарии отложенной обработки
  
• Скрипты, CLI (интерфейсы командной строки)
  
• Генерация документации, отложенное формирование отчетов
  
• Сценарии тестирования для других систем
  

2. Серверы

• Серверы веб-приложений и SPA
  
• Серверы и API для мобильных приложений
  
• Любые другие веб-API (RPC, JSON, REST)
  
• Серверы сообщений и трансляция событий (чаты, игры, интерактив)
  
• Заплаты на уже готовые системы, написанные на других языках, для реализации вебсокетов, SSE, лонг-пулинга и т.д., т.е. для затыкания дыр, для решения проблем в узких местах уже работающих систем.
  

3. Клиенты

• Оконные приложения (nw.js, node-webkit)
  
• Кравлеры, парсеры и сбор данных
  

4. Железо

• Программирование микроконтроллеров (arduino, espruino, tessel)
  
• Промышленная автоматизация
  

Редко применяется (но подходит) для:

• CMS, публикация контента (просто ниша уже занята и в этой задаче нода не дает чего-то принципиально нового или сверх соблазнительного).
  
• Массовая электронная коммерция и торговля (не применяется для массовых движков магазинов, но используется отдельными крупными компаниями для торговых и платежных задач в качестве дополнительного средства к уже имеющемуся ПО, по сути закрывает узкие места).
  

И плохо подходит:

• Вычисления и моделирование, со скоростью математических операций нода и JS, как не типизированный язык, не дают хороших показателей
  
• Научные приложения (по тем же причинам)
  

Азур - это право очень странный выбор для ноды, почему бы не Digital Ocean, OVH или Hetzner? Берегитесь майкрософта, сначала Вы подсядите на один их сервис для хранения файлов, потом на смежный, потом еще один и так постепенно приложение растворится в азуре и перенос еще куда-то будет не возможен. Я не рекомендую использовать их как хостинг, а если это уже решено, то хранение файлов оставьте как оно и было сделано, просто в файловой системе, так можно будет потом проще передвинуться куда захотите, между компами настройте NFS.

Я бы не противопоставлял монолитные приложения и микросервисы. На самом деле чем лучше приложение разделено на части, тем лучше оно централизовано. Приведу сначала пример житейский, если каждый сотрудник автономно выполняет порученную ему работу хорошо и качественно, то сокращается взаимодействие между сотрудниками, уменьшаются расходы времени на контроль и переделывание работы, при этом монолитность иерархических структур упрочняется чем более автономен каждый сотрудник в организации. Что же противопоставить, что же плохо? Плохо - смешивать уровни абстракции, в ноде распространено смешивать все в кучу, я приводил пример тут: habrahabr.ru/post/247543 цитирую:

Прикладной код часто смешан с системным. Дело в том, что нода, и большинство производных фреймворков, слишком низкоуровневые и каждое приложение обязательно содержит часть системного кода, не относящегося к задачам предметной области. Вот и случается, например, что добавление HTTP заголовка становится методом класса Patient и находится в одном файле с заданием роутинга URLов к сему пациенту и с отправкой событий через веб-сокеты. Это чудовищно.

Монолит - это не плохо. Плохо, когда смешаны слои абстракции, если это не понимать, то микросервисы ничего не дадут. Это приводит к высокой связанности кода, когда каждый фрагмент зависит от множества других. Внутри каждого микросервиса можно сделать полное месиво абстракций. Лучше планировать архитектуру слоями, ниже - слои системные, выше - прикладные. Иногда их нужно 2, иногда 3, иногда больше. В каждом модуле, конечно у вас будут как минимум: внешний интерфейс (содержащий внешние вызовы и спецификации форматов данных для обмена), внутренняя логика и внутренние структуры данных. Задача архитектора сделать так, чтобы интерфейс модуля экранировал внутренние структуры данных и внутреннюю логику от зависимостей. При этом, делить приложение на сотни процессов не обязательно, даже внутри одного процесса вы можете связать компоненты по принципу микросервисов, посадив их на шину событий, это будет называться модель акторов.