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

[dmitry111]

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

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


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

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

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


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


Спасибо!

[kobezzza]

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

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

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

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

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

[cyber]

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

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

[kobezzza]

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

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

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

[cyber]

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

[kobezzza]

У тебя есть:

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

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

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

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

Данные в REST должны передаваться в виде небольшого количества стандартных форматов (например HTML, XML, JSON). Сетевой протокол (как и HTTP) должен поддерживать кэширование, не должен зависеть от сетевого слоя, не должен сохранять информацию о состоянии между парами «запрос-ответ». Утверждается, что такой подход обеспечивает масштабируемость системы и позволяет ей эволюционировать с новыми требованиями.

Антиподом REST является подход, основанный на вызове удаленных процедур (Remote Procedure Call — RPC). Подход RPC позволяет использовать небольшое количество сетевых ресурсов с большим количеством методов и сложным протоколом. При подходе REST количество методов и сложность протокола строго ограничены, из-за чего количество отдельных ресурсов может быть большим.

[cyber]

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

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

[melky]

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

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

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

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

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

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

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

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


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

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

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

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

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

[kobezzza]

а почему стали делать именно так ?

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

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

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

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

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

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

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

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

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

[Octane]

Сообщение от kobezzza

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

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

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

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