Feathers: Express、Koa、Hapiで動作するようにFeathersサーバーフレームワークを独立させます

これに対する最大の障壁は認証であると思います。具体的には、リクエストとレスポンスのオブジェクトにアクセスする方法や、パスポートミドルウェアがKoaとどのように連携するかなどです。

一見すると、コアではそれほど悪くはありません。 reqとres $の代わりに、 https：//github.com/rkusa/koa-passport-exampleとctxを使用する必要があります。 Hapiについてはよくわかりませんが、Hapiをサポートすることに多くの価値があるとは確信していません。それは、Expressと何ら変わりはありません。 少なくともKoaでは、ジェネレーターをサポートしています。

IMHO、より柔軟でフレームワークに縛られないようにしたい場合は、ルーティングやコンテンツネゴシエーションなどにスタンドアロンモジュールを使用する方がおそらく良いでしょう。

Koaでのソケットサポートについては、これをインスピレーションに使用します： https：//github.com/koajs/koa.io。

IMHO、より柔軟でフレームワークに縛られないようにしたい場合は、ルーティングやコンテンツネゴシエーションなどにスタンドアロンモジュールを使用する方がおそらく良いでしょう。

http-framework ！ ：ウィンク：

@ahdinosauryaそれは私見に行くより正しい方法のように見えます。

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精神をチェックしたところ、とてもきれいに見えます。 エクスプレスからフェザーを切り離すのは素晴らしいことです。 エクスプレスとは異なる非常に多くの新しい実装が台頭しているため、将来的にはフェザーがより堅牢になります。 これに関する決定はありますか？

この認証PRhttps：//github.com/feathersjs/feathers-authentication/pull/336は、その下にあるさまざまなフレームワークをサポートできるようにするために必要な唯一の主要な部分である必要があります。

私はここ数日、これについてもっと多くのことを考えてきました。そして今、私たちはAukの清算に近づいているので、これがBuzzardリリースの主要な目標になるでしょう。 使用数を見てモジュール化するのは素晴らしいことですが、Expressはどこにも行きません。 昨年のダウンロード数は7000万回で、Koaは140万回、Hapiは約240万回です。

_これらの数値は、ビルドシステム、展開頻度、展開のサイズなどによって人為的に膨らませることができると思いますが、これにより、人気のあるものの概要がわかります。_

完全に正直に言うと、数字を見ると、表現する以外のことをサポートするインセンティブはあまりありません。 私が見る主な理由は次のとおりです。

• http2サポート（最終的にはexpress5で提供されるようです...）
• 依存関係を減らします。 ステートレスAPIまたはマイクロサービスを構築しているときにrawノードhttp（s）またはより最小限のものを使用できること（プライマリフェザーのユースケース）
• 将来を保証する👍
• よりモジュール化され、ルーターやテンプレートエンジンなどを交換できるようになります。フェザーは、実際には、コアテクノロジーに加えてアーキテクチャパターンとユーティリティライブラリにすぎません。

私の考えでは、Express以外でサポートする最初の「エンジン」はKoaでしょう。 これは、Expressと設計が最も類似しており、将来のES6 / ES7言語機能を適切にサポートします。 それも私たちの最も要求されているようです。 個人的には、rawノードライブラリをサポートしたいのですが、それは大変な作業になる可能性があります。

何が起こる必要があるか

• []一般的なトップレベルのFeathersAPIを特定します。 下にある他のエンジンを少なくとも1つ試してみるまで、これを完全に特定できるとは思いません。 しかし、私はそれが次のように簡単であるために❤️したいと思います：

  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は、特にソケット/レストのセットアップに関して、より良いアイデアを持っているでしょう。

その他の考慮事項

• ExpressのすべてのHTTP動詞メソッドをサポートしますか？ たくさんあります。 それは多くのExpressを実装することを意味しませんか？
• 現在、どのExpress固有のものに依存していますか？
• appオブジェクトのどのヘルパーメソッドをコアFeathersAPIの一部として保持しますか。
• Express 5の提案はどのようになっていますか？ 見てからしばらく経ちました。 @dougwilsonに連絡して、手を貸せるかどうかを確認するとよいでしょう（それが理にかなっている場合は、そのキッチンにすでに十分な料理人がいる可能性があります）。
• @dougwilsonが取り組んでいたものや、 spiritjs 、 http-frameworkなどのようなモジュールがあり、コアノード機能の上にこれらの抽象化を書き直すことなくモジュール性を提供します。

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

同意しました！ このようにして、人々はフェザーを一度学習し、アダプターを備えた任意のサーバーにデプロイできます。 いい案！

課題は、ヘッダーなどの接続固有のものに依存するライブラリを変換することにあります。

人気コンテストについて、私がKoaを使いたい主な理由は、人気があるからではなく（エクスプレスほどではない）、ミドルウェアエラーの処理に関してより安定しているからです。

Feathersを、シンAPIゲートウェイ（クラシックWebサーバー）と、スタンドアロンでデプロイでき、プロトコルに依存せず、関心のあるメッセージを聞くだけの愚かな/シンプルなWebサービス（つまり、ベストプラクティスのマイクロサービス）に適したアーキテクチャに移行してみましょう。パターン）。 その後、Senecaやその他の一般的なNode.jsマイクロサービスフレームワークとスムーズに統合を開始できます。

そして、はい、FeathersJSはExpress、Koa、Hapiなどにとらわれないはずです...
HTTP2 / Pushを使用したNginxでも見たいです:)

幸せな日々！

このhttps://github.com/fastify/fastifyを見たことがありますか？

FeathersJSで使用したいのですが、この問題の状況はどうなっていますか？

@andreafalzettiはまだ前進しています。 ここで進行中の進捗状況を確認できます： https ：//github.com/feathersjs/feathers-express/issues/3

ええ、羽毛と留め具を統合するのはとても甘いでしょう！ やってみましょう ：）

基本的な統合はかなり簡単なはずですが、それは物事が厄介になる認証（特にパスポートとoAuth）です。

私たちの計画は、Expressへの強い依存関係を取り除き、v3以降、どの統合が意味をなすかを調査することでした。 先週Fastifyについての話を見ましたが、それは興味深いものでしたが、Fastifyがメインの統合として使用しているルーターでNodes HTTP（およびHTTP2！）を使用する方がFeathersにとってさらに理にかなっているかもしれません。

参考までに、 feathers-rest-koaでのfeathers-koaREST統合の作業を開始しました

RESTクライアントを別のモジュール/パッケージとリポジトリに抽出するのは理にかなっていると思います;）

クライアントはすでにhttps://github.com/feathersjs/feathers-rest-clientにも関連しています： https ：//github.com/feathersjs/feathers-express/issues/3 by @christopherjbaker

Feathersの初心者として：2018年までに、FeathersはExpressから完全に独立していますか？

編集：または言い換えると：サポートされている他のフレームワーク。 KOAは完全にサポートされていますか？

ありがとう！ フレームワークが大好きで、ハードワークに感謝します！

@dafflに聞いてください、彼はそれに取り組んでいます...しかし、現在の状況についてはわかりません。

Feathersはフレームワークに依存しません（たとえば、 @ femalesjs / socketioでのみ使用するか、他のサービスと通信するためのスタンドアロンクライアントとしてのみ使用できます）が、Express用のHTTP APIバインディング（ @ femalesjs / express内）のみがあります。

Feathersの全体的なポイントはプロトコル固有のものを抽象化することなので、最終的に使用するHTTPフレームワークはそれほど重要ではなく、Expressから離れた認証などを抽象化することは、かなり大きなタスクです（PassportはすべてExpress用に構築されています。現在のKoa統合は、リクエストオブジェクトをいじって、Expressのように見せることで、その事実をハックします。 私にとっての新しいフレームワークバインディングの最優先事項は、プレーンノードHTTPです。これは、新しいサービスルックアップメカニズムを使用すると、Fastifyと同様のパフォーマンスを実現し、WebSocket接続をさらに高速化します。

この問題は、クローズされた後、最近のアクティビティがないため、自動的にロックされています。 関連するバグについては、この問題へのリンクを含む新しい問題を開いてください。