Для каких проектов используется node js?

Question

[JIakki]

Нормально ли писать обычные сайты на nodejs?
Разумно ли писать интернет магазин на node ?
Для каких проектов обычно используэтся nodejs?

Answer 1

[bromzh]

1) Нет. Обычный сайт - это одно короткое соединение на один запрос к серверу. Время жизни соединения ограничено одним request (пришёл запрос - соединение создалось, отдали ответ - оно умерло). Выигрыша по сравнению с обычными синхронными фреймворками нет. А так как нода - однопоточная, то может случиться так, что соединение, в котором выскочила ошибка убьёт всё приложение.
2) Нет. Бери любой развитый MVC-фреймворк на любом языке, так легче.
3) Для тех, где нужна асинхронность: прикрутить вебсокет-чат для готового сайта, работа с очередями сообщений (чтобы принимать их в неблокирующем режиме), рассылка уведомлений, запись в БД без блокировок, и т.д. Т.е. обычно его используют там, где надо держать много одновременно открытых соединений, каждое из которых не требует много процессорного времени, но может тормозить из-за IO.

Comments

[Александр Прозоров]

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

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

[bromzh]

Александр Прозоров: Ну понятно, что надо обезопасить себя и сделать обработку возможных ошибок максимально устойчивой, и запускать сервер не просто через screen.
Проблема в том, что новички могут не предусмотреть некоторые неочевидные вещи. Да и если что-то пойдет не так и одна задача сломает приложение, то все выполняющиеся задачи будут прервыны. После перезапуска далеко не факт, что данные смогут восстановиться. Например, асинхронная задача забрала из очереди сообщений послание, начала выполнять какое-то действие и уронила приложуху. Все незавершённые задачи уже забрали свои сообщения, но результат их выполнения прервался и если он не был сохранён где-то извне, то данные всех задач пропадут.
В многопоточном приложении потеряются данные только одной задачи, все другие потоки будут продолжать работать, да и основное приложение сложнее уронить.

[Александр Прозоров]

bromzh: всё верно, но почему вы решили что в Node.js нельзя разбивать задачи по потокам? Мне кажется вы очень условно понимаете "однопоточность" в Node.js. Вам никто не запрещает создавать многопоточное приложение на Node. Более того, там многие вещи, такие как обмен данными между процессами реализованы легко и красиво. Тут объект отправил - мам объект принял. Лично меня эта магия до сих пор неилюзорно радует.

[bromzh]

Александр Прозоров: Нет, нода однопоточная. Там есть event loop, который позволяет выполнять код асинхронно, но это не полноценные потоки. Если вызвать что-то блокирующее в любой задаче, заблокируется всё.
Вот в erlang'е асинхронность реализована через легковесные потоки (волокна). Есть 1 главный поток, все функции (корутины) запускаются в своих потоках. Там своя реализация планировщика. Но суть в том, что вызвав что-то блокирующее в какой-нибудь корутине, ты не заблочишь всё приложение. И если корутина сломается, приложение будет целым.
В Java, например, полноценные потоки на уровне JVM (вроде системные). При этом, код можно выполнять как просто параллельно (new Thread(runnable).start()), так и используя асинхронный подход (Future). И тут тоже потоки независимы, т.е. если один поток вызывает что-то блокирующее (если конечно не блокировать ресурсы через семафоры, например) или ломается, то приложение продолжает работать.

[Александр Прозоров]

bromzh: Вот вроде по форме вы правы - "Нет, нода однопоточная. Там есть event loop" - всё верно. Но что вам мешает выделять подзадачи в другие потоки в Node? Попробуйте - вам понравится :)

[bromzh]

Александр Прозоров: > Но что вам мешает выделять подзадачи в другие потоки в Node?
Как? Приведи пример пожалуйста. А то всё, что я нашёл - это запуск задачи в другом процессе, что далеко не одно и то же, что поток.

[Александр Прозоров]

bromzh: по сути я это и имел ввиду. Чем вас такой подход не устраивает? И желательно с практической точки зрения.

[bromzh]

Александр Прозоров: Ну стандартные преимущества тредов перед процессами:
Создавать процессы и переключаться между ними дольше, чем между потоками.
Нет общих ресурсов, ведь запуск процесса происходит в новой, изолированной среде, в новом интерпретаторе.
Передача данных в ноде идёт только через отправку сообщений, и сама передача данных между процессами - более дорогостоящая операция, чем передача между потоками.
Нет балансировщиков, типа тредпулов.
Более слабый контроль выполнения кода.
И т.д.

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

Так что нода пока однопоточна, а это не очень хорошо (хотя что-то начинает появляться.

Answer 2

[Александр Прозоров]

1. Процессинговый центр бонусных карт
   
2. Система автоматизации оконного производства (всё от приёма производственных заданий до складского учёта, realtime)
   
3. ERP/CRM SPA приложения с элементами realtime
   
4. Системы онлайн заказов
   

Comments

[Nick Murzin]

таким образом подойдёт для SPA-сайтов?

[Александр Прозоров]

Nick Murzin: Вопрос с подвохом да? :) Естественно в качестве бекенда для SPA приложений. Бонусом такого решения идёт изоморфный код, который может составлять изрядную долю за счёт тех же MVC-моделей.

[Nick Murzin]

Александр Прозоров: совсем нет, ссори если поставил в тупик "нубским вопросом". Пишу всё время на PHP. А для расширения кругозора хочу разобраться в зоопарке js-фреймворков и технологий

Answer 3

[Константин Китманов]

Писать стандартный магазин/визитку на node.js смысла немного, проще взять готовое решение на любой мейнстримной платформе (да хоть PHP, если не тошнит) и допилить, а то и взять конструктор/SaaS.
А вот что-то сложное, нестандартное, да еще если вы хорошо знаете JS и эффективно на нем пишите -- почему бы и нет.
Realtime можно сделать на чем угодно, Tornado, EventMachine, даже для PHP что-то было.

Comments

[Александр Прозоров]

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

[Константин Китманов]

Александр Прозоров: Основная фишка JS -- люди, которые знают JS, могут делать бэкенд. А уж из этого вытекает, в том числе, изоморфность. Я, например, не пишу полностью изоморфных приложений (не было нужды), хотя некоторые jade-шаблоны и библиотечки используются на сервере и на клиенте.

[Александр Прозоров]

Константин Китманов: Я бы не сказал, что человек хорошо знающий JS по front-end`у сходу начнёт писать сложные back-end`ы на Node. Да, порог вхождения ниже. Да, язык один и тот же. Но и различия весьма ощутимые. Что касается изоморфного подхода, то он проистекает не от клиентской школы, а как раз от серверной. Вы приводите весь свой код как раз к CommonJS формату и через это его унифицируете. Я не зря написал про внушительный стек. Пара изоморфных библиотек это одно, а изоморфный подход к архитектуре приложения это несколько совершенно иное.

[Константин Китманов]

Александр Прозоров: Вот я и говорю, что изоморфность -- не основное.

Answer 4

[tef]

Нод придуман для тех кому впадлу учить другой язык программирования. Теперь можно писать на джаваскрипте и на сервере! Аллилуя!

Comments

[Aleksandr Viskorenko]

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