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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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