複数のカスタムエンドポイントのユースケース
GraphQLは、データをクエリするための単一エンドポイントを公開することが一般的です。ただし、各エンドポイントがカスタマイズされたスキーマを提供する複数のカスタムエンドポイントを公開する方が適切な場合があります。これにより、アクセスするエンドポイントを切り替えるだけで、異なるユーザーやアプリケーションに対して異なる動作を提供できます。
GraphQLで複数のエンドポイントを公開することは、RESTと同じではありません。RESTでは各エンドポイントが事前に定義されたリソースやリソースセットへのアクセスを提供しますが、複数の GraphQLエンドポイントはそれぞれ引き続きスキーマの全データへのアクセスを提供し、必要なものだけを取得できます。これは通常のGraphQLの動作であり、異なるスキーマからデータにアクセスできる点が追加されています。
この機能は、複数のデータソースを単一の統合グラフに組み込むことを可能にするスキーマスティッチングやフェデレーションとも異なります。複数のエンドポイントでは、複数のスキーマを扱います。それぞれを独立したものとして扱うことが目的であり、より大きなスキーマの一部としてではありません。
異なるスキーマを公開することで、複数の独立したグラフへのアクセスを提供できます。GraphQLの創設者であるLee Byron氏はこれが有用な場面について説明しています。
A good example of this might be if you've company is centered around a product and has built a graphql API for that product, and then decides to expand into a new business domain with a new product that doesn't relate to the original product. It could be a burden for both of these unrelated products to share a single API and two separate endpoints with different schema may be more appropriate.
[...] Another example is [...] - you may have a separate internal-only endpoint that is a superset of your external GraphQL API. Facebook uses this pattern and has two endpoints, one internal and one external. The internal one includes internal tools which can interact with product types.
複数のGraphQLエンドポイントを公開することが適切な追加のユースケースを見ていきましょう。
管理者用エンドポイントと公開エンドポイントを分離して公開する
会社内のすべてのデータに単一グラフを使用している場合、アクセス制御ポリシーを設定することで、GraphQLスキーマ内のさまざまなフィールドへのアクセス権を持つユーザーを検証できます。たとえば、ログイン済みユーザーや特定のロールを持つユーザーのみがアクセスできるようにフィールドを設定できます。
ただし、機密情報や秘密情報を含むフィールドが存在し、そのようなフィールドが意図しない関係者に絶対にアクセスされるべきでない場合は、最初からこれらのフィールドを公開スキーマに公開せず、チームのみがアクセスできるプライベートスキーマにのみ公開する方が望ましいです。この戦略により、ソフトウェアのバグやスキーマ設定時の不注意など、意図しない問題からプライベートデータを保護し、特定のIPからの訪問者のみにプライベートエンドポイントへのアクセスを許可することでセキュリティをさらに強化できます。
したがって、AdminスキーマとPublicスキーマという2つの独立したスキーマを作成し、それぞれ/graphql/admin（特定のIPからの訪問者のみアクセス可能）と/graphql/public（全員がアクセス可能）のエンドポイントで公開できます。
プライベート情報へのアクセスをより安全に制限する
このセクションは前のセクションの一般化です。公開と管理者の区別だけでなく、あるユーザーグループが別のユーザーグループの情報に確実にアクセスできないようにする必要があるあらゆる状況が対象です。
たとえば、異なるクライアントにカスタマイズされたスキーマを作成する必要がある場合は、各クライアントにカスタムエンドポイント（/graphql/some-client、/graphql/another-clientなど）を公開できます。これは、同一の統合スキーマへのアクセスを許可してアクセス制御で検証するよりも安全な場合があります。
異なるアプリケーションに異なる動作を提供する
同一データソースにアクセスする異なるアプリケーションに、それぞれ異なる動作を付与できます。
たとえば、Redditはデスクトップブラウザからアクセスした場合とモバイルブラウザからアクセスした場合で異なるレスポンスを返します。デスクトップブラウザからは、ログインしているかどうかに関わらず、コンテンツを直接表示できます。
ただし、モバイルからアクセスする場合は、コンテンツにアクセスするためにログインが必要であり、アプリの使用が推奨されます。
この異なる動作は、DesktopスキーマとMobileスキーマという2つのスキーマを作成し、それぞれ/graphql/desktopと/graphql/mobileで公開することで実現できます。
サイトを異なる言語で生成する
同じサイトを異なる言語で生成したい場合は、英語であれば/graphql/en、フランス語であれば/graphql/frのように、言語コードをカスタムエンドポイント構造の一部にすることができます。そうすることで、GraphQLサーバーはこの情報を取得し、データを目的の言語に翻訳できます。
最後に、静的サイトジェネレーターでこれらの各エンドポイントを指定することで、サイトをいずれかの言語で生成します。
本番リリース前にアップグレードされたスキーマをテストする
GraphQLスキーマをアップグレードし、一部のユーザーに事前にテストしてもらいたい場合は、この新しいスキーマを/graphql/upcomingエンドポイントで公開できます。さらに、DEVからスキーマを継続的にデプロイする/graphql/bleeding-edgeエンドポイントも公開できます。
BfFアプローチのサポート
Backend-for-Frontends（略してBfF）は、各クライアントがAPIを「所有」し、自分自身の要件に基づいて最適なバージョンを生成できるように、異なるクライアントのために異なるAPIを生成するアプローチです。
このモデルでは、カスタムBfFがバックエンドサービスとクライアントの間の仲介役を担います。
このモデルは、GraphQLにおいて、すべてのBfFを複数のエンドポイントを持つ単一のGraphQLサーバーで実装し、各エンドポイントが特定のBfF/クライアント（/graphql/mobileや/graphql/webなど）を担当することで実現できます。
