Как решить, когда использовать Node.js?

Я полагаю, что Node.js лучше всего подходит для приложений реального времени: онлайн-игры, инструменты для совместной работы, чаты или что-нибудь, где какой-то один пользователь (или робот или датчик?) делает это приложение необходимо увидеть другими пользователями немедленно, без обновления страницы.

Я также должен отметить, что Socket.IO в сочетании с Node.js уменьшит вашу задержку в реальном времени даже дальше, чем то, что возможно при длительном опросе. Socket.IO вернется к длинному опросу как к худшему сценарию и вместо этого использует веб-сокеты или даже Flash, если они доступны.

Но я должен также упомянуть, что практически любая ситуация, когда код может блокироваться из-за потоков, может быть лучше адресован с помощью Node.js. Или любая ситуация, когда вам нужно, чтобы приложение управлялось событиями.

Кроме того, Райан Дал сказал в разговоре, что я когда-то присутствовал, что тесты Node.js тесно конкурируют с Nginx за обычные старые HTTP-запросы. Поэтому, если мы построим с помощью Node.js, мы можем эффективно обслуживать наши обычные ресурсы, и когда нам нужны вещи, управляемые событиями, он готов к обработке.

Плюс все это JavaScript все время. Лингва Франка на весь стек.

Причины использования NodeJS:

• Он запускает Javascript, поэтому вы можете использовать тот же язык на сервере и клиенте и даже совместно использовать некоторый код между ними (например, для проверки формы или для визуализации представлений с обоих концов. )

• однопоточная управляемая событиями система fast даже при обработке множества запросов одновременно, а также просто, по сравнению с традиционными многопоточными Java или ROR.

• Постоянно растущий пул пакетов, доступных через NPM, включая клиентскую и серверную библиотеки/модули, а также инструменты командной строки для веб-разработки. Большинство из них удобно размещаются на github, где иногда вы можете сообщить о проблеме и найти ее исправленной в течение нескольких часов! Приятно иметь все под одной крышей, стандартизованную отчетность о проблемах и легкую разметку.

• Он стал стандартной средой defacto, в которой можно запускать инструменты, связанные с Javascript и другие веб-инструменты, включая задачи, minifiers, декодеры, литеры, препроцессоры, коммутаторы и аналитические процессоры.

• Он кажется вполне подходящим для прототипирования, гибкого развития и быстрой итерации продукта.

Причины не использовать NodeJS:

• Он запускает Javascript, который не имеет проверки типа компиляции. Для больших, сложных безопасных систем или проектов, включая сотрудничество между различными организациями, язык, который поощряет контрактные интерфейсы и обеспечивает проверку статического типа сэкономьте некоторое время отладки (и взрывы) в долгосрочной перспективе. (Хотя JVM застрял с null, поэтому, пожалуйста, используйте Haskell для ваших ядерных реакторов.)

• Кроме того, многие из пакетов в NPM немного raw и все еще находятся в стадии быстрого развития. Некоторые библиотеки для старых фреймворков прошли десятилетие тестирования и исправления ошибок, и теперь они очень стабильны. Npmjs.org не имеет механизма для тарификации пакетов, что привело к распространению пакетов, делающих более или менее одно и то же, из которых большой процент больше не поддерживается.

• Вложенный обратный ад. (Конечно, есть 20 различных решений для этого...)

• Постоянно растущий пул пакетов может привести к тому, что один проект NodeJS станет радикально отличающимся от следующего. Существует большое разнообразие в реализации из-за огромного количества доступных опций (например, Express/Sails.js/Meteor/Derby). Иногда это может затруднить переход нового разработчика на проект Node. Сравните это с тем, что разработчик Rails присоединяется к существующему проекту: он должен иметь возможность быстро ознакомиться с приложением, потому что всем приложениям Rails рекомендуется использовать аналогичную структуру.

• Работа с файлами может быть немного болью. Вещи, которые тривиальны в других языках, например, чтение строки из текстового файла, достаточно странны, чтобы сделать с Node.js, что есть вопрос StackOverflow, связанный с 80+ upvotes. Там нет простого способа чтения одной записи за раз из файла CSV. Etc.

Я люблю NodeJS, это быстро и дико и весело, но я обеспокоен тем, что он мало интересуется доказуемо-правильной. Позвольте надеяться, что мы сможем в конечном итоге объединить лучшее из обоих миров. Я очень хочу посмотреть, что заменит Node в будущем...:)

Чтобы сделать это коротко:

Node.js хорошо подходит для приложений с большим количеством параллельных подключений, и каждому запросу требуется очень мало циклов ЦП, поскольку цикл событий (со всеми остальными клиентами) блокируется во время выполнения функции.

Хорошая статья о цикле событий в Node.js Блог Mixu tech: Понимание цикла событий Node.js.

У меня есть один реальный пример, где я использовал Node.js. Компания, в которой я работаю, получила одного клиента, который хотел иметь простой статический HTML-сайт. Этот сайт предназначен для продажи одного элемента с помощью PayPal, и клиент также хотел иметь счетчик, который показывает количество проданных предметов. Ожидается, что клиент посетит этот сайт с огромным количеством посетителей. Я решил сделать счетчик, используя Node.js и Express.js framework.

Приложение Node.js было простым. Получите сумму проданных предметов из базы данных Redis, увеличивайте счетчик, когда товар продан, и обслуживайте значение счетчика для пользователей через API.

Некоторые причины, по которым я решил использовать Node.js в этом случае

• Он очень легкий и быстрый. На этом веб-сайте прошло более 200 000 посещений за три недели, и минимальные серверные ресурсы смогли обработать все это.
• Счетчик действительно легко сделать в реальном времени.
• Node.js легко настроить.
• Существует множество модулей, доступных бесплатно. Например, я нашел модуль Node.js для PayPal.

В этом случае Node.js был удивительным выбором.

Наиболее важные причины для запуска следующего проекта с помощью Node...

• В него входят все самые крутые парни... так что это должно быть весело.
• Вы можете подключиться к кулеру и иметь множество приключений Node, чтобы похвастаться.
• Вы - пенни, когда дело доходит до расходов на облачный хостинг.
• Там было сделано с Rails
• Вы ненавидите развертывание IIS
• Ваша старая ИТ-работа становится довольно скучной, и вы хотите, чтобы вы были в блестящем новом старте.

Чего ожидать...

• Вы будете чувствовать себя в безопасности и безопасностью с помощью Express без всякого вируса, который вам никогда не нужен.
• Работает как ракета и хорошо масштабируется.
• Вам это снилось. Вы его установили. Пакет Node repo npmjs.org является самой большой экосистемой библиотек с открытым исходным кодом в мире.
• Ваш мозг получит время, искаженное в земле вложенных обратных вызовов...
• ... пока вы не научитесь сохранять Promises.
• Sequelize и Passport - это ваши новых друзей API.
• Отладка в основном асинхронного кода будет интересна.
• Время для всех узлов, чтобы овладеть Typescript.

Кто его использует?

• PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones.
• Вот почему они переключаются на Node.

Нет ничего похожего на Silver Bullet. Все связано с некоторыми издержками, связанными с этим. Это похоже на то, что вы едите жирную пищу, вы станете компрометировать свое здоровье, а здоровая пища не придет со специями, такими как жирная пища. Это индивидуальный выбор: хотят ли они здоровья или специй, как в своей пище. Точно так же Node.js считается используемым в конкретном сценарии. Если ваше приложение не вписывается в этот сценарий, вы не должны рассматривать его для разработки вашего приложения. Я просто задумываюсь о том же:

Когда использовать Node.JS

• Если ваш код на стороне сервера требует очень мало циклов процессора. В другом мире вы выполняете неблокирующую операцию и не имеете тяжелого алгоритма /Job, который потребляет много циклов процессора.
• Если вы работаете на Javascript и можете писать в формате Single Threaded, как на стороне клиента JS.

Если НЕ использовать Node.JS

• Ваш запрос сервера зависит от интенсивного алгоритма использования процессора /Job.

Рассмотрение масштабируемости с помощью Node.JS

• Node.JS сам по себе не использует все ядро ​​базовой системы и по умолчанию однопоточен, вам приходится писать логику самостоятельно, чтобы использовать многоядерный процессор и сделать его многопоточным.

Node.JS Альтернативы

Есть и другая возможность использовать вместо Node.JS, однако Vert.x кажется довольно многообещающим и имеет множество дополнительных функций, таких как полигот и лучше соображения масштабируемости.

Еще одна замечательная вещь, о которой я думаю, никто не упомянул о Node.js - это удивительное сообщество, система управления пакетами (npm) и количество существующих модулей, которые вы можете включить, просто включив их в свой пакет. json файл.

Моя часть: nodejs отлично подходит для создания систем реального времени, таких как аналитика, чат-приложения, apis, рекламные серверы и т.д. Черт, я сделал свое первое приложение для чата, используя nodejs и socket.io менее 2 часов, и это тоже во время экзамена неделя!

Edit

Прошло несколько лет с тех пор, как я начал использовать nodejs, и я использовал его для создания множества разных вещей, включая статические файловые серверы, простые аналитики, чат-приложения и многое другое. Это мое занятие, когда использовать nodejs

Когда использовать

При создании системы, которая делает акцент на concurrency и скорости.

• Сокеты только для серверов, таких как чат-приложения, приложения irc и т.д.
• Социальные сети, которые делают акцент на ресурсах реального времени, таких как геолокация, видеопоток, аудиопоток и т.д.
• Работа с небольшими кусками данных очень быстро, как в web-аналитике analytics.
• Как выставлять только REST только api.

Если не использовать

Это очень универсальный веб-сервер, поэтому вы можете использовать его везде, где хотите, но, вероятно, не в этих местах.

• Простые блоги и статические сайты.
• Как статический файловый сервер.

Имейте в виду, что я просто придираюсь. Для статических файловых серверов apache лучше в основном потому, что он широко доступен. На протяжении многих лет сообщество nodejs становилось все более и более зрелым, и можно с уверенностью сказать, что nodejs можно использовать практически везде, если у вас есть собственный выбор хостинга.

Его можно использовать там, где

• Приложения, которые сильно управляются событиями и сильно связаны с I/O
• Приложения, обрабатывающие большое количество подключений к другим системам
• Приложения реального времени (Node.js были разработаны с нуля в реальном времени и легки для использования.)
• Приложения, которые жонглируют блоками передачи информации в другие источники и из других источников.
• Высокий трафик, масштабируемые приложения
• Мобильные приложения, которым приходится разговаривать с API платформы и базой данных, без необходимости делать много данных аналитика
• Создание сетевых приложений
• Приложения, которые очень часто нужно разговаривать с задним концом

На мобильном фронте компании, работающие в прайм-тайм, полагаются на Node.js для своих мобильных решений. Проверьте, почему?

LinkedIn является выдающимся пользователем. Весь их мобильный стек построен на Node.js. Они перешли от 15 серверов с 15 экземплярами на каждой физической машине, всего к 4 экземплярам, ​​которые могут обрабатывать двойной трафик!

eBay запустил ql.io, язык веб-запросов для API HTTP, который использует Node.js в качестве стека времени выполнения. Они смогли настроить обычную рабочую станцию ​​Ubuntu на уровне разработчика, чтобы обрабатывать более 120 000 активных подключений в процессе Node.js, причем каждое соединение потребляет около 2 КБ памяти!

Walmart переработал свое мобильное приложение, чтобы использовать Node.js и переместил свою обработку JavaScript на сервер.

Подробнее: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

Node лучше всего подходит для одновременной обработки запросов -

Итак, Давайте начнем с истории. За последние 2 года я работаю над JavaScript и разрабатываю веб-интерфейс, и мне это нравится. Back end ребята предоставляют нам некоторые API, написанные на Java, python (мы не заботимся), и мы просто пишем вызов AJAX, получаем наши данные и угадываем, что! мы сделали. Но на самом деле это не так просто. Если данные, которые мы получаем, неверны или есть некоторая ошибка сервера, то мы застреваем, и мы должны связаться с нашими задними парнями по почте или чату (иногда на whatsApp тоже:)). не круто. Что делать, если мы написали наши API-интерфейсы в JavaScript и назвали эти API из нашего интерфейса? Да, это довольно круто, потому что, если мы сталкиваемся с какой-либо проблемой в API, мы можем изучить ее. Угадай, что! вы можете сделать это сейчас, как? - Node для вас.

Хорошо согласился, что вы можете написать свой API в JavaScript, но что, если я в порядке с проблемой выше. У вас есть другая причина использовать Node для API для отдыха?

так вот начинается волшебство. Да, у меня есть другие причины использовать Node для наших API.

Давайте вернемся к нашей традиционной системе API для отдыха, которая основана либо на операции блокировки, либо на потоке. Предположим, что существует два параллельных запроса (r1 и r2), для каждого из которых требуется операция с базой данных. Итак, в традиционной системе произойдет что-то:

1. Waiting Way: Наш сервер начинает обслуживать запрос r1 и ждет ответа на запрос. после завершения r1 сервер начинает обслуживать r2 и делает это таким же образом. Поэтому ожидание - это не очень хорошая идея, потому что у нас не так много времени.

2. Threading Way: Наш сервер создаст два потока для обоих запросов r1 и r2 и будет служить своей цели после запроса базы данных, так что охладите его быстро. Но это потребляет память, потому что вы можете видеть, что мы начали два потока также проблемы увеличивается, когда оба запроса запрашивают одни и те же данные, тогда вам приходится иметь дело с проблемами взаимоблокировки. Так что лучше, чем ждать, но все еще есть проблемы.

Теперь вот, как это сделает Node:

3. Nodeway: Когда такой же параллельный запрос приходит в Node, тогда он регистрирует событие с его обратным вызовом и продвигается вперед, он не будет ждать ответа на запрос для конкретного запроса. Поэтому, когда приходит запрос r1, тогда node (да, для этой цели существует цикл событий в Node.) зарегистрируйте событие с его функцией обратного вызова и продвигайтесь вперед для обслуживания запроса r2 и аналогичным образом зарегистрируйте его событие с его обратным вызовом. Всякий раз, когда какой-либо запрос завершается, он запускает соответствующее событие и выполняет его обратный вызов до завершения без прерывания.

Так что не ожидайте, нет потоков, нет потребления памяти - да, это нодвей для обслуживания API обслуживания.

Моя еще одна причина - выбрать Node.js для нового проекта:

Уметь создавать чистые облачные разработки

Я использовал Cloud9 IDE некоторое время, и теперь я не могу представить без него, он охватывает все жизненные циклы разработки. Все, что вам нужно, это браузер, и вы можете его кодировать в любое время в любом месте на любых устройствах. Вам не нужно проверять код на одном компьютере (например, дома), затем выходить на другой компьютер (например, на рабочем месте).

Конечно, там может быть облачная среда IDE для других языков или платформ (Cloud 9 IDE добавляет поддержку и для других языков), но использование Cloud 9 для разработки Node.js - отличный опыт для меня.

Нанесение асбеста longjohns...

Вчера мой заголовок с публикациями Packt, Реактивное программирование с помощью JavaScript. Это не действительно Node.js-centric title; ранние главы предназначены для того, чтобы охватить теорию, а более поздние главы, посвященные коду, охватывают практику. Поскольку я действительно не думал, что было бы уместно не давать читателям веб-сервер, Node.js казался безусловно очевидным выбором. Дело было закрыто до того, как оно было даже открыто.

Я мог бы рассказать о своем опыте работы с Node.js. Вместо этого я был честен о хороших моментах и ​​плохих моментах, которые я встречал.

Позвольте мне включить несколько цитат, которые здесь важны:

Предупреждение: Node.js и его экосистема горячо горячая, чтобы сжечь вас плохо!

Когда я был помощником учителя в математике, одним из неочевидных предложений, которые мне сказали, было не говорить студенту, что что-то было "легко". Причина была несколько очевидной в ретроспективе: если вы говорите людям, что что-то легко, кто-то, кто не видит решения, может в конечном итоге чувствовать (даже больше) глупость, потому что не только они не могут решить, как решить проблему, но проблема в том, что они слишком глупо, чтобы понять, это легко!

Есть gotchas, которые не просто раздражают людей из Python/Django, которые немедленно перезагружают источник, если вы что-то меняете. С Node.js поведение по умолчанию заключается в том, что если вы делаете одно изменение, старая версия продолжает действовать до конца или до тех пор, пока вы не остановите и не перезапустите сервер вручную. Это неуместное поведение не просто раздражает Pythonistas; он также раздражает пользователей Node.js, которые предоставляют различные обходные пути. В вопросе StackOverflow "Автозагрузка файлов в Node.js" на момент написания этой статьи было более 200 upvotes и 19 ответов; редактирование направляет пользователя к няне script, node -supervisor, с домашней страницей в http://tinyurl.com/reactjs-node-supervisor. Эта проблема дает новым пользователям отличную возможность чувствовать себя глупо, потому что они думали, что они исправили проблему, но старое, плохое поведение полностью не изменилось. И легко забыть отказываться от сервера; Я делал это несколько раз. И сообщение, которое я хотел бы дать, это "Нет, вы не глупы, потому что это поведение Node.js укусил вашу спину, а именно, что дизайнеры Node.js не видели причин для обеспечения соответствующего поведения здесь. попытайтесь справиться с этим, возможно, немного помогите от node -supervisor или другого решения, но, пожалуйста, не уходите, чувствуя, что вы глупы. Вы не тот, у кого проблема, проблема в Node.jss поведение по умолчанию."

Этот раздел, после некоторых дебатов, остался, именно потому, что я не хочу создавать впечатление "Легко". Я много раз режу руки, пытаясь заставить работать, и я не хочу сглаживать трудности и заставляю вас думать, что получение Node.js и его экосистемы для работы хорошо - дело простое, и если это не просто для вас тоже, вы не знаете, что вы делаете. Если вы не сталкиваетесь с неприятными трудностями, используя Node.js, это замечательно. Если вы это сделаете, я надеюсь, что вы не уйдете от чувства: "Я глуп - должно быть, со мной что-то не так". Вы не глупы, если испытываете неприятные сюрпризы, связанные с Node.js. Это не ты! Его Node.js и его экосистема!

Приложение, которое я действительно не желал после восходящего крещендо в последних главах и заключении, рассказывает о том, что я смог найти в экосистеме, и предоставил обходное решение для идиотского буквализма:

Другая база данных, которая казалась идеально подходящей и еще может быть выкуплена, представляет собой серверную реализацию хранилища ключей ключей HTML5. Этот подход обладает кардинальным преимуществом API, который хорошо понимают самые хорошие разработчики front-end. В этом отношении, это также API, который большинство не очень хороших разработчиков интерфейса понимают достаточно хорошо. Но с пакетом node -localstorage, в то время как доступ к словарю-синтаксису не предлагается (вы хотите использовать localStorage.setItem(ключ, значение) или localStorage.getItem(ключ), а не localStorage [key]), полную семантику localStorage, включая стандартную квоту 5 МБ - ПОЧЕМУ? Нужно ли защищать серверные разработчики JavaScript от себя?

Для возможностей базы данных на стороне клиента квота на 5 МБ на каждый сайт - это действительно щедрое и полезное количество передышки, чтобы позволить разработчикам работать с ним. Вы можете установить гораздо более низкую квоту и по-прежнему предлагать разработчикам неизмеримое улучшение по сравнению с хромированием наряду с управлением файлами cookie. Предел 5 МБ не очень быстро поддается обработке на стороне клиента Big Data, но есть действительно довольно щедрое пособие, которое находчивые разработчики могут использовать, чтобы сделать многое. Но, с другой стороны, 5MB не является особенно большой частью большинства дисков, приобретенных в последнее время, что означает, что если вы и веб-сайт не согласны с тем, что разумно использует дисковое пространство, или какой-то сайт просто hoggish, он действительно не стоит вы много, и вам не угрожает болотный жесткий диск, если ваш жесткий диск уже не был слишком полным. Возможно, нам было бы лучше, если бы баланс был немного меньше или немного больше, но в целом его достойное решение для устранения внутреннего напряжения для клиентского контекста.

Тем не менее, можно было бы мягко указать, что, когда вы являетесь одним из написанных на вашем сервере, вам не нужна дополнительная защита, чтобы сделать вашу базу данных более чем допустимым размером 5 МБ. Большинство разработчиков не нуждаются ни в каких инструментах, работающих в качестве няни, и не защищают их от хранения более 5 МБ серверных данных. И квота 5 МБ, которая является золотым балансирующим действием на стороне клиента, немного глупо на сервере Node.js. (И для базы данных для нескольких пользователей, например, описанной в этом Приложении, можно было бы немного болезненно отметить, что это не 5 МБ на учетную запись пользователя, если вы не создадите отдельную базу данных на диске для каждой учетной записи пользователя, а 5MB совместно используется все документы пользователя вместе. Это может стать болезненным, если вы обратитесь к вирусу!) В документации указано, что квота настраивается, но неделю назад разработчик спрашивает, как изменить квоту, так же как и вопрос StackOverflow, задающий тот же вопрос, Единственный ответ, который я смог найти, - это источник Github CoffeeScript, где он указан как необязательный второй целочисленный аргумент для конструктора. Так что это достаточно просто, и вы можете указать квоту, равную размеру диска или раздела. Но помимо переноса функции, которая не имеет смысла, автор средств полностью не выполнил стандартное соглашение об интерпретации 0 как означающее "неограниченное" для переменной или функции, где целое число должно указывать максимальный предел для некоторого использования ресурсов. Самое лучшее, что можно сделать с этой ошибкой, - это, вероятно, указать, что квота Infinity:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

Обмен двумя комментариями по порядку:

Люди бесполезно стреляли в ногу, постоянно используя JavaScript в целом, а часть JavaScript, сделавшая респектабельный язык, была, по сути, дугласом Крокфордом: "JavaScript как язык имеет некоторые действительно хорошие части и некоторые действительно плохие части. хорошие вещи. Просто забудьте, что есть что-нибудь еще". Возможно, горячая экосистема Node.js будет расти своим собственным "Дугласом Крокфордом", который скажет: "экосистема Node.js - это кодирование Дикого Запада, но есть некоторые настоящие драгоценные камни для Здесь есть области, которые следует избегать практически любой ценой. Вот области, в которых одни из самых богатых платформ, которые можно найти в ЛЮБОЙ язык или среду".

Возможно, кто-то другой может взять эти слова в качестве вызова и следовать за Крокфордом и написать "хорошие части" и/или "лучшие части" для Node.js и его экосистемы. Id купите копию!

И учитывая степень энтузиазма и ясных рабочих часов по всем проектам, может потребоваться через год, или два, или три, резко остудить любые замечания о незрелой экосистеме, сделанные на момент написания этой статьи. В течение пяти лет может быть разумным сказать: "В экосистеме 2015 г. Node.js было несколько минных полей. В экосистеме 2020 г. Node.js есть несколько раев".

Еще одна вещь node - это возможность создавать несколько v8-приложений node с помощью дочернего процесса node (childProcess.fork(), каждый из которых требует 10 МБ памяти в соответствии с документами) "на лету", что не влияет на основной процесс работы сервера. Поэтому разгрузка фонового задания, требующего огромной нагрузки на сервер, становится дочерней игрой, и мы можем легко убить их по мере необходимости.

Я много использовал node, и в большинстве приложений, которые мы создаем, требуется одновременное подключение к серверу, таким образом, интенсивный сетевой трафик. Рамки вроде Express.js и новый Koajs (который удалил аддон обратного вызова) сделали работу над node еще проще.

Если ваше приложение в основном привязывает веб-apis или другие io-каналы, дайте или возьмите пользовательский интерфейс, node.js может стать для вас честным выбором, особенно если вы хотите выжать большую масштабируемость или, если вашим основным языком в жизни является javascript (или javascript transpilers). Если вы создаете микросервисы, node.js также в порядке. node.js также подходит для любого небольшого или простого проекта.

Его основной точкой продажи является то, что он позволяет передним лицам брать на себя ответственность за исходные вещи, а не за типичный разрыв. Еще одна оправданная точка продажи - если ваша рабочая сила ориентирована на JavaScript, чтобы начать с нее.

Однако, помимо определенного момента, вы не можете масштабировать свой код без страшных взломов для обеспечения модульности, удобочитаемости и управления потоком. Некоторым людям нравятся эти хаки, особенно, исходя из фона javascript, управляемого событиями, они кажутся знакомыми или прощающими.

В частности, когда ваше приложение должно выполнять синхронные потоки, вы начинаете истекать кровью по полузасушливым решениям, что значительно замедляет процесс разработки. Если у вас есть вычислительные элементы в приложении, пройдите с осторожностью (только) node.js. Возможно, http://koajs.com/ или другие новинки смягчают те изначальные тернистые аспекты, по сравнению с тем, когда я изначально использовал node.js или написал это.

Я могу поделиться несколькими моментами, где & зачем использовать node js.

• Для приложений реального времени, таких как чат, совместное редактирование, мы лучше используем nodejs, так как это база событий, где события пожара и данные для клиентов с сервера.
• Простой и понятный, поскольку это база javascript, где у большинства людей есть идея.
• Большинство текущих веб-приложений, идущих к angular js & backbone, с node, легко взаимодействовать с клиентским кодом, поскольку оба будут использовать данные json.
• Доступно множество доступных плагинов.

Недостатки: -

• Node будет поддерживать большинство баз данных, но лучше всего mongodb, который не будет поддерживать сложные объединения и другие.
• Ошибки компиляции... разработчик должен обрабатывать все исключения, другие мудрые, если какое-либо приложение, связанное с ошибкой, перестанет работать, когда мы снова должны пойти и запустить его вручную или с помощью любого инструмента автоматизации.

Вывод: - Nodejs лучше всего использовать для простых приложений в реальном времени. Если у вас очень большая бизнес-логика и сложная функциональность лучше не использовать nodejs. Если вы хотите создать приложение вместе с чатом и любой совместной функциональностью.. node может использоваться в определенных частях и оставаться в соответствии с вашими удобными технологиями.

• Node отлично подходит для быстрых прототипов, но я никогда больше не буду использовать его для чего-либо сложного. Я потратил 20 лет на развитие отношений с компилятором, и я, конечно, пропустил его.

• Node особенно болезнен для поддержания кода, который вы не посещали некоторое время. Информация о типе и время обнаружения ошибки компиляции - ХОРОШИЕ ВЕЩИ. Зачем бросать все это? Для чего? И dang, когда что-то идет на юг, стеки часто довольно бесполезны.