[Асинхроность и nodejs] Кто что использует против callback hell и почему?

Question

[shcoderAlex]

Добрый день всем.

Связавшись с nodejs и выбрав его как основу новому проекту, я столкнулся с чем-то новым и поначалу очень не понятным для меня, это была асинхроность. Весь мой код был похож на пирамидки из колбеков стремящихся к правому краю экрана. Со временим открыл для себя пару вариантов async и Q. Пытался подружиться с fibrous-ом, но увы. Что-то слышал про yields и генераторы, но тоже не срослось. Хотел бы услышать ваше мнение по этому вопросу и узнать есть ли понацея?

Спасибо, продуктивного дня.

Answer 1

[Александр Кит]

Это популярная проблема, все пытаются с ней бороться, придумывают разные инструменты, библиотеки и прочее. Но скажу, что при хорошей архитектуре вложенность функций редко переваливает за 2 штуки - а это уже никакой не `хэл`. Ну вот посмотрите на метод в котором у вас этот самый `хэл`. Это же явное нарушение SOLID - один метод обрабатывает данные, куда-то их посылает, ждет в коллбэке ответ, с ним что-то делает, потом снова вызывает другую асинхронную функцию и опять ждет ответ, и так несколько раз. Поэтому `коллбэк хэл` - это классная штука, которая помогает разбивать код на независимые функции - принял данные, что-то сними сделал, отправил дальше как эти данные, так и другие аргументы. Точка.

Answer 2

[Тимур Шемсединов]

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

var dataRequests = [];
// массив запросов к разным данным (БД, файлы, сетевые вызовы)
var dataResults  = {};
// я предпочитаю не использовать массив results, который дает async
// а вместо этого делать именованные фрагменты данных
// и писать их в свой хеш

// добавляем один запрос к данным
dataRequests.push(function(callback) {
	db.queryRow(
		'SELECT * FROM TableName1 where Field1=?', [someValue1],
		function(err, res) {
			dataResults.firstPiceName = res;
			callback(err, null);
		}
	);
});

// добавляем второй запрос к данным
dataRequests.push(function(callback) {
	db.queryValue(
		'SELECT count(*) FROM TableName2 where Field2=?',
		[someValue2],
		function(err, res) {
			dataResults.secondPiceName = res;
			callback(err, null);
		}
	);
});

// вызываем массив запросов асинхронно
async.series(dataRequests, function(err, results) {
	// тут делаем бизнес-логику над dataResults в котором у нас есть
	// все фрагменты данных .firstPiceName и .secondPiceName
	// и формируем общий результат
});

А еще рекомендую ставить тег "node.js" на вопросы по ноде.

Comments

[shcoderAlex]

Поддерживаю Ваш подход со своим хешом, очень напряжно возиться с массивом который возвращается. По поводу тега, там явный баг он был но был по счёту 4, сейчас отредактировал дописал его, но его так же нет... Отписался в саппорт.

Answer 3

[Денис Пушкарев]

Ну основные подходы вы перечислили.

За yield, генераторами и обертками над ними - будующее, но пока они доступны только в нестабильной ветке 0.11. Fibers - попытка их эмулировать, мне не очень нравится, да и смысл, если скоро генераторы появятся в стабильной ветке? Q и прочие промисы - хорошая штука, но в js по старой привычке использую async.

Текущие проекты пишу на LiveScript, в нем с последовательными асинхронными операциями помогает такая штука, как backcall'ы, пример.

Answer 4

[zohkiller]

Есть IcedCoffeeScript http://maxtaco.github.io/coffee-script/ почти (а это и есть) как кофе скрипт, только не вызывает рвотных позывов как LiveScript

Comments

[Денис Пушкарев]

Как по мне, рвотные позывы скорее вызывают <a href="http://maxtaco.github.io/coffee-script/#try:sleepRandom%20%3D%20(time%2C%20callback)-%3E%0A%20%20await%20setTimeout%20defer()%2C%20time%20*%201000%0A%20%20callback%20Math.random()%20*%201000%20%7C%200%0A%0Aconsole.log%20'start'%0Aawait%20sleepRandom%205%2C%20defer%20a%0Aconsole.log%20'sleep%205%20sec%2C%20a%20%3D%20'%20%2B%20a%0Aawait%20sleepRandom%206%2C%20defer%20b%0Aconsole.log%20'sleep%206%20sec%2C%20b%20%3D%20'%20%2B%20b%0Aawait%20sleepRandom%207%2C%20defer%20c%0Aconsole.log%20'sleep%207%20sec%2C%20c%20%3D%20'%20%2B%20c%0Aconsole.log%20'a%20%2B%20b%20%2B%20c%20%3D%20'%20%2B%20(a%20%2B%20b%20%2B%20c)%0A">результаты компиляции</a> IcedCoffee. До перехода на LiveScript на нём и сидел.

[zohkiller]

ну сравним sleepRandom = !(time, callback)-> <- setTimeout _, time * 1000 callback Math.random! * 1000 .|. 0 log \start a <- sleepRandom 5 log 'sleep 5 sec, a = ' + a b <- sleepRandom 6 log 'sleep 6 sec, b = ' + b c <- sleepRandom 7 log 'sleep 7 sec, c = ' + c log 'a + b + c = ' + (a + b + c) и sleepRandom = (time, callback)-> await setTimeout defer(), time * 1000 callback Math.random() * 1000 | 0 console.log 'start' await sleepRandom 5, defer a console.log 'sleep 5 sec, a = ' + a await sleepRandom 6, defer b console.log 'sleep 6 sec, b = ' + b await sleepRandom 7, defer c console.log 'sleep 7 sec, c = ' + c console.log 'a + b + c = ' + (a + b + c) А что вы смотрите результат компиляции на node.js ? я вот нет, и дебага через @map source + ide хватает за глаза! А код должен быть читаем для программиста а не машины

[Денис Пушкарев]

На вкус и цвет... LS кода визуально в 1,5 раза меньше, он легко читаем => он красивее. Результаты компиляции на ноде я смотрю часто, далеко не ради отладки, а потому, как:

1. Важна производительность.

2. Один и тот же код часто идет и на сервер, и на клиент. Тут важен размер. 452 байта LS, тот же код, что был бы написан и на чистом js, против 1920 + подключенная библиотека у ICS.