[解決済み】マイクロサービスアーキテクチャでGraphQLを使用するタイミングと方法

質問

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

API Gatewayとして動作する1つのGraphQLスキーマのみを持ち、対象となるマイクロサービスにリクエストをプロキシし、そのレスポンスを強制するという議論がある。しかし、マイクロサービスはREST/Thriftプロトコルで通信することになります。

もう一つのアプローチは、マイクロサービスごとに複数のGraphQLスキーマを持つことです。小さなAPI Gatewayサーバを持ち、リクエストのすべての情報とGraphQLクエリを使ってターゲットとなるマイクロサービスへリクエストをルーティングする。

第一のアプローチ

API Gatewayとして1つのGraphQL Schemaを持つことは、マイクロサービスのコントラクト入出力を変更するたびに、API Gateway側でそれに応じてGraphQL Schemaを変更しなければならないという欠点があります。

第二のアプローチ

マイクロサービスごとに複数のGraphQLスキーマを使用する場合、GraphQLがスキーマ定義を強制し、コンシューマーはマイクロサービスから与えられた入力/出力を尊重する必要があるため、ある意味理にかなっています。

質問内容

• GraphQLがマイクロサービスアーキテクチャの設計に適していると思うのはどこですか？

• GraphQLの実装が可能なAPI Gatewayは、どのように設計しますか？

どのように解決するのですか？

間違いなく1番の方法です。

クライアントが複数のGraphQLサービスと会話することは（アプローチ2のように）、そもそもGraphQLを使用する目的を完全に打ち消します。 全体 アプリケーションのデータを1回のラウンドトリップでフェッチできるようにします。

を持つことは シェアードナッシング アーキテクチャは、マイクロサービスの観点からは合理的に見えるかもしれませんが、クライアントサイドのコードにとっては、絶対的な悪夢です。 すべて のクライアントの 絶対に後悔しますよ。

GraphQLとマイクロサービスの相性は抜群です。なぜなら、GraphQLはマイクロサービスアーキテクチャを採用していることをクライアントから隠蔽できるからです。バックエンドの観点では、すべてをマイクロサービスに分割したいが、フロントエンドの観点では、すべてのデータが単一のAPIから来るようにしたいのでしょう。GraphQLの使用は、私が知る限り、その両方を可能にする最良の方法です。バックエンドをマイクロサービスに分割しながらも、すべてのアプリケーションに単一のAPIを提供し、異なるサービスからのデータ間のジョインを可能にするのです。

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