Bagaimana anda melakukan caching pada API GraphQL?

Question

IT Interview Practice · Accepted Answer

Caching GraphQL lebih sukar daripada REST kerana terdapat satu endpoint dan permintaan biasanya POST, jadi caching HTTP berasaskan URL tidak berfungsi terus daripada kotak. Sebaliknya anda melakukan caching pada tiga lapisan: **klien**, **pengangkutan/CDN**, dan **pelayan**.

## Cache klien ternormal

Apollo Client dan Relay menyimpan keputusan dalam **cache ternormal (normalized cache)** yang dikunci oleh `__typename` + `id`. Setiap object disimpan sekali; pertanyaan berlainan yang merujuk `User:1` yang sama berkongsinya, jadi mutation yang mengemas kini satu entiti menyegar semula setiap paparan secara automatik.

```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
```

Inilah sebabnya medan patut memulangkan `id` — cache memerlukan kunci yang stabil untuk menyahpendua.

## Persisted queries + CDN

**Persisted queries** menggantikan rentetan pertanyaan dengan hash. Klien menghantar hash pendek dan bukannya badan POST yang panjang; pelayan mencari pertanyaan yang berdaftar.

```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
```

Mengubah pertanyaan baca menjadi GET yang boleh di-cache membolehkan **CDN** menyampaikannya di edge, dan mengecilkan muatan. Petunjuk `@cacheControl` (max-age, scope) membenarkan pelayan mengisytiharkan TTL per-medan yang dihormati oleh CDN dan cache pelayan Apollo.

## Di sebelah pelayan

Satu response cache (cth. milik Apollo) yang dikunci oleh pertanyaan + pembolehubah + skop auth mengelakkan resolver dijalankan semula; DataLoader mengendalikan penyahpenduaan per-permintaan (satu perkara yang berbeza — ia bukan cache merentas-permintaan).

## Mengapa ia penting

Reka bentuk endpoint-tunggal/POST merosakkan caching HTTP yang naif, jadi penemu duga mahu mendengar jawapan **berlapis**: cache entiti ternormal pada klien, persisted queries + `@cacheControl` untuk membuka caching CDN/edge, dan di mana DataLoader sesuai (per-permintaan, bukan merentas-permintaan).

Cache klien ternormal

Persisted queries + CDN

Di sebelah pelayan

Mengapa ia penting

Soalan berkaitan