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

Развертывание - дело десятое, осваивайте 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, иногда больше. В каждом модуле, конечно у вас будут как минимум: внешний интерфейс (содержащий внешние вызовы и спецификации форматов данных для обмена), внутренняя логика и внутренние структуры данных. Задача архитектора сделать так, чтобы интерфейс модуля экранировал внутренние структуры данных и внутреннюю логику от зависимостей. При этом, делить приложение на сотни процессов не обязательно, даже внутри одного процесса вы можете связать компоненты по принципу микросервисов, посадив их на шину событий, это будет называться модель акторов.

Архитектурные принципы не очень связаны именно с нодой, они будут примерно одинаковыми, на каком бы языке вы не писали. Первое, что я могу посоветовать, когда Вы переходите от технологий программирования к архитектуре систем, это как переход от кладки кирпича к архитектуре зданий - нужно отложить все шаблоны, которые Вы знали до того и подняться на другой уровень абстракции. А именно, нужно перестать мыслить такими понятиями, как DI (dependency injection), REST, MVC, ORM, RPC, шаблонизаторы, компоненты, сокеты, промисы и прочее - это все технологии. Что же нужно понять это: слои (layers), модули, контракты, адаптеры, клиент-сервер, 3-звенная архитектура, микросервисы, СМО (системы массового обслуживания), и т.д. Где так все собрано в одном месте - не могу сказать, я лично по крупицам все осваивал, на что положил 20 лет профессиональной деятельности. Почитайте про ISO/OSI, загляните в три мои статьи habrahabr.ru/post/227753 и habrahabr.ru/post/204958 и habrahabr.ru/post/117791 Раньше хорошие статьи по архитектуре были на www.osp.ru но, к сожалению, давно не читал его. Можно начать с книг Гради Буча и освоения UML, этот дядька сформировал достаточно полный подход и методологию проектирования программных систем, которая ведет правильным путем, но на практике, в каждом отдельном случае может быть заменена интуицией архитектора и существенно упрощена. Удачи!

https://github.com/caolan/async

async.series({
  one: function(callback) {
    setTimeout(function() {
      callback(null, 1);
    }, 200);
  },
  two: function(callback) {
    setTimeout(function() {
      callback(null, 2);
    }, 100);
  }
},
function(err, results) {
  // results is now equal to: { one: 1, two: 2 }
});

С node.js все наоборот, у него веб-сервер "внутри" приложений, а не приложения "внутри" веб-сервера. Каждое приложение само и является веб-сервером. Чтобы сделать виртуалхосты, хостить много сайтов, обрабатывать много доменов, нужно запустить много экземпляров ноды и связать весь этот зоопарк в один пучок через nginx. Если каждое приложение предполагает приличную нагрузку, то нужно каждое распараллеливать при помощи cluster и потом эти кластеры уже объединять через nginx. В результате, если у Вас будет 20 сайтов на машине, то это минимум 20 процессов ноды, а то и все 100. Есть альтернативное решение - сервер приложений, который перевлрачивает мир обратно с головы на ноги, т.е. на модель "внутри" сервера приложений много приложений: habrahabr.ru/post/247543