Feathers: Rendre le framework de serveur Feathers indépendant pour fonctionner avec Express, Koa et Hapi

Je pense que le plus grand obstacle à cela sera l'authentification, en particulier comment nous obtenons l'accès à l'objet de demande et de réponse et comment le middleware de passeport fonctionne avec Koa, etc.

En un coup d'œil, ça n'a pas l'air trop mal avec Koa. Nous aurions juste besoin d'utiliser https://github.com/rkusa/koa-passport-example et ctx au lieu de req et res . Avec Hapi, je ne suis pas si sûr, mais je ne suis pas convaincu qu'il y ait beaucoup de valeur à soutenir Hapi, cela ne fournit pas vraiment quelque chose de différent d'Express. Au moins avec Koa, vous avez un support de générateur.

À mon humble avis, si nous cherchons à être plus flexibles et non liés à un cadre, nous ferions probablement mieux d'utiliser des modules autonomes pour le routage, la négociation de contenu, etc.

Pour la prise en charge des sockets avec Koa, nous utilisons ceci comme source d'inspiration : https://github.com/koajs/koa.io.

À mon humble avis, si nous cherchons à être plus flexibles et non liés à un cadre, nous ferions probablement mieux d'utiliser des modules autonomes pour le routage, la négociation de contenu, etc.

http-framework ! :clin d'œil:

@ahdinosaur ya qui ressemble plus à la bonne façon de procéder à mon humble avis.

Je pense que nous devrions faire de Feathers une bibliothèque au lieu d'un cadre - cela le rendrait également plus indépendant sur le transport.

Exemples:

Code commun

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

Spécifique au framework

Koa

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

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

Express

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

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

Fondamentalement, les adaptateurs créeront le middleware pour leur framework particulier.

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

@daffl Je viens de vérifier l'esprit et il a l'air très soigné. Ce serait incroyable de découpler les plumes de l'express. Avec la montée en puissance de tant de nouvelles implémentations différentes d'express, cela rendrait les plumes plus robustes à l'avenir. Des décisions à ce sujet ?

Cette PR d'authentification https://github.com/feathersjs/feathers-authentication/pull/336 devrait être la seule pièce majeure dont nous avons besoin pour pouvoir prendre en charge les différents frameworks en dessous.

J'y ai beaucoup réfléchi ces derniers jours et maintenant que nous approchons de la fin d'Auk, cela va être le principal objectif de la sortie de Buzzard. Aussi agréable qu'il soit d'être modulaire en regardant les chiffres d'utilisation, Express ne va nulle part. Il a 70 millions de téléchargements l'année dernière , Koa est juste là-haut avec 1,4 million et Hapi avec ~2,4 millions .

_Je pense que ces chiffres peuvent être artificiellement gonflés par les systèmes de construction, la fréquence de déploiement, la taille des déploiements, etc., mais cela donne une idée générale de la popularité des choses._

Pour être tout à fait honnête, en regardant les chiffres, il n'y a vraiment pas beaucoup d'incitation à soutenir autre chose qu'exprimer. Les principales raisons que je vois seraient:

• Prise en charge de http2 (qui semble arriver éventuellement dans express5 ....)
• réduction des dépendances. Pouvoir utiliser des http(s) de nœuds bruts ou quelque chose de plus minimal lorsque vous créez une API ou un microservice sans état (cas d'utilisation principal des plumes)
• être à l'épreuve du futur 👍
• devenant plus modulaire, de sorte que vous pouvez échanger votre routeur, vos moteurs de modèles, etc. Feathers n'est vraiment qu'un modèle architectural + une bibliothèque utilitaire au-dessus de la technologie de base.

Dans mon esprit, le premier "moteur" à prendre en charge autre qu'Express serait Koa. C'est la conception la plus similaire à Express et offre une bonne prise en charge des futures fonctions de langage ES6/ES7. Il semble également être notre plus demandé. Personnellement, je préférerais avoir un support pour les bibliothèques de nœuds bruts, mais cela pourrait représenter beaucoup de travail.

Que doit-il arriver

• [ ] Identifiez l'API Feathers de niveau supérieur commune. Je ne pense pas que nous puissions l'identifier pleinement avant d'avoir essayé au moins un autre moteur en dessous. Cependant, je ❤️ pour que ce soit aussi simple que :

  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);
  

  Ceci est conceptuellement similaire à ce que @jeffijoe suggérait, cependant, je préférerais que les gens sentent qu'ils interagissent directement avec une application Feathers. Je pense que cela fera une API plus propre. Cependant, cela étant dit, il est un peu tôt pour le dire, car nous devrons peut-être alors modifier une tonne de méthodes. Une enquête plus approfondie sera nécessaire avant de pouvoir déterminer l'API de niveau supérieur.

• [ ] Assurez-vous que toutes les méthodes express utilisées sont polyfilled, aliasées ou que nous supprimons leur dépendance. Il y en a peut-être d'autres, mais ceux qui me viennent à l'esprit sont :
  
  
  
  • app.get
  
  
  • app.set
  
  
  • app.render
  
  
  • app.send
  
  
  • app.json
  
  
  • req.accepts
  
  
  • req.xhr
  
  
• [ ] Rendre le moteur d'authentification/transport indépendant (https://github.com/feathersjs/feathers-authentication/pull/336)
• [ ] Alias/modifier la façon dont nous enregistrons les routes REST.
• [ ] Alias/modifier la configuration des sockets

Il pourrait y avoir plus de choses. @daffl aurait une meilleure idée, en particulier autour de la configuration socket/rest.

autres considérations

• Allons-nous prendre en charge toutes les méthodes de verbe HTTP d'Express ? Il y en a beaucoup . Cela ne signifierait-il pas implémenter beaucoup d'Express ?
• Sur quels éléments spécifiques à Express comptons-nous actuellement ?
• Quelles méthodes d'assistance sur l'objet app voulez-vous conserver dans le cadre de l'API Feathers principale.
• À quoi ressemble Express 5 pour la proposition ? Ça fait un moment que je l'ai regardé. Ce serait bien de se connecter avec @dougwilson et de voir si nous pouvons donner un coup de main (si cela a du sens, il pourrait déjà y avoir suffisamment de cuisiniers dans cette cuisine).
• Y a-t-il des modules comme sur quoi @dougwilson travaillait ou spiritjs , http-framework , etc. qui nous donneraient la modularité sans avoir à réécrire ces abstractions au-dessus de la fonctionnalité du nœud principal.

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

D'accord! De cette façon, les gens peuvent apprendre Feathers une fois et se déployer sur n'importe quel serveur doté d'un adaptateur. Bonne idée!

Le défi réside dans la conversion des bibliothèques qui s'appuient sur des éléments spécifiques à la connexion, tels que les en-têtes.

À propos du concours de popularité, ma principale raison de vouloir utiliser Koa n'est pas parce qu'il est populaire (pas autant qu'express), mais parce qu'il est plus stable en termes de gestion des erreurs de middleware.

S'il vous plaît, déplaçons Feathers vers une architecture plus adaptée à une passerelle API légère (serveur Web classique) et à des services Web stupides/simples qui peuvent être déployés de manière autonome et sont indépendants du protocole, en écoutant simplement les messages d'intérêt (c'est-à-dire les meilleures pratiques Micro Service schéma). Ensuite, nous pouvons commencer à nous intégrer en douceur avec Seneca et d'autres frameworks Node.js Micro Services populaires.

Et oui, FeathersJS devrait être agnostique à Express, Koa, Hapi, peu importe...
J'adorerais le voir sur Nginx avec HTTP2/Push aussi :)

Jours heureux!

Avez-vous vu ce https://github.com/fastify/fastify ?

J'adorerais l'utiliser avec FeathersJS, où en est ce problème ?

@andreafalzetti continue d'avancer. Vous pouvez voir des progrès ici : https://github.com/feathersjs/feathers-express/issues/3

Ouais, ce serait super sympa d'intégrer des plumes avec fastify ! Faisons-le :)

L'intégration de base devrait être assez simple, cependant, c'est l'authentification (en particulier le passeport et oAuth) où les choses se compliquent.

Notre plan était de supprimer la dépendance vis-à-vis d'Express et, après la v3, d'étudier quelles intégrations avaient du sens. J'ai vu une conférence sur Fastify la semaine dernière et même si c'était intéressant, il serait peut-être encore plus logique que Feathers utilise simplement Nodes HTTP (et HTTP2 !) avec le routeur que Fastify utilise comme intégration principale.

Pour info, j'ai commencé à travailler sur l'intégration REST plumes-koa dans plumes-rest-koa

Je pense qu'il serait logique d'extraire le client REST dans un module/package et un référentiel séparés ;)

Les clients sont déjà sur https://github.com/feathersjs/feathers-rest-client également liés : https://github.com/feathersjs/feathers-express/issues/3 par @christopherjbaker

En tant que débutant dans Feathers : d'ici 2018, Feathers est-il complètement indépendant d'Express ?

EDIT : Ou en d'autres termes : quels autres frameworks sont pris en charge. KOA est-il entièrement pris en charge ?

Merci! J'adore le cadre et merci pour le travail acharné!

Demandez à @daffl , il y travaille... Pas sûr de l'état actuel des choses cependant.

Feathers est indépendant du framework (vous ne pouvez par exemple l'utiliser qu'avec @feathersjs/socketio ou en tant que client autonome pour parler à d'autres services) mais il n'a que des liaisons API HTTP pour Express (dans @feathersjs/express ).

Étant donné que l'intérêt de Feathers est d'abstraire les choses spécifiques au protocole, le framework HTTP qu'il utilise ne devrait finalement pas vraiment avoir beaucoup d'importance et l'abstraction de choses comme l'authentification loin d'Express est une tâche assez importante (tout Passport est conçu pour Express et même les intégrations Koa actuelles ne font que contourner ce fait en jouant avec son objet de requête pour le faire ressembler à Express). Pour moi, la priorité la plus élevée pour les nouvelles liaisons de framework serait le nœud HTTP simple qui, avec un nouveau mécanisme de recherche de service, donnerait des performances similaires à Fastify et rendrait les connexions Websocket encore plus rapides.

Ce problème a été automatiquement verrouillé puisqu'il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau problème avec un lien vers ce problème pour les bogues associés.