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

avatar
Legend
21 февраля 2011 в 05:20
556520
17
2194

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

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

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

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

Учитывая, что Node.js можно запускать почти сразу после установки на инстансах Amazon EC2, я пытаюсь понять, для каких проблем требуется Node.js, а не для каких-либо серьезных такие короли, как PHP, Python и Ruby. Я понимаю, что это действительно зависит от опыта, который у человека есть в языке, но мой вопрос больше относится к общей категории: когда использовать конкретный фреймворк и для каких проблем он особенно подходит?

Источник
zzzzBov
16 августа 2016 в 16:34
4

Этот вопрос обсуждается на мета (meta.coderhelper.com/q/332386/497418).

Ответы (17)

avatar
Benson
21 февраля 2011 в 05:30
1354

Вы проделали отличную работу по обобщению того, что замечательно в Node.js. Мне кажется, что Node.js особенно подходит для приложений, в которых вы хотите поддерживать постоянное соединение между браузером и сервером. Используя метод, известный как «длинный опрос», вы можете написать приложение, которое отправляет обновления пользователю в реальном времени. Выполнение длительного опроса многих гигантов Интернета, таких как Ruby on Rails или Django, создало бы огромную нагрузку на сервер, потому что каждый активный клиент съедает один серверный процесс. Эта ситуация представляет собой атаку tarpit. Когда вы используете что-то вроде Node.js, серверу не нужно поддерживать отдельные потоки для каждого открытого соединения.

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

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

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

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

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

>
user482594
27 сентября 2011 в 07:03
12

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

Stokedout
8 января 2013 в 11:27
1

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

hitautodestruct
11 февраля 2016 в 07:46
12

Зачем нужен длинный опрос? Что случилось с будущим и сокетами?

Vikas
20 марта 2016 в 12:27
1

Мой короткий ответ - фоновый процесс. Все запросы и ответы (включая API для отдыха) могут быть выполнены на любом другом языке и на любом другом сервере. Так что для тех, кто думает преобразовать свои веб-проекты в node. Подумайте еще раз, это то же самое! Используйте узел в качестве фонового процесса, например, чтение электронных писем с помощью imap, обработку изображений, загрузку файлов в облако или любые длительные или бесконечные процессы, которые в основном ориентированы на события ...

avatar
BEJGAM SHIVA PRASAD
9 августа 2016 в 15:02
-2

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

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

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

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

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

avatar
Christos Hayward
2 сентября 2015 в 19:18
15

Надевание асбестовых длинных джинсов ...

Вчера мой заголовок в Packt Publications: Реактивное программирование с помощью JavaScript. На самом деле это не Node.js-ориентированный заголовок; первые главы предназначены для изучения теории, а последующие главы, насыщенные кодом, посвящены практике. Поскольку я действительно не думал, что уместно не предоставлять читателям веб-сервер, Node.js казался безусловно очевидным выбором. Дело было закрыто еще до открытия.

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

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

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

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

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

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

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

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

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

Тем не менее, можно осторожно указать, что когда вы пишете код для своего сервера, вам не нужна дополнительная защита от увеличения размера вашей базы данных более чем допустимые 5 МБ. Большинству разработчиков не нужны и не будут нужны инструменты, выступающие в роли няни и защищающие их от хранения более 5 МБ данных на стороне сервера. А квота в 5 МБ, которая является золотым балансирующим действием на стороне клиента, на сервере Node.js выглядит несколько глупо. (И для базы данных для нескольких пользователей, такой как описано в этом Приложении, можно с некоторой болью отметить, что это не 5 МБ на учетную запись пользователя, если только вы не создадите отдельную базу данных на диске для каждой учетной записи пользователя; эти 5 МБ разделяются между все учетные записи пользователей вместе. Это может стать болезненным , если вы станете вирусным!) В документации указано, что квота настраивается, но письмо, полученное неделю назад разработчику с вопросом, как изменить квоту, остается без ответа, как и было вопрос 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 и его экосистемы. Куплю копию!

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

avatar
Anshul
16 января 2015 в 20:10
20

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

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

Хорошо, согласен, что вы можете написать свой API на JavaScript, но что, если я согласен с вышеуказанной проблемой. Есть ли у вас еще одна причина использовать node for rest API?

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

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

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

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

Теперь вот как узел это сделает:

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

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

jsbisht
14 марта 2015 в 17:10
1

Привет, Аншуль. Можете ли вы уточнить или предложить какой-либо ресурс о том, как может возникнуть взаимоблокировка при многопоточности.

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

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

Rich Remer
17 октября 2014 в 20:16
2

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

James
29 мая 2015 в 16:19
2

Я провел 30 лет с компилируемыми языками, но после того, как я использовал его всего около года, я предпочитаю JavaScript. Это настолько продуктивно - я могу делать гораздо больше с гораздо меньшим количеством кода, чем Java C # C ++ или C. Но это другой образ мышления. Нетипизированные переменные на самом деле являются преимуществом во многих случаях. JSLINT необходим. Когда вам нужно делать что-то одновременно, асинхронные обратные вызовы намного безопаснее, проще и, в конечном итоге, более продуктивны, чем любой язык, где вам нужно использовать потоки. И вы все равно должны знать JavaScript, потому что это язык браузера.

joeytwiddle
26 ноября 2015 в 04:13
0

Я сочувствую поднятым опасениям и отмечаю, что были предприняты определенные усилия для их решения, хотя они, конечно, не применяются повсеместно. Существует замечательный проект под названием Tern, который может предоставить вывод типа из статического анализа кода и библиотек Javascript. Имеет плагины для различных редакторов. Также есть Typescript, JSDoc и BetterJS. А еще есть Go, один из многих языков компиляции в Javascript!

avatar
matanster
24 июля 2014 в 11:39
9

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

Его главный аргумент в том, что он позволяет фронтендерам брать на себя ответственность за внутреннюю часть, а не за типичное разделение. Еще один оправданный аргумент в пользу того, что ваша рабочая сила изначально ориентирована на JavaScript.

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

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

Sven Slootweg
9 марта 2015 в 02:40
3

Существует множество подходов к масштабированию приложений Node.js, и вы, похоже, не даете никаких ссылок, касающихся утверждений о «недоработанных решениях», «ужасных взломах» и «ужасных API». Разум расширяет кругозор?

matanster
9 марта 2015 в 11:39
0

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

Sven Slootweg
9 марта 2015 в 19:11
2

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

matanster
18 марта 2015 в 21:38
0

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

avatar
Vinayak Bevinakatti
3 июля 2014 в 07:17
30

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

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

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

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

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

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

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

avatar
Tony O'Hagan
12 июня 2014 в 13:24
105

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

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

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

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

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

Tony O'Hagan
14 июня 2014 в 04:24
18

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

refactor
19 мая 2016 в 12:25
1

вложенных обратных вызовов можно избежать, используя генераторы ES6 для асинхронного кода

Tony O'Hagan
20 мая 2016 в 00:12
1

@CleanCrispCode: Да, конечно! ES6 принял стиль C # async / await, поэтому теперь мы можем развернуть гораздо более чистый асинхронный код узла, который также поддерживает традиционный try / catch. В 2016/17 JS-кодеры переходят на ES6.

Simone Poggi
27 июля 2016 в 08:19
1

в десять тысяч раз больше: «С Express вы будете чувствовать себя в безопасности и в безопасности без всякого ненужного серверного ПО»

avatar
I_Debug_Everything
8 июня 2014 в 14:27
15

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

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

avatar
joeytwiddle
25 ноября 2013 в 21:47
209

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

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

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

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

  • Фактически он стал стандартной средой, в которой можно запускать инструменты, связанные с Javascript, и другие веб-инструменты , в том числе средства выполнения задач, средства повышения качества, минификаторы. препроцессоры, сборщики пакетов и аналитические процессоры.

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

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

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

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

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

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

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

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

joeytwiddle
23 августа 2015 в 16:46
1

@nane Да, я думаю, что они могут решить эту проблему, однако тогда вы должны ограничить себя использованием только библиотек, написанных на безопасных языках, или согласиться с тем, что не вся ваша кодовая база статически типизирована . Но есть один аргумент: поскольку вы должны написать хорошие тесты для своего кода независимо от языка, тогда ваш уровень достоверности должен быть равен даже для динамически типизированного кода. Если мы примем этот аргумент, то преимущества строгой типизации сводятся к ускорению разработки / отладки, доказуемости и оптимизации.

joeytwiddle
23 августа 2015 в 16:59
1

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

ed209
25 августа 2015 в 13:43
0

@joeytwiddle Ваше утверждение «вы должны ограничить себя использованием только библиотек, написанных на безопасных языках» неверно. Вы по-прежнему можете использовать нетипизированные библиотеки, если, например, используете что-то вроде машинописного текста. Вы также можете сгенерировать свои собственные файлы .d.ts и добавить их в проект с определенной типизацией. Однако я скажу, что машинописный текст безопасен по типу настолько, насколько вы готовы к нему приложить усилия. Вы можете полениться и набирать все, что не приносит пользы. Написав node и TS, я бы сказал, что вы были бы дураком, если бы не использовали TS.

CodeMonkey
3 сентября 2015 в 06:33
2

@joeytwiddle, разве такие вещи, как Typescript, не помогут Node.js, когда дело доходит до обработки больших сложных программ и статической проверки типов?

Dan
3 ноября 2015 в 12:37
0

@CodeMonkey Я лично использовал TypeScript, и каждый член команды в конечном итоге прибегал к использованию any в качестве типа (что противоречит цели), потому что это больше проблем, чем оно того стоит. Статическая проверка типов не поможет вам почти так сильно, как надежный набор тестов.

Dan
3 ноября 2015 в 12:38
2

@joeytwiddle для чего это стоит, вы можете использовать stillmainolated.com, чтобы определить, поддерживается ли пакет npm (поскольку большинство из них находится на github). Кроме того, npm search и npm show покажут вам дату последнего выпуска пакета.

BonsaiOak
26 февраля 2016 в 15:10
3

Сравнивая рельсы с узлом, вы путаете платформу с фреймворком. Rails - это фреймворк для Ruby, точно так же, как Sails и meteor - фреймворки для Javascript.

Michael Shopsin
3 августа 2016 в 14:25
0

Я пишу серверы на Java и Node.js, и сравнение уместно. Когда мне нужно много работать над долгой обработкой, Java - это прекрасно. Когда я хочу быть промежуточным звеном между другим веб-сервером и браузером пользователей, Node.js отлично подходит, тем более что я не сохраняю много состояния. NPM имеет множество пакетов, хотя качество и полнота оставляют желать лучшего. Стабильность Java и зрелые библиотеки лучше подходят для более сложной долгосрочной обработки информации. Единственный тип серверов, которые я ненавижу, - это серверы C ++, поскольку ручное управление памятью на серверах очень сложно сделать правильно.

avatar
Sean Zhao
27 сентября 2013 в 20:34
16

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

Уметь заниматься разработкой исключительно в облаке

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

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

Wanny Miarelli
24 февраля 2015 в 18:40
1

На самом деле Cloud9 IDE и другие (кодирование того, что я использую) поддерживают почти все типы веб-языков.

matanster
18 марта 2015 в 20:15
7

Ты серьезный чувак? это критерии выбора стека? :) рада, что это работает для вас!

avatar
BoxerBucks
6 июня 2013 в 17:42
41

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

joeytwiddle
19 июля 2013 в 21:46
6

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

Dan Dascalescu
13 февраля 2014 в 13:45
3

При всем уважении, многие пакеты на npm ужасны, потому что npm не имеет механизма для оценки пакетов . Взгляд в прошлое от CPAN кого-нибудь?

r3wt
1 августа 2014 в 06:32
0

Жаль, что ни одна из библиотек веб-сокетов не может удовлетворить спецификации rfc 6455. Фанаты node.js глухие, немые и слепые, когда говорят об этом факте.

Jonathan Gray
10 ноября 2014 в 04:14
1

Я не знаю, когда вы сделали комментарий, но на данный момент библиотека ws поддерживает эту спецификацию.

avatar
Joonas
31 мая 2013 в 06:34
127

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

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

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

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

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

Miguel Stevens
14 апреля 2014 в 15:25
7

Как организовать что-то подобное? Вам нужно установить nodejs на производственном сервере? В Linux?

harry young
15 июля 2015 в 23:17
1

Есть несколько PaaS, таких как nodejitsu и Heroku. Или вы действительно можете настроить nodejs на Linux, то есть на amazon ec2. см .: lauradhamilton.com/…

Tiberiu-Ionuț Stan
1 мая 2016 в 10:52
13

200 000 посещений за 1 814 400 секунд. Совершенно не актуально. Даже bash может обслуживать такое количество запросов на самом медленном сервере. Скретч-сервер. Самая медленная ВМ.

avatar
shash7
6 мая 2013 в 13:52
36

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

Изменить

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

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

При создании системы, в которой упор делается на параллелизм и скорость.

  • Разъемы только для серверов, таких как приложения для чата, приложения IRC и т. Д.
  • Социальные сети, в которых особое внимание уделяется ресурсам реального времени, таким как геолокация, видеопоток, аудиопоток и т. Д.
  • Обработка небольших фрагментов данных очень быстрая, как веб-приложение аналитики.
  • Поскольку предоставляет только API REST.

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

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

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

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

Endrju
5 января 2016 в 09:53
0

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

Bery
16 июня 2016 в 09:52
0

Я бы сказал иначе - взгляните на ghost.org, выглядит потрясающе и построен на основе NodeJs - совместная работа, редактирование статей в реальном времени. Кроме того, создание простой страницы в NodeJs, скажем, с использованием sailsjs.org, легко, быстро, и вам не нужно беспокоиться об изучении любого из языков программирования на стороне сервера.

avatar
Ajay Tiwari
5 апреля 2013 в 17:17
60

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

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

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

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

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

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

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

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

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

Ondrej Peterka
24 мая 2013 в 13:00
24

Я не уверен, что «Если ваш запрос на стороне сервера включает операции блокировки, такие как ввод-вывод файла или ввод-вывод сокета», перечисленный в «Когда НЕ использовать». Если я правильно понимаю, одна из сильных сторон node.js заключается в том, что у него есть мощные асинхронные средства для обработки ввода-вывода без блокировки. Таким образом, Node.js можно рассматривать как «лекарство» от блокировки ввода-вывода.

Ajay Tiwari
5 июня 2013 в 07:28
3

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

Omar Al-Ithawi
6 июня 2013 в 08:23
4

@ajay из nodejs.org они говорят «неблокирующий ввод-вывод», пожалуйста, отметьте «Когда НЕ» 2 и 3.

Erik Reppen
6 июля 2013 в 02:14
0

Можно писать и связывать компоненты C с приложениями Node.js.

Nam Nguyen
12 сентября 2013 в 20:05
5

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

Jess
14 мая 2014 в 19:44
4

Вы можете использовать node.js для тяжелых вычислений. Используйте fork. См. coderhelper.com/questions/9546225/…. Узел очень хорошо обрабатывает несколько ядер с модулем cluster. nodejs.org/api/cluster.html

avatar
stewe
15 января 2012 в 01:48
206

Для краткости:

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

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

avatar
fisherwebdev
21 февраля 2011 в 06:43
409

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

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

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

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

Плюс все время это JavaScript. Lingua Franca на всем стеке.

Michael Blackburn
8 сентября 2015 в 15:29
17

Просто наблюдение от кого-то, кто переключается между .Net и Node. Разные языки для разных областей системы очень помогают при переключении контекста. Когда я смотрю на Javascript, я работаю в клиенте, C # означает сервер приложений, SQL = база данных. Работая с Javascript, я обнаружил, что путаю слои или просто переключаю контекст дольше. Скорее всего, это артефакт работы над стеком .NET весь день и ночного кодирования ночью, но это имеет значение.

Michael Blackburn
8 сентября 2015 в 15:31
9

Интересно, что практика переключения диалектов между представителями разных культур при перемещении между основной и местной культурами называется «переключением кода».

AJB
30 декабря 2015 в 18:46
1

Буквально на днях я думал о том, как я могу каким-то образом назначить разные цвета моим различным файлам .js. Зеленый - на стороне клиента, синий - на стороне сервера. Я все время теряюсь.