キャッシュ

オブジェクト識別子を提供することで、クライアントはリッチなキャッシュを構築できます

エンドポイントベースのAPIでは、クライアントはHTTPキャッシュを使用してリソースの再取得を簡単に回避し、2つのリソースが同じかどうかを識別できます。これらのAPIのURLは、クライアントがキャッシュの構築に活用できる**グローバルに一意の識別子**です。しかし、GraphQLには、特定のオブジェクトに対してこのグローバルに一意の識別子を提供するURLのようなプリミティブがありません。したがって、APIがクライアントが使用するためのかかる識別子を公開することをお勧めします。

グローバルに一意のID#

これを実現するための一つのパターンは、`id`のようなフィールドをグローバルに一意の識別子として予約することです。このドキュメント全体で使用されているスキーマ例はこのアプローチを使用しています

これは、クライアント開発者に提供する強力なツールです。リソースベースのAPIのURLがグローバルに一意のキーを提供するのと同じように、このシステムの`id`フィールドはグローバルに一意のキーを提供します。

バックエンドが識別子にUUIDのようなものを使用している場合、このグローバルに一意のIDを公開することは非常に簡単です! バックエンドにまだすべてのオブジェクトに対してグローバルに一意のIDがない場合、GraphQLレイヤーはこのIDを構築する必要がある場合があります。多くの場合、これは型の名前をIDに追加して識別子として使用するのと同じくらい簡単です。サーバーは、そのIDをbase64エンコードして不透明にすることができます。

必要に応じて、このIDを使用して、グローバルオブジェクト識別の`node`パターンを操作できます。

既存のAPIとの互換性#

この目的で`id`フィールドを使用する場合の懸念事項の1つは、GraphQL APIを使用するクライアントが既存のAPIとどのように連携するかということです。たとえば、既存のAPIがタイプ固有のIDを受け入れるが、GraphQL APIがグローバルに一意のIDを使用する場合、両方を同時に使用するのは難しい場合があります。

このような場合、GraphQL APIは以前のAPIのIDを別のフィールドに公開できます。これにより、両方の利点を得ることができます

• GraphQLクライアントは、グローバルに一意のIDを取得するための一貫したメカニズムに引き続き依存できます。
• 以前のAPIで作業する必要があるクライアントは、オブジェクトから`previousApiId`を取得して使用することもできます。

代替案#

グローバルに一意のIDは過去に強力なパターンであることが証明されていますが、使用できる唯一のパターンではなく、すべての状況に適しているわけでもありません。クライアントが本当に必要とする重要な機能は、キャッシュのためにグローバルに一意の識別子を導き出す機能です。サーバーにそのIDを導き出させるとクライアントが簡素化されますが、クライアントも識別子を導き出すことができます。多くの場合、これはオブジェクトのタイプ（`__typename`でクエリされた）と、タイプに一意の識別子を組み合わせるのと同じくらい簡単です。

さらに、既存のAPIをGraphQL APIに置き換える場合、GraphQLのすべてのフィールドがグローバルに一意に変更された`id`**を除いて**同じであれば、混乱を招く可能性があります。これは、`id`をグローバルに一意のフィールドとして使用しないことを選択するもう1つの理由になります。