Теперь, когда библиотека Feathers уже независима от клиента (см. https://github.com/feathersjs/feathers/pull/193), нам больше не нужен Express как жесткая зависимость для сервера. Вместо этого мы можем создать отдельные модули для Express, Koa и, возможно, Hapi, которые можно настроить так же, как и любой другой плагин:
Единственное, что можно изменить при обновлении приложения Feathers 2, — это app.configure(express())
:
const feathers = require('feathers');
const express = require('feathers-express');
const app = feathers()
// Make this app Express compatible
.configure(express())
// Configure REST API that uses Express
.configure(express.rest());
// Use any Express middleware
app.use(bodyParser.json());
// Use Feathers services normally
app.use('/todos', {
get(id) {
return Promise.resolve({ id, description: `You have to do ${id}!` });
}
});
Поддержка Коа появлялась несколько раз (см. № 83 и № 58). Теперь это можно сделать очень похоже:
const feathers = require('feathers');
const koa = require('feathers-koa');
const app = feathers()
// Make this app Koa compatible
.configure(koa())
// Configure Koa REST handler
.configure(koa.rest());
// Use normal Koa middleware
app.use(function *(){
this.body = 'Hello World';
});
// Use a Feathers service through app.service
app.service('/todos', {
get(id) {
return Promise.resolve({ id, description: `You have to do ${id}!` });
}
});
Я думаю, что самым большим препятствием для этого будет аутентификация, в частности, как мы получаем доступ к объекту запроса и ответа и как промежуточное программное обеспечение паспорта работает с Koa и т. д.
На первый взгляд с Koa все выглядит не так уж плохо. Нам просто нужно использовать https://github.com/rkusa/koa-passport-example и ctx
вместо req
и res
. С Hapi я не уверен, но я не уверен, что поддержка Hapi имеет большую ценность, на самом деле она не дает ничего отличного от Express. По крайней мере, с Koa у вас есть поддержка генератора.
ИМХО, если мы хотим быть более гибкими и не привязанными к фреймворку, нам, вероятно, лучше просто использовать автономные модули для маршрутизации, согласования контента и т. д.
Для поддержки сокетов с Koa мы используем это для вдохновения: https://github.com/koajs/koa.io.
ИМХО, если мы хотим быть более гибкими и не привязанными к фреймворку, нам, вероятно, лучше просто использовать автономные модули для маршрутизации, согласования контента и т. д.
http-framework
! :подмигивание:
@ahdinosaur да , это похоже на более правильный путь, ИМХО.
Я думаю, что мы должны сделать Feathers библиотекой, а не фреймворком — это также сделает его более независимым от транспорта.
Примеры:
const feathersApp = feathers().configure(rest());
feathersApp.service('todos', new NeDB('todos'));
export default feathersApp;
Коа
import feathersApp from './feathersApp';
import Koa from 'koa';
import adapter from 'feathers-koa';
const app = new Koa();
app.use(adapter(feathersApp));
выражать
import feathersApp from './feathersApp';
import express from 'express';
import adapter from 'feathers-express';
const app = express();
app.use(adapter(feathersApp));
По сути, адаптеры будут создавать промежуточное программное обеспечение для своей конкретной среды.
Примечание: https://github.com/spirit-js/spirit
@daffl Я только что проверил дух, и он выглядит очень аккуратно. Было бы замечательно отделить перья от экспресса. С появлением такого количества новых реализаций, отличных от экспресс, в будущем перья станут более надежными. Есть решения по этому поводу?
Этот PR аутентификации https://github.com/feathersjs/feathers-authentication/pull/336 должен быть единственной важной частью, которая нам нужна для поддержки различных фреймворков.
Последние несколько дней я много думал об этом, и теперь, когда мы приближаемся к закрытию Auk, это станет главной целью выпуска Buzzard. Как бы ни было приятно быть модульным, глядя на цифры использования, Express никуда не денется. В прошлом году у него было 70 миллионов загрузок , у Koa - 1,4 миллиона , а у Hapi - около 2,4 миллиона .
_Я думаю, что эти цифры могут быть искусственно завышены за счет систем сборки, частоты развертывания, размера развертываний и т. д., но это дает общее представление о том, насколько популярны вещи._
Если быть до конца честным, глядя на цифры, на самом деле не так много стимулов поддерживать что-либо, кроме выражения. Основные причины, которые я вижу, следующие:
На мой взгляд, первым «движком», поддерживающим кроме Express, будет Koa. По дизайну он больше всего похож на Express и обеспечивает хорошую поддержку будущих языковых функций ES6/ES7. Это также кажется нашим самым востребованным. Лично я бы предпочел иметь поддержку необработанных библиотек узлов, но это может потребовать много работы.
[ ] Определить общий API Feathers верхнего уровня. Я не думаю, что мы сможем полностью определить это, пока мы не попробуем хотя бы один другой двигатель под ним. Однако я бы ❤️, чтобы это было так же просто, как:
const feathers = require('feathers');
const app = feathers();
// use by string name
app.engine('express');
// or pass the engine with string
const koa = require('koa');
app.engine('koa', koa);
// or simply pass the engine. I like this best
const koa = require('koa');
app.engine(koa);
Это концептуально похоже на то, что предлагал @jeffijoe , однако я бы предпочел, чтобы люди чувствовали, что они напрямую взаимодействуют с приложением Feathers. Я думаю, что это сделает более чистый API. Однако, как говорится, пока рано говорить об этом, так как нам, возможно, придется изменить массу методов. Прежде чем мы сможем определить API верхнего уровня, потребуются дополнительные исследования.
app.get
app.set
app.render
app.send
app.json
req.accepts
req.xhr
Может быть больше вещей. У @daffl была бы идея получше, особенно в отношении настройки сокета / отдыха.
app
вы хотите сохранить как часть основного API Feathers.// or simply pass the engine. I like this best const koa = require('koa'); app.engine(koa);
Согласованный! Таким образом, люди могут один раз изучить Feathers и развернуть его на любом сервере с адаптером. Отличная идея!
Проблема заключается в преобразовании библиотек, которые полагаются на вещи, специфичные для подключения, такие как заголовки.
Что касается конкурса популярности, моя основная причина, по которой я хочу использовать Koa, заключается не в том, что он популярен (не так сильно, как в Express), а в том, что он более стабилен с точки зрения обработки ошибок промежуточного программного обеспечения.
Пожалуйста, давайте переместим Feathers на архитектуру, более подходящую для тонкого шлюза API (классический веб-сервер) и глупых/простых веб-сервисов, которые могут быть развернуты автономно и не зависят от протокола, просто прослушивая интересующие сообщения (т.е. передовая практика Micro Service шаблон). Затем мы можем начать плавную интеграцию с Seneca и другими популярными платформами Node.js Micro Services.
И да, FeathersJS не должен зависеть от Express, Koa, Hapi, чего угодно...
Я бы хотел увидеть это и на Nginx с HTTP2/Push :)
Счастливые дни!
Вы, ребята, видели это https://github.com/fastify/fastify?
Я хотел бы использовать его с FeathersJS, каков статус этой проблемы?
@andreafalzetti все еще движется вперед. Вы можете увидеть некоторый прогресс здесь: https://github.com/feathersjs/feathers-express/issues/3
Да, было бы очень мило интегрировать перья с fastify! Давай сделаем это :)
Базовая интеграция должна быть довольно простой, однако аутентификация (в частности, паспорт и oAuth) становится сложной.
Наш план состоял в том, чтобы удалить жесткую зависимость от Express и после v3 выяснить, какие интеграции имеют смысл. На прошлой неделе я видел доклад о Fastify, и, хотя он был интересным, для Feathers может быть даже более целесообразно просто использовать Nodes HTTP (и HTTP2!) с маршрутизатором, который Fastify использует в качестве основной интеграции.
К вашему сведению, я начал работу над интеграцией REST-коа с перьями-коа.
Я думаю, было бы целесообразно извлечь REST-клиент в отдельный модуль/пакет и репозиторий;)
Клиенты уже находятся на https://github.com/feathersjs/feathers-rest-client , также связанные: https://github.com/feathersjs/feathers-express/issues/3 от @christopherjbaker
Как новичок в Feathers: к 2018 году Feathers полностью независим от Express?
РЕДАКТИРОВАТЬ: Или, другими словами: какие другие фреймворки поддерживаются. Поддерживается ли KOA полностью?
Спасибо! Люблю фреймворк и спасибо за тяжелую работу!
Спросите @daffl , он работал над этим... Хотя не уверен насчет текущего положения дел.
Feathers не зависит от фреймворка (например, вы можете использовать его только с @feathersjs/socketio или в качестве отдельного клиента для взаимодействия с другими службами), но он имеет только привязки HTTP API для Express (в @feathersjs/express ).
Поскольку весь смысл Feathers заключается в абстрагировании специфических для протокола вещей, используемая им структура HTTP, в конечном счете, не должна иметь большого значения, а абстрагирование таких вещей, как аутентификация, от Express — довольно большая задача (весь Passport создан для Express и даже текущие интеграции Koa просто обходят этот факт, возясь с его объектом запроса, чтобы он выглядел как Express). Наивысшим приоритетом для новых привязок фреймворка для меня будет простой Node HTTP, который с новым механизмом поиска службы даст производительность, аналогичную Fastify, и сделает соединения через веб-сокеты еще быстрее.
Эта проблема была автоматически заблокирована, так как после ее закрытия в последнее время не было никаких действий. Пожалуйста, откройте новую проблему со ссылкой на эту проблему для связанных ошибок.
Самый полезный комментарий
Я думаю, что мы должны сделать Feathers библиотекой, а не фреймворком — это также сделает его более независимым от транспорта.
Примеры:
Общий код
Фреймворк-специфический
Коа
выражать
По сути, адаптеры будут создавать промежуточное программное обеспечение для своей конкретной среды.