Feathers: フェザーサービスでRPCスタイルのメソッドを許可する

すでに準備ができているかもしれませんが、そうでない場合は、 https ： 。

FeathersはRESTアーキテクチャの制約に基づいて構築されており、それには多くの正当な理由があります（ @marshallswainがすでにリンクしているもので言及されているものも

これまでの利点（セキュリティ、予測可能性、明確に定義されたリアルタイムイベントの送信など）は、アプリケーションロジックを概念化するときに必要な考え方の変化を大幅に上回っています。

あなたの例のために：

• メールメッセージをデータベースに保存しないメールアクションを送信します。 メソッド「create」は「send」アクションを正確に記述していません

リソースがデータベースレコードである必要があるとはどこにも言いません。 これは、任意の種類のリソースにすることができます（都市の現在の天気や、それを送信する電子メールの作成など）。 電子メールの送信は通常、別の電子メールサービスのいずれかを使用して行われます。

app.use('/email', {
  create(data) {
    return sendEmail(data);
  }
})

またはフックで。

• eコマースWebサイトで注文します。 舞台裏では、1つのトランザクションに多くのレコードが挿入されます：order_item、order_header、voucher_tracking、...。このアクションを1つのエンティティに関連付けることは困難です。

これがフェザーフックの目的です。 したがって、新しい注文を作成するときは、明確に定義されたフックチェーンもあります。

app.service('orders').before({
  create: [
    validateData(),
    checkStock(),
    checkVoucher()
  ]
}).after({
  create: [
    chargePayment(), // hook that calls `app.service('payment').create()`
    sendEmail(), // hook that calls `app.service('email').create()`
    updateStock() // Update product stock here
  ]
})

最初は少し奇妙に感じるかもしれませんが、それらのパターンに合わせてみることをお勧めします。 RPCスタイルのライブラリを探しているなら、Feathersは正しい選択ではありません。

スレッドスターターに同意します。 これはFeatherJSの設計上の欠陥である可能性があります。
電子メールと注文サービスの例は「create」メソッドを使用してモデル化できますが、私の業務には、単純にRESTメソッドを使用できないビジネスロジックインスタンスもたくさんあります。

これについての高レベルの議論は続けません。 特定の例がある場合は、それらのパターンを中心に、より複雑なユースケースをモデル化する方法を紹介します。 Feathersは、 RESTアーキテクチャパターンを中心に構築され、それを実施するフレームワークです。 実際にRESTfulAPIを提供したい（そしてリアルタイム機能を無料で入手したい）場合、これらの制約を回避する方法はありません。

そうでない場合は、すでに述べたように、別のフレームワークを探す必要があります。

GraphQL + PostgraphQLの方が表現力に優れていることがわかりました。 すでに切り替えました！
Featherjsは優れたRESTフレームワークですが、それ自体が少数のREST動詞に制限されており、実際の使用には実用的ではありません。

世界中のほぼすべてのテクノロジー企業で使用されており、過去25年間インターネット全体で機能しているパターンが、実際に使用されていないことを理解できませんか？

GraphQLはデータクエリに適していますが、（データがどのように/変更されるかを決定する明確に定義された動詞のセットの代わりに）任意のミューテーションを定義できることには、独自の一連の課題があります（そしてそれが誰もいない理由の1つです）たとえばSOAPをもう使用しています）。

こんにちは、FeathersJSはこの部分を除いて非常に優れたデザインだと思います。
（実際、私は自分の仕事でJavaのFeatherJS REST Crud＆Query Serviceと同様のことを行い、それを広範囲に使用しました。GraphQLのファンではありません）

ただし、アプリケーションが使用するサービスはRESTサービスだけではありません。 むしろ、RESTサービスは単に「サービス」と呼ばれるべきではありません。
特定のビジネスロジックの場合、create / update / patch / deleteの代わりに、たとえば「doSomething」などのサービスメソッドが必要です。 （cosの場合、カスタムサービスAPIルートを作成することは可能ですが、WebSocketを使用する場合は、フレームワークによってすでに制御されているため、できませんか？featherjs WebSocket処理コード自体を変更しない限り）

とにかく、私はあなたたちがすでにクールなフレームワークをさらに改善するためのフィードバックとしてこれを受け取ることができることを願っています。 乾杯。

それでも、問題に取り組むメンタルモデルの調整にすぎないことが多いと思います。 ほとんどの「カスタム」メソッド/機能は、最初はそのように見えない場合でも、フックのチェーンまたはカスタムサービスとして表すことができます。

グローバルな「タスク」の場合、それらをキックできるtasksサービスを作成することに何も問題はないと思います。 それは次のように使用できます

app.service('tasks').create({
  action: 'doSomething',
  arguments: []
});

これらはWebSocketを介して使用でき、カスタムイベントなどを介してステータスを報告することもできます。

はい。 確かに、それは回避策です。 しかし、それほどきちんとはしていません。 まだ回避策。 ：/

サービスにカスタムメソッドを追加できるプラグインを作成しました： https ：

@ arve0まだクライアントでcreateを使用していますが、今のところ気に入っています。 追加を考えています

class BaseService {
  constructor (options) {
    this.options = options || {};
  }

  async create (data, params) {
    if (Array.isArray(data)) {
      return Promise.all(data.map(current => this.create(current, params)));
    }
    return data;
  }

}

module.exports = BaseService;

基本サービス。作成されたサービスにcreateコマンドを含める必要はありません。

const BaseService = require('../base/base.service');

/* eslint-disable no-unused-vars */
class Service extends BaseService{


  async doSomething (){
    console.log('custom');
     return {
      text: `custom response`
    };

  }
}

module.exports = function (options) {
  return new Service(options);
};

module.exports.Service = Service;

また、このコードをジェネレーターに含めると便利です。 :)

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