web-dev-qa-db-ja.com

GraphQLとマイクロサービスアーキテクチャ

GraphQLがマイクロサービスアーキテクチャ内で使用するのに最も適している場所を理解しようとしています。

API Gatewayがリクエストをターゲットマイクロサービスにプロキシし、それらの応答を強制するGraphQLスキーマが1つだけであるという議論があります。マイクロサービスは、通信の思考にREST/Thriftプロトコルを使用します。

別のアプローチは、代わりに複数のGraphQLスキーマをマイクロサービスごとに1つ持つことです。リクエストのすべての情報とGraphQLクエリを使用して、ターゲットのマイクロサービスにリクエストをルーティングする、より小さなAPIゲートウェイサーバーが必要です。

最初のアプローチ

1つのGraphQLスキーマをAPIゲートウェイとして使用すると、マイクロサービス契約の入出力を変更するたびに、APIゲートウェイ側でGraphQLスキーマを変更する必要があるというマイナス面があります。

2番目のアプローチ

マイクロサービスごとに複数のGraphQLスキーマを使用する場合、GraphQLはスキーマ定義を強制し、消費者はマイクロサービスから提供される入出力を尊重する必要があるため、ある意味で意味があります。

質問

  • GraphQLは、マイクロサービスアーキテクチャを設計するのに最適です。

  • GraphQLを実装できるAPIゲートウェイをどのように設計しますか？

architecturemicroservicesgraphql
125
Fabrizio Fenoglio

間違いなく＃1にアプローチします。

クライアントが複数のGraphQLサービスと対話する（アプローチ＃2のように）ことは、GraphQLを最初に使用する目的を完全に無効にします。つまり、entireアプリケーションデータを1回のラウンドトリップで取得できるようにします。

shared nothingアーキテクチャを持つことは、マイクロサービスの観点からは理にかなっているように思えるかもしれませんが、クライアント側のコードでは、変更するたびに悪夢になりますマイクロサービスの場合、クライアントのallを更新する必要があります。あなたは間違いなく後悔するでしょう。

GraphQLは、クライアントからマイクロサービスアーキテクチャを持っているという事実を隠すため、GraphQLとマイクロサービスは最適です。バックエンドの観点からは、すべてをマイクロサービスに分割する必要がありますが、フロントエンドの観点からは、すべてのデータを単一のAPIから取得する必要があります。 GraphQLの使用は、私が知っている最良の方法です。バックエンドをマイクロサービスに分割しながら、すべてのアプリケーションに単一のAPIを提供し、さまざまなサービスのデータを結合できます。

マイクロサービスにRESTを使用したくない場合、もちろんそれぞれに独自のGraphQL APIを持たせることができますが、APIゲートウェイが必要です。 APIゲートウェイを使用する理由は、マイクロサービスパターンにうまく適合するためではなく、クライアントアプリケーションからマイクロサービスを呼び出しやすくするためです。

189
helfer

記事＃ here を参照してください。これは、アプローチ1がどのようにそしてなぜ機能するかを示しています。また、私が言及した記事から取られた以下の画像を見てください： enter image description here

すべてを単一のエンドポイントの背後に置くことの主な利点の1つは、各リクエストに独自のサービスがある場合よりも、データをより効率的にルーティングできることです。これは、GraphQLの推奨値であり、複雑さとサービスクリープの削減ですが、結果として得られるデータ構造により、データの所有権を非常に明確に定義し、明確に描くことができます。

GraphQLを採用するもう1つの利点は、データの読み込みプロセスをより強力に制御できることです。データローダーのプロセスは独自のエンドポイントに送られるため、要求を部分的、完全に、または注意を払いながら、データの転送方法を非常にきめ細かく制御できます。

次の記事では、これら2つの利点を他の利点とともに非常によく説明しています。 https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

23
Enayat

アプローチ＃2の場合、実際には、迷惑なAPIゲートウェイを手動で維持するよりもはるかに簡単なので、私が選択した方法です。この方法で、サービスを独立して開発できます。生活をもっと楽にする：P

スキーマを1つに結合する優れたツールがいくつかあります。 graphql-weaver およびapolloの graphql-tools 、私はgraphql-weaverを使用しています。使いやすく、すばらしい動作をします。

6
HFX

2019年半ばの時点で、1番目のアプローチのソリューションの名前は「 Schema Federationcoined by the Apollo people （以前はこれは多くの場合、GraphQLステッチと呼ばれていました）。彼らは、このためにモジュール@apollo/federationおよび@apollo/gatewayも提案しています。

1
vanthome

GraphQLとマイクロサービスを使用しています

私の経験に基づいて、機能/用途に応じて両方のアプローチを組み合わせることでうまくいくので、アプローチ1のように単一のゲートウェイを持つことはありません...しかし、アプローチ2として各マイクロサービスのgraphqlをネザーにします。

たとえば、Enayatからの回答の画像に基づいて、この場合に私がすることは、3つのグラフゲートウェイを持つことです（画像のように5ではありません）

enter image description here

  • アプリ（製品、バスケット、配送、在庫、他のサービスに必要/リンク）

  • 支払い

  • ユーザー

この方法では、認証トークン、ユーザーID、支払いID、支払いステータスなど、依存するサービスから公開される必要/リンクされた最小限のデータの設計に特に注意を払う必要があります

たとえば、私の経験では、「ユーザー」ゲートウェイがあります。GraphQLには、ユーザークエリ/突然変異、ログイン、サインイン、サインアウト、パスワードの変更、電子メールの復元、電子メールの確認、アカウントの削除、プロファイルの編集、写真のアップロードがあります、など...このグラフ自体は非常に大きい！、最後に他のサービス/ゲートウェイはユーザーID、名前、トークンなどの結果情報のみを考慮するため、分離されています。

この方法の方が簡単です...

  • 使用法に応じて、さまざまなゲートウェイノードをスケール/シャットダウンします。 （たとえば、人々は常に自分のプロファイルを編集したり支払いをしているわけではありませんが、検索製品はより頻繁に使用される可能性があります）。

  • ゲートウェイが成熟し、成長し、使用方法がわかるか、ドメインに関する専門知識があれば、ゲートウェイを所有できるスキーマの一部を特定できます（... gitリポジトリと対話する巨大なスキーマで私に起こりました） 、リポジトリと対話するゲートウェイを分離し、必要な/リンクされた情報は...フォルダパスと予想されるブランチのみであることがわかりました）

  • リポジトリの履歴がより明確になり、ゲートウェイとそれに関連するマイクロサービス専用のリポジトリ/開発者/チームを持つことができます。

0
Victor Jimenez