В реакт компонентный подход, это не шаблонизация в том виде, как ее принято понимать, это замена шаблонизации. А уж тем более, на сервере шаблонизация обычно не нужна, между клиентом и сервером можно гонять JSON данные и их визуализировать на клиенте или при помощи клиентского шаблонизатора или байндингом или компонентами, я рекомендую для этого React. Сейчас подгоню ссылок, погодите малость.
В первую очередь Express.js и angular.js, ну Jade еще может быть где-то полезен, но серверная шаблонизация нужна пару раз в жизни, иначе разве это жизнь...
Знаю, это распространено, но я решительно не вижу смысла в связке nginx+Node.js потому, что для продакшена лучше всю статику выносить на CDN, а для разработки проще отдавать статику прямо из ноды. Зачем тогда nginx? Правильно, на nginx нужно подымать CDN-ы и еще для терминации SSL разве что, но в общем случае, терминация SSL тоже может быть в хостинге as a service, т.е. мы вообще не паримся, ни статикой, ни шифрованием.
Тут все зависит от того, какие Вы сравниваете файлы, если это конфиги в форматах JSON, INI, XML или еще какие текстовые форматы, парсеры для которых есть, то это одно дело, а если файлы двоичные, то совсем другое. Если формат фалов не сложный, то Вы их отпарсите и сравните строковыми операциями на JS, и это может быть эффективнее, чем делать diff, потому, что вывод diff Вам тоже нужно будет парсить.
Нынче СУБД уже хранят JSON не в виде текста или BLOB, теперь они умеют их хранить в виде распарсанных объектов, строить по ним индексы и использовать в запросах, в общем, работать с полями JSON, так же, а то и лучше, чем можно манипулировать с ними в MongoDB. Вот тут про JSONB посмотрите www.postgresql.org/docs/9.4/static/datatype-json.html
CREATE TABLE CART(ID INT, ITEM_TYPE INT, DATA JSONB);
CREATE INDEX IDX_LINK_URL ON CART USING gin ((DATA -> 'url'));
Тогда рекомендую перекомпилировать под линукс, для C/C++ и C# это возможно, если нет зависимостей от каких-то сторонних DLL, которые перенести на линукс нельзя, но вообще гораздо лучше взять исходник и переписать на JS или C/C++ и обернуть для вызовов из Node.js. Тут вот написано как оборачивать https://nodejs.org/api/addons.html
В общем, нужно разобраться с принципом колбеков сначала и потом с принципом асинхронности. Вкратце: колбек - это функция, которая передается параметром в другую функцию и будет вызвана 1 раз из нее, когда будет готов результат. Есть негласное соглашение, что к колбека первый параметр это ошибка или null (если все удачно), а второй параметр - это результат (случается, что результатов несколько, тогда их или группируют в объект или просто у колбека становится больше двух параметров, четких правил тут нет). Колбек нужно вызвать 1 и только 1 раз. Вызывать его больше - это уже не колбек, а некий аналог события. Теперь про асинхронность, нужно понимать, что это просто способ возврата результата не через значение функции, а через колбек, что приводит к созданию цепочек вызовов и даже к ветвлению вызовов. Для упрощения и управления последовательностью операций, а глевное - для создания удобных синтаксических структур в коде - есть много путей, один и них - использование async.js. Его доку можно и нужно прочитать полностью, она вполне вменяемама и лежит на одной странице прямо с примерами https://github.com/caolan/async Еще полезно пройти соответствующий раздел nodeschool.io
Я не работаю с Ц9, мне там неудобно. Какой файл смотреть - не ясно, в index.js там не во всех случаях вызываются колбеки из функций внутри async.parallel, проследите, чтобы в лббом случае был вызван колбек.
UPD прочитал, но понятнее не стало, мы запускаем много функций, которые параллельно что-то добывают, конечно они не сами добывают, а вызывают разные асинхронные API, передавая по эстафете им колбеки, и когда все вызовы вернут значения, то вызывается наконец и завершающая функция, что нужно если не это?
А, это нужно сделать вложенный async.parallel. Наружный запускает две функции, каждая обращается к одному API, но обращений несколько, когда заказчиваются вложенные распараллеленные обращения, то две ветки сливаются во внешней parallel.
fr33zy, согласен, или async.each но уж точно, что eventEmitter тут ни при чем. Daniel Newman, опишите задачу в общем, без своей реализации, возможно, ее нужно решать вообще иначе.
1. Я вот не в курсе, будут ли лететь ошибки, если отправлять на неактуальные ID, но как минимум это будет плохо для производительности, отправляться то оно будет пробовать, если не узнает, что клиент отпал.
2. Можно массив, но этот массив лучше хранить в памяти нодовского процесса.
3. Если он обеспечивает такую доставку, то наверняка у него есть и список ID, иначе как бы он мог находить нужные сокеты по ID. К сожалению с адаптером не знаком. Советую посмотреть его исходники или поискать именно в адаптере документацию как он хранит в памяти с своих структурах данных эти таблицы ID. Он явно должен хранить их в памяти ноды, а редис использовать для трансляции сообщений, как mq.
1. Node.js с Express habrahabr.ru/post/243945 и мой расширенный комментарий habrahabr.ru/post/243945/#comment_8141311
2. Angular habrahabr.ru/post/246905
Где покапаться в поисках альтернативы:
1. nodeframework.com
2. https://github.com/sindresorhus/awesome-nodejs и https://github.com/vndmtrx/awesome-nodejs
3. Подсоветуйте фреймворк для node?
4. Есть какие-нибудь ресурсы по построению правильной серверной архитектуры на node.js/io.js?