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.
Есть модуль koa-connect или koa-express. Оба позволяют подключать модули от express. Они спроектированы для версии koa 1.0 но через koa-convert можно подключить к Koa2, если есть такая необходимость. Правда не 100% експресовских middleware будут работать по такой схеме, т.к. в Koa некоторые объекты могут называться по-другому.
Конечно, запуск експресовских middleware на koa не лучшая практика, но такое использование может быть оправдано на этапе прототипирования, когда надо максимально быстро получить работающий костяк приложения.
По сравнению с koa у любого callbeck-style фреймворка (не только express) есть слабое место в обработке ошибок. Даже если вы в своем коде сделали все правильно, то ошибка может возникнуть во внешнем модуле и, как итог, ваш процесс падает, конечно там есть решение через домены, но они уж точно не добавляют красоты и наглядности вашему приложению. У koa такой проблемы нет, вы можете отлавливать все через try/catch как при работе сихронного кода, как показано в примере статьи. На koa уронить процесс значительно труднее, даже если вы сами не обработаете исключение, его обработает koa и не упадет.
Если я правильно понял, вы хотете сказать что организация ECMA собирается добавить в стандарт "костыли"? Звучит это как-то, мягко говоря, не убедительно. Откуда вы знаете, что с какой скоростью будет реализовано?
В Koa используется async/await, я Вам его не навязываю, просто рассказваю о фреймворке. Вам нравиться модуль Fibers? Я против него ничего не имею — используйте.
Чтоб не блокировать исполнение других обработчиков. Например к вашему 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 функции.
Есть модуль koa-connect или koa-express. Оба позволяют подключать модули от express. Они спроектированы для версии koa 1.0 но через koa-convert можно подключить к Koa2, если есть такая необходимость. Правда не 100% експресовских middleware будут работать по такой схеме, т.к. в Koa некоторые объекты могут называться по-другому.
Конечно, запуск експресовских middleware на koa не лучшая практика, но такое использование может быть оправдано на этапе прототипирования, когда надо максимально быстро получить работающий костяк приложения.
По сравнению с koa у любого callbeck-style фреймворка (не только express) есть слабое место в обработке ошибок. Даже если вы в своем коде сделали все правильно, то ошибка может возникнуть во внешнем модуле и, как итог, ваш процесс падает, конечно там есть решение через домены, но они уж точно не добавляют красоты и наглядности вашему приложению. У koa такой проблемы нет, вы можете отлавливать все через try/catch как при работе сихронного кода, как показано в примере статьи. На koa уронить процесс значительно труднее, даже если вы сами не обработаете исключение, его обработает koa и не упадет.
Если я правильно понял, вы хотете сказать что организация ECMA собирается добавить в стандарт "костыли"? Звучит это как-то, мягко говоря, не убедительно. Откуда вы знаете, что с какой скоростью будет реализовано?
В Koa используется async/await, я Вам его не навязываю, просто рассказваю о фреймворке. Вам нравиться модуль Fibers? Я против него ничего не имею — используйте.