Как вы пишете на сервере (node.js)
 

Много информации по написанию на node.js. Но чем больше ее изучаешь, тем понимаешь, что строгого подхода к написанию кода в node.js нет.

В этой теме хотелось бы понять при каких обстоятельствах использовать функции обратного вызова и события в node.js


Когда-то можно и не прерывать процесс. Запросили данные, подождали, получили.

Когда-то нужно с вызовом передать функцию обратного вызова (callback). И на другом конце обернуть ее process.nextTick()

Наверное кто-то весь код "склеивает" событиями eventEmitter.


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


Спасибо!

Главные правила ноды (из личного опыта, примерно ~ 2 года работы с нодой):

1) Не бросай исключений в асинхронных операциях, а передавай их как параметр callback;

2) Используй паттерны / фреймворки для работы с асинхронностью. Выбор фреймворка и паттерна зависит от предпочтений, я использую Async.

3) Нельзя по долгу занимать поток в серверном приложении, т.е. если нужно что-то большое посчитать, то либо используй setImmediate и дроби задачу, либо выноси задачу из Ноды на более предпочтительный инструмент (имхо, более правильное решение).

Всё остальное уже не так важно, т.е. пиши как нравиться.

Все руки не доходят проверить, если написать модуль для ноды на c++, и в нем провести расчеты, то нода блокироваться не будет, а задача будет выполненна асинхронно ?

Подозреваю, что это зависит от того, как написано дополнение, ведь для интеграции С/С++ кода как модулей ноды там есть своё АПИ, которое можно юзать и думаю, что есть возможность "фризить" поток выполнения ноды, если это нужно.

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

kobezzza, а можешь дать пример кода, если не тяжело .

У тебя есть:

1) Кластер серверов на ноде, который принимает и агрегирует входящие запросы от клиентов;

2) Кластер серверов на Java/C++/Erlang и т.д., которые делают какие то жёсткие вычисления в 100500 потоков и т.д.

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

Собственно по ссылке на википедии дан исчерпывающий ответ:

Без твоего добавления по написаному , не совсем понятно как это работает .
спасибо.

его вообще нет.

кстати, что ты имеешь в виду под "node.js" ? веб-сервер? так это ж только один компонент node.js

наверное ты имел в виду express\connect :)

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

решение оказалось простым - это было Ruby on Rails SailsJS. сначала показалось, что это закос под Yii, но потом меня одёрнуло, и я вспомнил, что Yii - это тоже закос под ROR

имхо, ответ дан на главной странице Node.js :


я хочу сказать - ответ "везде, где есть ввод\вывод". но это я так думаю :)

причём как первый параметр callback
kobezzza, а почему стали делать именно так ?

скоро будем использовать co и yield :D

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

Или если рассматривать yield подход, то использование try-catch тоже не шибко нравиться, т.к. синтаксис конструкции слишком громоздкий и цена за её использование высока.

Может я что-то не понимаю в этой жизни, но на мой взгяд это супер очевидно и удобно :)

async.map(['file1', 'file2', 'file3'], fs.stat, function (err, results) {
    ...
});

async.parallel(
    [
        function () { ... },
        function () { ... }
    ], 

    function (err, results) {
        ...
    }
);

Я пока не вижу очевидных плюсов подхода с yield, как замены async, так что с переходом повременю.

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

Это даже не рекомендация, а обязательное правило, потому что catch может поймать только исключение в своем стеке.

try {
    setImmediate(function () {
        throw new Error('test error');
    });
} catch (error) {
    console.log(error); //не поймает test error
}