Feathers: Сделайте серверную структуру Feathers независимой для работы с Express, Koa и Hapi.

Созданный на 12 мар. 2016  ·  22Комментарии  ·  Источник: feathersjs/feathers

Теперь, когда библиотека 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}!` });
  }
});
Breaking Change Feature Proposal

Самый полезный комментарий

Я думаю, что мы должны сделать 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));

По сути, адаптеры будут создавать промежуточное программное обеспечение для своей конкретной среды.

Все 22 Комментарий

Я думаю, что самым большим препятствием для этого будет аутентификация, в частности, как мы получаем доступ к объекту запроса и ответа и как промежуточное программное обеспечение паспорта работает с 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 миллиона .

_Я думаю, что эти цифры могут быть искусственно завышены за счет систем сборки, частоты развертывания, размера развертываний и т. д., но это дает общее представление о том, насколько популярны вещи._

Если быть до конца честным, глядя на цифры, на самом деле не так много стимулов поддерживать что-либо, кроме выражения. Основные причины, которые я вижу, следующие:

  • Поддержка http2 (которая в конечном итоге появится в express5....)
  • уменьшение зависимостей. Возможность использовать http(s) необработанных узлов или что-то более минимальное при создании API без сохранения состояния или микросервиса (первичный вариант использования перьев)
  • задел на будущее 👍
  • становится более модульным, так что вы можете поменять местами свой маршрутизатор, механизмы шаблонов и т. д. Feathers на самом деле — это просто архитектурный шаблон + служебная библиотека поверх основной технологии.

На мой взгляд, первым «движком», поддерживающим кроме 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

  • [ ] Сделать механизм аутентификации/транспорт независимым от транспорта (https://github.com/feathersjs/feathers-authentication/pull/336)
  • [] Псевдоним/изменение способа регистрации REST-маршрутов.
  • [ ] Псевдоним/изменить способ настройки сокетов

Может быть больше вещей. У @daffl была бы идея получше, особенно в отношении настройки сокета / отдыха.

Другие соображения

  • Собираемся ли мы поддерживать все HTTP-методы экспресс-глагола Express? Есть много . Разве это не означало бы реализацию большого количества Express?
  • На какие конкретные вещи Express мы сейчас полагаемся?
  • Какие вспомогательные методы объекта app вы хотите сохранить как часть основного API Feathers.
  • Как выглядит Express 5 для предложения? Прошло некоторое время с тех пор, как я смотрел на это. Было бы хорошо связаться с @dougwilson и посмотреть, можем ли мы протянуть руку помощи (если это имеет смысл, на этой кухне уже может быть достаточно поваров).
  • Существуют ли такие модули, как то, над чем работал @dougwilson , или spiritjs , http-framework и т. д., которые дали бы нам модульность без необходимости переписывать эти абстракции поверх основной функциональности узла.
// 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, и сделает соединения через веб-сокеты еще быстрее.

Эта проблема была автоматически заблокирована, так как после ее закрытия в последнее время не было никаких действий. Пожалуйста, откройте новую проблему со ссылкой на эту проблему для связанных ошибок.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

harrytang picture harrytang  ·  3Комментарии

rstegg picture rstegg  ·  3Комментарии

eric-burel picture eric-burel  ·  3Комментарии

huytran0605 picture huytran0605  ·  3Комментарии

corymsmith picture corymsmith  ·  4Комментарии