Feathers: Machen Sie das Feathers-Server-Framework unabhängig, um mit Express, Koa und Hapi zu arbeiten

Das größte Hindernis dafür wird meiner Meinung nach die Authentifizierung sein, insbesondere wie wir Zugriff auf das Anforderungs- und Antwortobjekt erhalten und wie die Passport-Middleware mit Koa funktioniert usw.

Auf den ersten Blick sieht es bei Koa gar nicht so schlecht aus. Wir müssten nur https://github.com/rkusa/koa-passport-example und ctx anstelle von req und res verwenden. Bei Hapi bin ich mir nicht so sicher, aber ich bin nicht davon überzeugt, dass es viel Wert hat, Hapi zu unterstützen, es bietet nicht wirklich etwas anderes als Express. Zumindest bei Koa hat man Generatorunterstützung.

IMHO, wenn wir flexibler und nicht an ein Framework gebunden sein möchten, ist es wahrscheinlich besser, nur eigenständige Module für Routing, Inhaltsverhandlungen usw. zu verwenden.

Für die Socket-Unterstützung mit Koa verwenden wir dies als Inspiration: https://github.com/koajs/koa.io.

IMHO, wenn wir flexibler und nicht an ein Framework gebunden sein möchten, ist es wahrscheinlich besser, nur eigenständige Module für Routing, Inhaltsverhandlungen usw. zu verwenden.

http-framework ! :zwinkern:

@ahdinosaur ya, das sieht meiner Meinung nach eher nach dem richtigen Weg aus.

Ich denke, wir sollten Feathers zu einer Bibliothek statt zu einem Framework machen - das würde es auch unabhängiger vom Transport machen.

Beispiele:

Gemeinsamer Code

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

Framework-spezifisch

Koa

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

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

äußern

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

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

Grundsätzlich erstellen die Adapter die Middleware für ihr jeweiliges Framework.

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

@daffl Ich habe gerade Spirit überprüft und es sieht sehr ordentlich aus. Es wäre erstaunlich, Federn von Express zu entkoppeln. Mit dem Aufkommen so vieler neuer Implementierungen, die sich von Express unterscheiden, würden Federn in Zukunft robuster werden. Irgendwelche Entscheidungen dazu?

Diese Authentifizierungs-PR https://github.com/feathersjs/feathers-authentication/pull/336 sollte das einzige größere Stück sein, das wir benötigen, um verschiedene Frameworks darunter unterstützen zu können.

Ich habe in den letzten Tagen viel mehr darüber nachgedacht und jetzt, wo wir uns der Abwicklung von Auk nähern, wird dies das Hauptziel für die Veröffentlichung von Buzzard sein. So schön es ist, modular zu sein, wenn man sich die Nutzungszahlen ansieht, Express geht nirgendwo hin. Es hat im letzten Jahr 70 Millionen Downloads , Koa liegt mit 1,4 Millionen ganz oben und Hapi mit ~2,4 Millionen .

_Ich denke, diese Zahlen können durch Build-Systeme, Bereitstellungshäufigkeit, Größe der Bereitstellungen usw. künstlich aufgebläht werden, aber das gibt eine allgemeine Vorstellung davon, wie beliebt Dinge sind._

Um ganz ehrlich zu sein, wenn man sich die Zahlen ansieht, gibt es wirklich nicht viel Anreiz, etwas anderes als Express zu unterstützen. Die Hauptgründe, die ich sehe, wären:

• http2-Unterstützung (die anscheinend irgendwann in Express5 kommt ....)
• Abhängigkeiten reduzieren. In der Lage zu sein, Raw-Knoten-http(s) oder etwas Minimaleres zu verwenden, wenn Sie eine zustandslose API oder einen Microservice erstellen (primärer Feathers-Anwendungsfall)
• zukunftssicher sein 👍
• wird modularer, sodass Sie Ihren Router, Template-Engines usw. austauschen können. Feathers ist wirklich nur ein Architekturmuster + Utility-Bibliothek auf der Basis von Kerntechnologie.

Meiner Meinung nach wäre Koa die erste "Engine", die eine andere als Express unterstützt. Es ist Express im Design am ähnlichsten und bietet gute Unterstützung für zukünftige ES6/ES7-Sprachfunktionen. Es scheint auch unser am meisten nachgefragtes zu sein. Persönlich hätte ich lieber Unterstützung für Raw-Node-Bibliotheken, aber das könnte eine Menge Arbeit sein.

Was passieren muss

• [ ] Identifizieren Sie die allgemeine Feathers-API der obersten Ebene. Ich glaube nicht, dass wir dies vollständig identifizieren können, bis wir mindestens einen anderen Motor darunter ausprobiert haben. Allerdings würde ich ❤️ es so einfach machen wie:

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

  Dies ähnelt konzeptionell dem, was @jeffijoe vorgeschlagen hat, aber ich würde es vorziehen, wenn die Leute das Gefühl haben, dass sie direkt mit einer Feathers-App interagieren. Ich denke, es wird für eine sauberere API sorgen. Davon abgesehen ist es jedoch noch etwas früh, um das zu sagen, da wir dann möglicherweise eine Menge Methoden anpassen müssen. Weitere Untersuchungen sind erforderlich, bevor wir die API der obersten Ebene bestimmen können.

• [ ] Stellen Sie sicher, dass alle verwendeten Express-Methoden entweder polyfill, aliased sind oder wir die Abhängigkeit von ihnen entfernen. Vielleicht gibt es noch mehr, aber die, die mir auf Anhieb einfallen, sind:
  
  
  
  • app.get
  
  
  • app.set
  
  
  • app.render
  
  
  • app.send
  
  
  • app.json
  
  
  • req.accepts
  
  
  • req.xhr
  
  
• [] Auth-Engine/Transport agnostisch machen (https://github.com/feathersjs/feathers-authentication/pull/336)
• [ ] Alias/ändern, wie wir REST-Routen registrieren.
• [ ] Alias/ändern, wie wir Sockets einrichten

Es könnten noch mehr Sachen sein. @daffl hätte eine bessere Idee, insbesondere in Bezug auf das Socket / Rest-Setup.

Andere Überlegungen

• Werden wir alle HTTP-Verbmethoden von Express unterstützen? Es gibt viele . Würde das nicht bedeuten, viel Express zu implementieren?
• Auf welche Express-spezifischen Dinge verlassen wir uns derzeit?
• Welche Hilfsmethoden für das app -Objekt möchten Sie als Teil der zentralen Feathers-API beibehalten.
• Wie sieht Express 5 für einen Vorschlag aus? Ist schon eine Weile her, dass ich es mir angeschaut habe. Es wäre gut, sich mit @dougwilson in Verbindung zu setzen und zu sehen, ob wir helfen können (wenn es Sinn macht, gibt es vielleicht bereits genug Köche in dieser Küche).
• Gibt es Module wie das, an dem @dougwilson gearbeitet hat, oder spiritjs , http-framework usw., die uns die Modularität geben würden, ohne diese Abstraktionen über der Kernknotenfunktionalität neu schreiben zu müssen?

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

Einverstanden! Auf diese Weise können Benutzer Feathers einmal lernen und auf jedem Server mit einem Adapter bereitstellen. Großartige Idee!

Die Herausforderung liegt in der Konvertierung von Bibliotheken, die auf verbindungsspezifischen Dingen wie Headern beruhen.

Was den Popularitätswettbewerb betrifft, so ist mein Hauptgrund, Koa zu verwenden, nicht, weil es beliebt ist (nicht so sehr wie Express), sondern weil es stabiler in Bezug auf die Behandlung von Middleware-Fehlern ist.

Bitte lassen Sie uns Feathers auf eine Architektur umstellen, die besser für ein dünnes API-Gateway (klassischer Webserver) und dumme/einfache Webdienste geeignet ist, die eigenständig bereitgestellt werden können und protokollunabhängig sind und nur Nachrichten von Interesse abhören (dh Best Practice Micro Service Muster). Dann können wir mit der reibungslosen Integration in Seneca und andere beliebte Node.js Micro Services-Frameworks beginnen.

Und ja, FeathersJS sollte gegenüber Express, Koa, Hapi, was auch immer ... agnostisch sein.
Ich würde es gerne auch auf Nginx mit HTTP2/Push sehen :)

Glückliche Tage!

Habt ihr das https://github.com/fastify/fastify gesehen?

Ich würde es gerne mit FeathersJS verwenden, wie ist der Status dieses Problems?

@andreafalzetti geht immer noch voran. Hier können Sie einige Fortschritte sehen: https://github.com/feathersjs/feathers-express/issues/3

Ja, wäre super süß, Federn mit Fastify zu integrieren! Lass es uns tun :)

Die grundlegende Integration sollte ziemlich einfach sein, aber bei der Authentifizierung (insbesondere Passport und oAuth) wird es schwierig.

Unser Plan war es, die harte Abhängigkeit von Express zu beseitigen und nach v3 zu untersuchen, welche Integrationen sinnvoll sind. Ich habe letzte Woche einen Vortrag über Fastify gesehen, und obwohl es interessant war, könnte es für Feathers noch sinnvoller sein, nur Nodes HTTP (und HTTP2!) Mit dem Router zu verwenden, den Fastify als Hauptintegration verwendet.

Zu Ihrer Information, ich habe mit der Arbeit an der REST-Integration von Feathers-Koa in Feathers-Rest-Koa begonnen

Ich denke, es wäre sinnvoll, den REST-Client in ein separates Modul/Paket und Repo zu extrahieren;)

Die Clients sind bereits unter https://github.com/feathersjs/feathers-rest-client ebenfalls bezogen: https://github.com/feathersjs/feathers-express/issues/3 von @christopherjbaker

Als Neuling bei Feathers: Bis 2018 ist Feathers komplett unabhängig von Express?

EDIT: Oder anders gesagt: Welche anderen Frameworks werden unterstützt? Wird KOA vollständig unterstützt?

Danke! Ich liebe das Framework und danke für die harte Arbeit!

Fragen Sie @daffl , er hat daran gearbeitet ... Bin mir aber nicht sicher über den aktuellen Stand der Dinge.

Feathers ist Framework-unabhängig (da Sie es zB nur mit @feathersjs/socketio oder als eigenständiger Client verwenden können, um mit anderen Diensten zu kommunizieren), aber es hat nur HTTP-API-Bindungen für Express (in @feathersjs/express ).

Da der springende Punkt von Feathers darin besteht, die protokollspezifischen Dinge zu abstrahieren, sollte das verwendete HTTP-Framework letztendlich keine so große Rolle spielen, und Dinge wie die Authentifizierung von Express weg zu abstrahieren, ist eine ziemlich große Aufgabe (Passport ist vollständig für Express und sogar die aktuellen Koa-Integrationen umgehen diese Tatsache einfach, indem sie mit ihrem Anforderungsobjekt herumspielen, damit es wie Express aussieht). Die höchste Priorität für neue Framework-Bindungen wäre für mich Plain Node HTTP, das mit einem neuen Service-Lookup-Mechanismus eine ähnliche Leistung wie Fastify erzielen und Websocket-Verbindungen noch schneller machen würde.

Dieses Problem wurde automatisch gesperrt, da es nach seiner Schließung keine Aktivitäten mehr gegeben hat. Bitte öffnen Sie ein neues Problem mit einem Link zu diesem Problem für verwandte Fehler.