А если вам нужно проверить не случилось ли ошибки при получении данных из базы
try {
user = await getUser();
} catch (err) {
// Error handling
}
Вы представляете во что превратиться Ваш код?
async/wait это отличная конструкция для написания человек-читаемого и легко понимаемого кода. Потому что код выглядит как синхронный а виполняется асинхронно.
Ваше заявление "С Promise получается короче" работает только для примитивных конструкций, для более сложных это не всегда справедливо
let user,spammers = [];
do {
user = await getUser();
if (await isSpammer(user)) {
spammers.push(user)
}
} while (spammers.length <= 10 && user !== null);
console.log(spammers)
В мире nodejs самая популярная ORM для mysql это драйвер MySQL :).
У себя в компании мы не используем ORM. В этой статье мы говорим про микросервис, у которого, как правило, количество кода и таблиц небольшое, сам микросервис сильно "заточен" под базу с которой он работает. От него требуеться быстродействие и минимальное потребление ресурсов.
Так в новой редакции у меня так и есть. Там роутер производит 2 разных middleware: 1 сами роуты, 2 заглушка, котрая правильно отвечает на вызов недопустимого метода. Но ее теретически можно не подключать, от этого REST сильно в функциональности не потеряет. В первой редакции это было не так, там эксортился инстанс роута, а он сам по себе middleware не является. Для генерации основного middleware у него надо вызвать метод router.routes()
Примечательно, что этот модуль — обёртка над node-fibers.
Так это еще один плюс в копилку async/await. Смысл для такой "крутой техногии" даунгрейдится в "более примитивную". Кроме того, из обсуждения ниже понятно, что замеры производительности сомнительны даже для babel.
Лучше я напишу в одном месте Future.fromPromise( p ).wait(), чем буду по всему коду раскидывать async и await.
Сомнительная красота.
В том-то и дело, что он не добавляет никакого нового синтаксиса. Только апи для запуска и переключения волокон.
А что api меняться не может?
Как я обожаю эту толерантность. Обе технологии выполняют одну и ту же функцию. Только одна прямо, хоть и не стандарт, а другая криво, хоть и почти-вот-вот-стандарт.
Тут "толерантность" не совсем подходит, синергия в случає с модулем обёрткой над node-fibers.
У node-fibers есть сильные стороны, которые вы уже перечислили но есть проблемы:
Есть некий талантливый разработчик Marcel Laverdet, который это все кодит. Ему сейчас интересно, репозиторий живой, но сильная зависимость от одного разработчика это риск для технологии. Ведь не всем она нравиться и ваша голосовалка говорит о том что даже после ваших блестящих аргунетов лидирует async/await
Бинарный код модуля это тоже проблема, т.к. есть облачные хостинги и среды с ограниченными возможностями по компиляции, где Вы не сможете собрать node-fibers.
Изомофный код, который становиться популярным в современных фреймворках не может использовать fibers, т.к. нету для него транспайлера.
Стандарт Async Functions будет принят в конце ноября, сейчас он в стадии 'Stage 3 ("Candidate")'. Это означает что Ваш код, написанный под этим синтаксисом меняться не будет и Вас нету рисков что-то переписывать.
Неккоректно сравнивать быстродействие async/await в совокупности с транспайлером babel, так как это не самая быстрая реализация этого синтаксиса. Если использовать модуль asyncawait то, по утверждению автора модуля, производительность составлячет 79% от callback-стиля оформления кода. Другими словами потеря в скорости несущественная. Ситуация может измениться в нативной реализации, которая вот-вот, появится.
Огромное количество модулей уже описаны промисами, вам стоит просто написать await и ваше приложение ассинхронно подождет.
То что у Fibers нету стандарта означает что синтаксис может претерпевать изменения, это существенно повышает риски долгосрочной поддержки такого кода.
Мне симпатична технология Fibers, но я не понимаю зачем ей противопоставлять async/await. Обе имеют свои плюсы и минусы.
Нет не принят, из ES 2017 тут используется только синтаксис async/await, который находиться в стадии 'Stage 3 («Candidate»)', ожидаемое время стадии 'Stage 4 («Finished»)' конец ноября, до принятия «Async Functions»|осталось ждать несколько месяцев.
Все остальные синтаксические конструкции из стандарта ES 2015.
В том то и дело что async/await выглядит как синхронный код а выполняется асинхронно.
Другими словами когда вы ждете ответа с базы вы не блокируете поток. В этот момент ваше приложение может обрабатвать другие запросы от пользователей.
А если вам нужно проверить не случилось ли ошибки при получении данных из базы
try {
user = await getUser();
} catch (err) {
// Error handling
}
Вы представляете во что превратиться Ваш код?
async/wait это отличная конструкция для написания человек-читаемого и легко понимаемого кода. Потому что код выглядит как синхронный а виполняется асинхронно.
Ваше заявление "С Promise получается короче" работает только для примитивных конструкций, для более сложных это не всегда справедливо
Чтоб не блокировать исполнение других обработчиков. Например к вашему web-серверу пришло несколько запросов.
Напишите аналог на промисах через рекурсию
Напишите аналог на промисах, у вас тут "независимая" обработка кажного юзера.
Ну и все это, конечно, внутри асихронной функции.
Покажите мне цикл на промисах, чтоб я асихронно получал пользователя из базы далее что-делал полученными данными и запрашивал следующего пользователя.
Слабо?
Это не драфт, предложение находится в Stage 3 ("Candidate"), в следующем месяце будет частью стандарта Stage 4 ("Finished").
А если в цикле?
Если речь идет о Windows:
Как-то однобоко получилось.
Есть монолит, есть сервисы, есть монолит+сервисы. И то, и то востребовано в разработке.
Слайды презентации: http://www.slideshare.net/profyclub_ru/dom-aviasalesru (чтоб "руками" ссылки не набирать :) ).
В мире nodejs самая популярная ORM для mysql это драйвер MySQL :).
У себя в компании мы не используем ORM. В этой статье мы говорим про микросервис, у которого, как правило, количество кода и таблиц небольшое, сам микросервис сильно "заточен" под базу с которой он работает. От него требуеться быстродействие и минимальное потребление ресурсов.
Вот некоторые ORM, на которые когда-то смотрел:
Так в новой редакции у меня так и есть. Там роутер производит 2 разных middleware: 1 сами роуты, 2 заглушка, котрая правильно отвечает на вызов недопустимого метода. Но ее теретически можно не подключать, от этого REST сильно в функциональности не потеряет. В первой редакции это было не так, там эксортился инстанс роута, а он сам по себе middleware не является. Для генерации основного middleware у него надо вызвать метод router.routes()
А вы что хотели чтоб я вам здесь фреймворк написал? В статье столько кода, сколько нужно для демонстрации подхода Koa 2.
Вы, видимо, еще очень начинающий программист — там все есть. Если это не так напишите мне SQL-инъекцию для этого сервиса.
Да вы не молчите, пишите, не стесняйтесь, может мы разберемся где у вас проблемы.
Тут "толерантность" не совсем подходит, синергия в случає с модулем обёрткой над node-fibers.
У node-fibers есть сильные стороны, которые вы уже перечислили но есть проблемы:
Есть некий талантливый разработчик Marcel Laverdet, который это все кодит. Ему сейчас интересно, репозиторий живой, но сильная зависимость от одного разработчика это риск для технологии. Ведь не всем она нравиться и ваша голосовалка говорит о том что даже после ваших блестящих аргунетов лидирует async/await
Бинарный код модуля это тоже проблема, т.к. есть облачные хостинги и среды с ограниченными возможностями по компиляции, где Вы не сможете собрать node-fibers.
Дискуссия async/await vs fibers началась несколько дней назад в коментах к моей статье Пишем микросервис на KoaJS 2 в стиле ES2017. Часть I: Такая разная ассинхронность. (название похоже или мне показалось :) ). Там эта цепочка не вызвала бурного обсуждения, но как я вижу, дискуссия не окончена.
Стандарт Async Functions будет принят в конце ноября, сейчас он в стадии 'Stage 3 ("Candidate")'. Это означает что Ваш код, написанный под этим синтаксисом меняться не будет и Вас нету рисков что-то переписывать.
Огромное количество модулей уже описаны промисами, вам стоит просто написать await и ваше приложение ассинхронно подождет.
Мне симпатична технология Fibers, но я не понимаю зачем ей противопоставлять async/await. Обе имеют свои плюсы и минусы.
Все остальные синтаксические конструкции из стандарта ES 2015.
Немного сложнее с датой, обычно для этого используют Moment.js:
Вы правы, хотел минимизировать. Поправил код, теперь экспортрую 2 функции.