このエントリは以下のエントリをベースにしています。
This entry is based on the following one, written by Todd Kaplinger (IBM Senior Technical Staff Member).
https://itnext.io/graphql-in-a-microservices-architecture-d17922b886eb

Background

先日のExploring Tokens with Stellarという記事で、ソリューション構築におけるGraphQL stitchingの利用方法を説明しました。どうやってシンプルでエレガントな方法で解決したかを理解するために、まず最初にソリューションの全体的なトポロジをご紹介します。

Exploring Tokens with Stellar
https://itnext.io/exploring-tokens-with-stellar-291172208639
Schema stitching (deprecated)
https://www.apollographql.com/docs/graphql-tools/schema-stitching/

Author note: このトピックに対する強い関心の結果として、token-factoryという組織の下で2019年3月14日にGitHubでソースコードをリリースしました。

Exploring Tokens with Stellar: Creating a unique user experience for exchanging digital tokens
https://github.com/token-factory

Growing pains with micro services in the context of GraphQL

GraphQLを使用してプログラミングモデルを作成したところ、マイクロサービスと12 factorアプリに関する一般的な利点を得ながら、各機能に個別のサービスを用意することで、チームがすばやく作業してプログラミングモデルを反復できるようになりました。一方、これらのサービスを分離すると、チームはサーバーサイドのバッチ処理やキャッシュなどのGraphQLの高度な機能を最大限に活用することができませんでした。

Server-side Batching & Caching
https://graphql.org/learn/best-practices/#server-side-batching-caching

同時に並行して、クライアント側のプログラミングモデルを単純化しようとしていました。明確に定義されたエンドポイントに基づいたApolloによるクライアント初期化の開発は、開発チームにとって別の問題点を生み出していました。

How GraphQL stitching solved our problem

問題点を解決するために、チームは他の人によるGraphQLを使ったマイクロサービスアーキテクチャへのアプローチを見ることにしました。その結果すぐ、schema stitchingのアイデアにすぐに到達しました。私達のマイクロサービスアーキテクチャでは、各マイクロサービスがユニークなエンドポイントと、Ingress Controller用に構成されたルーティングルールを持っていました。この方法では、フロントエンド開発チームが複数のApolloクライアントを定義して種々のエンドポイントをサポートしたり、Ingress Controllerで複雑なルーティングルールをシンプルなコンテキストパスのルーティングルール上に構成して、種々のマイクロサービスのエンドポイントへのルーティングをサポートする必要がありました。Schema stitchingを使うことにより、すべての背後のGraphQL APIの複合ビューを表す様々なマイクロサービスからのスキーマをマージでき、その結果、クライアントのプログラミングモデルがシンプルになりました。結果、プログラム対象の単一のGraphQLエンドポイントになりました。さらにこれにより、以前のアーキテクチャでは不可能だったGraphQLと複数のサービスにわたるバッチクエリを実際に受け入れることができました。

Architecture of GraphQL stitching

GraphQL stitchingは、既存のトポロジ（上記のトポロジを参照）にデプロイされる追加のランタイムサービスです。このソリューションでは、Ingress ControllerとGraphQLエンドポイント間でトラフィックをルーティングするGraphQL Proxyをデプロイしました。コアの機能は、graphql-toolsと呼ばれるコミュニティが提供しているNode.jsモジュールで、実装が必要な一連の明確に定義されたAPIを備えています。stitchingの役割は、定義済みのGraphQLエンドポイントのセットからスキーマをインポートしてマージすることです。このランタイムサービスは、インバウンドリクエストのペイロードを適切なエンドポイントにマッピングし、エラー処理とセキュリティを担当します。

Our approach to GraphQL stitching for our services

下記の例に、スキーマのマージとApolloサーバを様々なGraphQLのmutationやクエリを使った初期化の責任を持つ完全なリソースを含めました。ご注意頂きたいのは、stitchingは実サービスのプロキシとして振る舞い、スキーマがマージされるとstaticになる、という点です。そのため、管理しているつなぎ合わされたGraphQLスキーマが不安定な場合、定期的にこれらのエンドポイントの変更を関しする必要があります。この例では、Kubernetes Readiness and Livenessプローブを使って変更を追跡し、変更時にはサービスのリロードを呼び出しています。

Introducing remote 3rd party schemas

このスクリプトの微妙な項目の1つが22行目にあります。

const STELLAR_NODE_URI = ‘https://core-test.gly.sh/graphql’

GraphQL stitchingへの移行に関する最も強力な機能の1つは、サードパーティAPIを使用できること、そして、既存のGraphQL APIとマージできることです。Stellar開発者コミュニティは非常に活発で、開発者に多くの有用なアセットを提供しています。大きく依存しているのは、StellarテストネットのPostgresデータベースの上にあるGraphQL対応のAPI層です。開発者エコシステムの力を示すこれやその他の素晴らしい例は、Building Stellar Appsの記事に記載されています。このエンドポイントはAPIを拡張し、各主要なコアデータベースに対する豊富なGraphQLクエリのセットを公開します。

Building Stellar Apps
https://itnext.io/building-stellar-apps-36303d0e6f45

Conclusion

REST API中心の世界観から生まれたGraphQLは、複数のフロントエンドアプリケーションに適したきめの細かいクエリを実行できる真のゲームチェンジャーです。GraphQL stitchingを活用することで、将来的にマイクロサービスを追加できる機能を備えた、利用可能でスケーラブルな堅牢なAPI戦略を構築しました。