GraphQL API はどのようにキャッシュするのか?

Question

IT Interview Practice · Accepted Answer

GraphQL のキャッシュは REST より難しいです。エンドポイントが 1 つで、リクエストが通常 POST であるため、URL ベースの HTTP キャッシュがそのままでは機能しないからです。代わりに 3 つの層でキャッシュします: **クライアント**、**トランスポート/CDN**、**サーバー** です。

## 正規化されたクライアントキャッシュ

Apollo Client と Relay は、結果を `__typename` + `id` をキーとする **正規化キャッシュ** に格納します。すべてのオブジェクトは 1 度だけ格納され、同じ `User:1` を参照する異なるクエリはそれを共有するため、1 つのエンティティを更新する mutation はすべてのビューを自動的に更新します。

```graphql
# Both queries write to the same normalized entry User:1 in the client cache
query A { user(id: "1") { id name } }
query B { post(id: "9") { author { id name } } }  # author is also User:1
```

これが、フィールドが `id` を返すべき理由です — キャッシュが重複排除するために安定したキーを必要とするのです。

## Persisted query + CDN

**Persisted query** はクエリ文字列をハッシュに置き換えます。クライアントは長い POST 本文の代わりに短いハッシュを送信し、サーバーは登録済みのクエリを検索します。

```js
// Automatic Persisted Queries: first a tiny GET with just the hash
// GET /graphql?extensions={"persistedQuery":{"sha256Hash":"abc..."}}
// -> because it's a GET with a stable key, a CDN can cache the RESPONSE at the edge
```

読み取りクエリをキャッシュ可能な GET に変えることで、**CDN** がそれをエッジで配信でき、ペイロードも小さくなります。`@cacheControl` ヒント (max-age、scope) により、サーバーは CDN と Apollo サーバーキャッシュが尊重するフィールドごとの TTL を宣言できます。

## サーバーサイド

クエリ + 変数 + 認証スコープをキーとするレスポンスキャッシュ (例: Apollo のもの) は、リゾルバの再実行を避けます。DataLoader はリクエストごとの重複排除を扱います (これは別の関心事です — クロスリクエストのキャッシュではありません)。

## なぜ重要なのか

単一エンドポイント/POST という設計が素朴な HTTP キャッシュを壊すため、面接官は **層構造** の答えを聞きたがります: クライアント上の正規化エンティティキャッシュ、CDN/エッジキャッシュを解放するための persisted query + `@cacheControl`、そして DataLoader がどこに収まるか (クロスリクエストではなくリクエストごと) です。

正規化されたクライアントキャッシュ

Persisted query + CDN

サーバーサイド

なぜ重要なのか

関連する質問