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

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

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

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

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

2194
Legend 21 Фев 2011 в 08:20

17 ответов

Лучший ответ

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

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

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

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

-3
Naeem Shaikh 6 Янв 2015 в 10:45

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

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

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

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

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

-2
BEJGAM SHIVA PRASAD 9 Авг 2016 в 15:02

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

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

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

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

9
matanster 18 Мар 2015 в 21:41

Надевать асбестовые кальсоны…

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

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

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

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

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

Есть подводные камни, которые не только раздражают людей, переходящих из Python / Django, который немедленно перезагружает исходный код, если вы что-то меняете. В Node.js поведение по умолчанию таково, что если вы сделаете одно изменение, старая версия будет оставаться активной до конца времени или до тех пор, пока вы вручную не остановите и не перезапустите сервер. Это неприемлемое поведение не только раздражает питонистов; это также раздражает пользователей Node.js, которые предлагают различные обходные пути. На вопрос StackOverflow «Автоматическая перезагрузка файлов в Node.js» на момент написания этой статьи было набрано более 200 положительных голосов и 19 ответов; редактирование направляет пользователя к сценарию няни, node-supervisor, с домашней страницей по адресу 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 года есть несколько райских мест ».

15
Christos Hayward 4 Сен 2015 в 12:15

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

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

15
I_Debug_Everything 8 Июн 2014 в 14:27

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

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

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

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

16
ajduke 18 Фев 2014 в 08:14

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

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

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

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

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

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

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

Вот как это сделает узел:

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

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

20
Anshul 16 Янв 2015 в 21:00

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

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

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

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

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

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

Подробнее читайте на странице http://www.pixelatingbits.com / a-close-look-at-mobile-app-development-with-node-js /

30
Vinayak Bevinakatti 17 Дек 2015 в 17:01

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

Изменить

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

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

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

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

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

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

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

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

36
shash7 12 Сен 2014 в 13:07

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

41
BoxerBucks 6 Июн 2013 в 17:42

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

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

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

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

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

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

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

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

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

60
Braiam 13 Авг 2016 в 18:46

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

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

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

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

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

  • PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • Вот почему они перешли на Node.
105
Tony O'Hagan 16 Авг 2016 в 10:14

У меня есть один реальный пример, в котором я использовал 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 был отличным выбором.

127
Peter Mortensen 14 Мар 2014 в 18:23

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

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

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

206
Peter Mortensen 14 Мар 2014 в 18:20

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

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

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

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

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

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

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

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

209
Community 23 Май 2017 в 10:31

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

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

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

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

К тому же это все время JavaScript. Lingua Franca во всем стеке.

409
fisherwebdev 21 Фев 2011 в 06:43