Feathers: Torne a estrutura do servidor Feathers independente para trabalhar com Express, Koa e Hapi

Criado em 12 mar. 2016 · 22Comentários · Fonte: feathersjs/feathers

Agora que o Feathers já funciona independente da biblioteca no cliente (consulte https://github.com/feathersjs/feathers/pull/193), também não precisamos mais do Express como dependência rígida para o servidor. Em vez disso, podemos criar módulos separados para Express, Koa e potencialmente Hapi que podem ser configurados como qualquer outro plugin:

Expressar

A única coisa para mudar a atualização de um aplicativo Feathers 2 seria para 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}!` });
  }
});

Koa

O suporte Koa surgiu várias vezes (veja #83 e #58). Isso agora pode ser feito de maneira muito semelhante:

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

Fonte

daffl

👍25 🎉8

Comentários muito úteis

Acho que devemos fazer do Feathers uma biblioteca em vez de uma estrutura - isso também o tornaria mais independente do transporte.

Exemplos:

Código comum

const feathersApp = feathers().configure(rest());
feathersApp.service('todos', new NeDB('todos'));
export default feathersApp;

Específico da estrutura

Koa

import feathersApp from './feathersApp';
import Koa from 'koa';
import adapter from 'feathers-koa';

const app = new Koa();
app.use(adapter(feathersApp));

Expressar

import feathersApp from './feathersApp';
import express from 'express';
import adapter from 'feathers-express';

const app = express();
app.use(adapter(feathersApp));

Basicamente, os adaptadores criarão o middleware para sua estrutura específica.

jeffijoe em 20 mai. 2016

👍14

Todos 22 comentários

A maior barreira para isso eu acho que será a autenticação, especificamente como temos acesso ao objeto de solicitação e resposta e como o middleware de passaporte funciona com Koa, etc.

De relance, não parece tão ruim com Koa. Só precisaríamos usar https://github.com/rkusa/koa-passport-example e ctx em vez de req e res . Com o Hapi, não tenho tanta certeza, mas não estou convencido de que haja muito valor em apoiar o Hapi, ele realmente não oferece nada diferente do Express. Pelo menos com o Koa você tem suporte ao gerador.

IMHO, se queremos ser mais flexíveis e não vinculados a uma estrutura, provavelmente é melhor usar módulos autônomos para roteamento, negociação de conteúdo etc.

ekryski em 12 mar. 2016

Para suporte de soquete com Koa, usamos isso como inspiração: https://github.com/koajs/koa.io.

ekryski em 12 mar. 2016

IMHO, se queremos ser mais flexíveis e não vinculados a uma estrutura, provavelmente é melhor usar módulos autônomos para roteamento, negociação de conteúdo etc.

http-framework ! :piscar:

ahdinosaur em 16 mar. 2016

@ahdinosaur ya que parece mais o caminho certo para ir IMHO.

ekryski em 16 mar. 2016

Acho que devemos fazer do Feathers uma biblioteca em vez de uma estrutura - isso também o tornaria mais independente do transporte.

Exemplos:

Código comum

const feathersApp = feathers().configure(rest());
feathersApp.service('todos', new NeDB('todos'));
export default feathersApp;

Específico da estrutura

Koa

import feathersApp from './feathersApp';
import Koa from 'koa';
import adapter from 'feathers-koa';

const app = new Koa();
app.use(adapter(feathersApp));

Expressar

import feathersApp from './feathersApp';
import express from 'express';
import adapter from 'feathers-express';

const app = express();
app.use(adapter(feathersApp));

Basicamente, os adaptadores criarão o middleware para sua estrutura específica.

jeffijoe em 20 mai. 2016

👍14

Nota: https://github.com/spirit-js/spirit

daffl em 12 ago. 2016

👍4

@daffl Acabei de verificar o espírito e parece muito legal. Seria incrível dissociar as penas do expresso. Com o surgimento de tantas novas implementações diferentes do expresso, isso tornaria as penas mais robustas no futuro. Alguma decisão sobre isso?

rickmed em 17 ago. 2016

Este PR de autenticação https://github.com/feathersjs/feathers-authentication/pull/336 deve ser a única peça importante que precisamos para poder suportar diferentes estruturas abaixo.

ekryski em 31 out. 2016

Eu tenho pensado muito mais sobre isso nos últimos dias e agora que estamos chegando perto de encerrar o Auk, esse será o principal objetivo do lançamento do Buzzard. Por mais legal que seja ser modular olhando para os números de uso, o Express não vai a lugar nenhum. Tem 70 milhões de downloads no ano passado , Koa está lá em cima com 1,4 milhões e Hapi com ~ 2,4 milhões .

_Acho que esses números podem ser inflados artificialmente por sistemas de compilação, frequência de implantação, tamanho de implantações etc., mas isso dá uma ideia geral de como as coisas são populares._

Sendo completamente honesto, olhando para os números, não há muito incentivo para apoiar nada além do expresso. Os principais motivos que vejo seriam:

Suporte a http2 (que parece estar chegando no express5 eventualmente ....)
reduzindo dependências. Ser capaz de usar http(s) de nó bruto ou algo mais mínimo ao criar uma API ou microsserviço sem estado (caso de uso de penas primárias)
sendo à prova de futuro 👍
tornando-se mais modular, para que você possa trocar seu roteador, mecanismos de modelo, etc. Feathers realmente é apenas um padrão de arquitetura + lib utilitário em cima da tecnologia principal.

Na minha opinião, o primeiro "motor" a oferecer suporte além do Express seria o Koa. É o mais semelhante em design ao Express e oferece um bom suporte para futuras funções de linguagem ES6/ES7. Também parece ser o nosso mais pedido. Pessoalmente, prefiro ter suporte para bibliotecas de nós brutos, mas isso pode ser muito trabalhoso.

O que precisa acontecer

[ ] Identifique a API Feathers de nível superior comum. Acho que não podemos identificar isso completamente até tentarmos pelo menos um outro motor por baixo. No entanto, eu ❤️ que fosse tão fácil quanto:
```
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);
```
Isso é conceitualmente semelhante ao que @jeffijoe estava sugerindo, no entanto, prefiro que as pessoas sintam que estão interagindo diretamente com um aplicativo Feathers. Eu acho que vai fazer para uma API mais limpa. No entanto, dito isso, é um pouco cedo para dizer, pois talvez tenhamos que corrigir uma tonelada de métodos. Mais investigações serão necessárias antes que possamos determinar a API de nível superior.
[ ] Certifique-se de que todos os métodos expressos usados sejam polyfilled, alias ou removemos a dependência deles. Pode haver mais, mas os que consigo pensar de cabeça são:
- app.get
- app.set
- app.render
- app.send
- app.json
- req.accepts
- req.xhr
[ ] Tornar o mecanismo de autenticação/transporte agnóstico (https://github.com/feathersjs/feathers-authentication/pull/336)
[ ] Alias/alterar como registramos as rotas REST.
[ ] Alias/alterar como configuramos os soquetes

Pode haver mais coisas. @daffl teria uma ideia melhor, especificamente em torno da configuração do soquete/descanso.

outras considerações

Vamos dar suporte a todos os métodos verbais HTTP do Express? Existem muitos . Isso não significaria implementar muito Express?
Em quais coisas específicas do Express estamos confiando atualmente?
Quais métodos auxiliares no objeto app você deseja manter como parte da API Feathers principal.
Como é o Express 5 para proposta? Já faz um tempo desde que eu olhei para ele. Seria bom entrar em contato com @dougwilson e ver se podemos dar uma mãozinha (se fizer sentido, já deve haver cozinheiros suficientes naquela cozinha).
Existem módulos como o que @dougwilson estava trabalhando ou spiritjs , http-framework , etc. que nos dariam a modularidade sem ter que reescrever essas abstrações sobre a funcionalidade do nó principal.

ekryski em 31 out. 2016

// or simply pass the engine. I like this best
const koa = require('koa');
app.engine(koa);

Acordado! Dessa forma, as pessoas podem aprender Feathers uma vez e implementar em qualquer servidor que tenha um adaptador. Boa ideia!

Download em 1 nov. 2016

O desafio está em converter bibliotecas que dependem de coisas específicas de conexão, como cabeçalhos.

Sobre o concurso de popularidade, minha principal razão para querer usar o Koa não é porque é popular (não tanto quanto expresso), mas porque é mais estável em termos de tratamento de erros de middleware.

jeffijoe em 1 nov. 2016

👍4

Por favor, vamos mover Feathers para uma arquitetura mais adequada para um gateway de API fino (servidor web clássico) e serviços web estúpidos/simples que podem ser implantados de forma independente e são independentes de protocolo, apenas ouvindo mensagens de interesse (ou seja, melhor prática Micro Service padronizar). Em seguida, podemos começar a integrar sem problemas com Seneca e outras estruturas populares de Micro Services Node.js.

E sim, FeathersJS deve ser agnóstico para Express, Koa, Hapi, o que for...
Eu adoraria vê-lo no Nginx com HTTP2/Push também :)

Dias felizes!

kristianmandrup em 8 mar. 2017

Vocês já viram isso https://github.com/fastify/fastify?

Eu adoraria usá-lo com FeathersJS, qual é o status deste problema?

andreafalzetti em 5 out. 2017

👍2

@andreafalzetti segue em frente. Você pode ver algum progresso acontecendo aqui: https://github.com/feathersjs/feathers-express/issues/3

marshallswain em 9 out. 2017

👍1

Pois é, seria super fofo integrar penas com fastify! Vamos fazer isso :)

kristianmandrup em 12 out. 2017

A integração básica deve ser bastante direta, no entanto, é a autenticação (especificamente o passaporte e o oAuth) onde as coisas ficam complicadas.

Nosso plano era remover a dependência do Express e depois da v3 investigar quais integrações fazem sentido. Eu vi uma palestra no Fastify na semana passada e, embora tenha sido interessante, pode fazer ainda mais sentido para o Feathers usar apenas Nodes HTTP (e HTTP2!) com o roteador que Fastify está usando como a integração principal.

daffl em 12 out. 2017

👍1

Para sua informação, comecei a trabalhar na integração REST feathers-koa em feathers-rest-koa

Acho que faria sentido extrair o cliente REST em um módulo/pacote e repositório separados;)

kristianmandrup em 12 out. 2017

Os clientes já estão em https://github.com/feathersjs/feathers-rest-client também relacionados: https://github.com/feathersjs/feathers-express/issues/3 por @christopherjbaker

daffl em 12 out. 2017

Como um novato no Feathers: Em 2018, o Feathers é completamente independente do Express?

EDIT: Ou em outras palavras: Quais outros frameworks são suportados. O KOA é totalmente suportado?

Obrigado! Ame o quadro e obrigado pelo trabalho duro!

bitflower em 24 jan. 2018

Pergunte ao @daffl , ele está trabalhando nisso... Não tenho certeza sobre o estado atual das coisas.

kristianmandrup em 24 jan. 2018

👍1

O Feathers é independente do framework (como você pode, por exemplo, usá-lo apenas com @feathersjs/socketio ou como um cliente autônomo para conversar com outros serviços), mas ele só possui ligações de API HTTP para Express (em @feathersjs/express ).

Como o objetivo do Feathers é abstrair as coisas específicas do protocolo, a estrutura HTTP que está usando não deve importar muito e abstrair coisas como autenticação do Express é uma tarefa muito grande (todo o Passport é construído para Express e até as integrações atuais do Koa apenas contornam esse fato mexendo com seu objeto de solicitação para torná-lo parecido com o Express). A prioridade mais alta para novas ligações de estrutura para mim seria HTTP de nó simples, que com um novo mecanismo de pesquisa de serviço produziria desempenho semelhante ao Fastify e tornaria as conexões de websocket ainda mais rápidas.

daffl em 24 jan. 2018

👍3

Este problema foi bloqueado automaticamente, pois não houve nenhuma atividade recente após o fechamento. Por favor, abra um novo problema com um link para este problema para bugs relacionados.