Comments 19
Коа очень хорошо подходит для микросервисов. В случае полноценного приложения Вам необходимо будет архитектуру своего фреймворка проектировать самому или выбирать с уже готовых шаблонов.
Это не плохо, но многим не хочеться с этим заморачиваться.
У вас будет шикарный фундамент, и выбор middleware для реализации роутинга, шаблонизации, сесии и т.д. Про некоторые полезные middleware я напишу во второй части.
Это хороший фреймворк — на нем создавались самые первые версии микросервисов нашей компании, мы использовали его совместно с модулем async. Некоторые из этих сервисов по сей день обслуживают ненагруженную часть сайта, которую мы еще не успели переписать. Но это CallBack-style фреймворк и они с Koa находятся в разных весовых категориях.
Пишу небольшой проект на koa2 (как раз rest), так что тема интересная.
Надеюсь во второй части будет информации побольше, чем просто из текущей документации.
async/await это то что через год станет частью JavaScript, остальные уровни не из нашей игры :)
Игра одна и та же. Через год медленные костыли станут чуть менее медленными, но всё теми же костылями. У async/await нет совершенно никаких преимуществ перед волокнами.
Если я правильно понял, вы хотете сказать что организация ECMA собирается добавить в стандарт "костыли"? Звучит это как-то, мягко говоря, не убедительно. Откуда вы знаете, что с какой скоростью будет реализовано?
В Koa используется async/await, я Вам его не навязываю, просто рассказваю о фреймворке. Вам нравиться модуль Fibers? Я против него ничего не имею — используйте.
Эта организация уже и так надобавляла уже кучу костылей и продолжает в том же духе. Чего только стоят несколько api для работы с пропертями (getters|setters, defineProperty/defineProperties, Object.create, Symbol, Reflection, Proxy). А ведь всего-то надо было лишь позволить перегружать операторы и получать идентификатор объекта.
По секрету скажу, что async/await, generators и прочие stackless сопрограммы в машинных кодах реализуются через тот же switch с соответствующими пенальти по производительности и сложностями оптимизации. Найдёте другой способ — дайте знать :-) fibers же не даёт никакого пенальти на вызов функции, только на переключение стеков, что является быстрой и относительно редкой операцией.
А я использую тот же express и враппер, запускающий обработчик в отдельном волокне:
express.get( '/userInfo', $jin.sync2middle( req => {
var body = {
auth : requestInfoFromAuthServer() ,
profile : requestProfileFromUserStorageServer() ,
}
return { status : 'ok' , type : 'text/json' , body }
} ) )
А чем express нестабилен?
Есть модуль 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 и не упадет.
Пишем микросервис на KoaJS 2 в стиле ES2017. Часть I: Такая разная ассинхронность