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

Я новичок в таких вещах, но в последнее время я много слышал о том, как хорошо узел.js есть. Учитывая, насколько мне нравится работать с jQuery и JavaScript в целом, я не могу не задаться вопросом, как решить, когда использовать Node.js. Веб-приложения, я имею в виду что-то вроде Bitly - берет некоторый контент, архивирует его.

из всех домашних заданий, которые я делал в последние несколько дней, я получил следующую информацию. Узел.Яш

  • это инструмент командной строки, который может быть запущен как обычный веб-сервер и позволяет запускать программы JavaScript
  • использует большое V8 JavaScript engine
  • очень хорошо, когда вам нужно сделать несколько вещей одновременно
  • основан на событиях, поэтому все замечательно Ajax - подобные вещи можно делать на стороне сервера
  • позволяет обмениваться кодом между браузером и серверной
  • позволяет нам соединиться с MySQL

некоторые из источников, с которыми я столкнулся:

учитывая, что узел.js можно запустить почти из коробки на Amazon ЕС2 экземпляры, я пытаюсь понять, какой тип проблем требует узла.js в отличие от любого из могущественных королей там, как PHP, Python и Рубин. Я понимаю, что это действительно зависит от опыта работы с языком, но мой вопрос больше относится к общей категории: когда использовать конкретную структуру и для каких проблем она особенно подходит?

17 ответов


вы проделали большую работу по обобщению того, что потрясающе в Node.js. Я чувствую, что это узел.js особенно подходит для приложений, где вы хотите поддерживать постоянное соединение из браузера обратно на сервер. Используя метод, известный как "долго-опроса", вы можете написать приложение, которое отправляет обновления для пользователя в режиме реального времени. Делать длинный опрос на многих гигантов сети, как Ruby на Rails или Джанго, создала бы огромную нагрузку на сервере, потому что каждый активный клиент съедает один серверный процесс. Эта ситуация составляет тарпит атака. Когда вы используете что-то вроде узла.js, серверу не нужно поддерживать отдельные потоки для каждого открытого соединения.

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

стоит отметить, что у Ruby и Python есть инструменты для такого рода вещей (eventmachine и витая, соответственно), но этот узел.Яш делает это исключительно хорошо, и с нуля. JavaScript исключительно хорошо расположен для модели параллелизма на основе обратного вызова, и он выделяется здесь. Кроме того, возможность сериализации и десериализации с помощью JSON native как для клиента, так и для сервера довольно изящна.

Я смотрю вперед к чтению других ответов здесь, это фантастический вопрос.

стоит указать на этот узел.js также отлично подходит для ситуаций, в которых вы будете повторно использовать много кода через разрыв клиент/сервер. The основы Метеор делает это очень легко, и многие люди предполагают, что это может быть будущее веб-разработки. Я могу сказать по опыту, что писать код в Meteor очень весело, и большая часть этого тратит меньше времени на размышления о том, как вы собираетесь реструктурировать свои данные, чтобы код, который работает в браузере, мог легко манипулировать им и передавать его обратно.

вот статья о пирамиде и длинном опросе, которая оказывается очень простой в настройке с небольшой помощью gevent:TicTacToe и длинный опрос с пирамидой.


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

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

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

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

плюс это все JavaScript все время. Лингва франка на всю стопку.


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

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

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

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

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

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

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

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


чтобы сделать его коротким:

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

хорошая статья о цикле событий в узле.js is технический блог Mixu: понимание узла.событие в JS цикла.


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

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

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

  1. это очень легкий и быстрый. На этом веб-сайте было более 200000 посещений за три недели, и минимальные ресурсы сервера смогли справиться со всем этим.
  2. счетчик очень легко сделать, чтобы быть в реальном времени.
  3. узел.js было легко настроить.
  4. есть много модулей можно скачать бесплатно. Например, я нашел узел.JS модуль для PayPal.

в этом случае, узел.js был потрясающим выбором.


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

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

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

  • вы будете чувствовать себя в безопасности с Express без всех медиа сервер не нужен.
  • работает как ракета и хорошо масштабируется.
  • вы мечтаете. Ты его установил. РЕПО пакета узлаnpmjs.org является крупнейшей экосистемой библиотек с открытым исходным кодом в мире.
  • ваш мозг получит время искривлено в стране вложенных обратный вызов. ..
  • ... пока вы не научитесь держать свой обещания.
  • Sequelize и паспорт ваши новые друзья API.
  • отладка в основном асинхронного кода получит umm ... интересные .
  • время для всех Нодеров освоить машинопись.

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

  • Системы PayPal, Нетфликс, Волмарт, В LinkedIn, Групон, Убер, Компания GoDaddy, Доу Джонс!--6-->
  • вот почему они переключился на узел.

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

когда использовать узел.JS

  1. если ваш серверный код требует очень мало циклов процессора. В другом мире вы делаете неблокирующую операцию и не имеете тяжелого алгоритма/задания, которое потребляет много циклов процессора.
  2. если вы из Javascript back ground и удобно писать однопоточный код так же, как на стороне клиента JS.

когда не использовать узел.JS

  1. ваш сервер запрос зависит от тяжелого процессора, потребляющего алгоритм / задание.

рассмотрение масштабируемости с узлом.JS

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

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

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


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


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

редактировать

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

при использовании

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

  • сокеты только серверы, такие как чат-приложения, irc-приложения и т. д.
  • социальные сети, которые делают акцент на ресурсах в реальном времени, таких как геолокация, видеопоток, аудиопоток и т. д.
  • обработка небольших кусков данных очень быстро, как аналитика webapp.
  • как подвергать остальные только прикладной программный интерфейс.

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

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

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

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


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

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

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

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

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

Walmart re-engineered его мобильное приложение для использования узла.js и подтолкнул свою обработку JavaScript к серверу.

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


узел лучше для обработки -

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

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

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

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

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

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

теперь вот, как узел будет это делать:

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

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


мой еще одна причина выбрать узел.JS для нового проекта:

уметь делать чисто облачной разработки

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

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


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

Я много использую узел, и в большинстве приложений, которые мы создаем, требуется сервер соединения при этом при этом интенсивный сетевой трафик. Фреймворки вроде Экспресс.js и новая Koajs (который удалил callback hell) сделали работу на узле еще проще.


надев асбестовые авто...

вчера мой титул с публикациями Packt,реактивное программирование на JavaScript. На самом деле это не Узел.JS-ориентированное название; ранние главы предназначены для охвата теории, а более поздние главы с тяжелым кодом охватывают практику. Потому что я действительно не думал, что было бы уместно не дать читателям веб-сервер, узел.js казался однозначно очевидный выбор. Дело было закрыто до этого был даже открыт.

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

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

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

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

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

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

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

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

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

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

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

замена двух комментариев по порядку:

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


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

свой главный пункт продажи оно позволяет front-enders принять ответственность для бэк-энд, а не типичное разделение. Еще один оправданный пункт продажи - если ваша рабочая сила ориентирована на javascript.

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

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


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

  1. для приложений реального времени,таких как чат, совместное редактирование лучше мы идем с nodejs, поскольку это база событий, где событие огня и данные для клиентов с сервера.
  2. просто и легко понять, как это в JavaScript, где большинство людей имеют представление.
  3. большинство текущих веб-приложений, идущих к angular js & backbone, с узлом легко взаимодействовать с кодом на стороне клиента, поскольку оба будут использовать данные json.
  4. много плагинов.

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

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

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


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

  2. узел особенно болезнен для поддержания кода, который вы не посещали некоторое время. Тип info и обнаружение ошибок времени компиляции-это хорошие вещи. Зачем все это выбрасывать? За что? И черт возьми, когда что-то идет на юг, стек довольно часто полностью отслеживает бесполезный.