Bagaimana cara meng-cache sebuah GraphQL API?

Question

IT Interview Practice · Accepted Answer

Meng-cache GraphQL lebih sulit daripada REST karena hanya ada satu endpoint dan request biasanya POST, sehingga HTTP caching berbasis URL tidak jalan begitu saja. Sebagai gantinya Anda meng-cache di tiga lapisan: **client**, **transport/CDN**, dan **server**.

## Normalized client cache

Apollo Client dan Relay menyimpan hasil dalam **normalized cache** yang di-key berdasarkan `__typename` + `id`. Setiap objek disimpan sekali; query berbeda yang mereferensikan `User:1` yang sama akan berbagi objek itu, sehingga sebuah mutation yang memperbarui satu entity menyegarkan setiap tampilan secara otomatis.

```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 field sebaiknya mengembalikan `id` — cache membutuhkan key yang stabil untuk melakukan deduplikasi.

## Persisted query + CDN

**Persisted query** mengganti string query dengan sebuah hash. Client mengirim hash pendek alih-alih body POST yang panjang; server mencari query yang telah teregistrasi.

```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 read query menjadi GET yang bisa di-cache memungkinkan sebuah **CDN** menyajikannya di edge, dan memperkecil payload. Petunjuk `@cacheControl` (max-age, scope) memungkinkan server mendeklarasikan TTL per-field yang dihormati oleh CDN dan cache Apollo server.

## Sisi server

Sebuah response cache (misalnya milik Apollo) yang di-key berdasarkan query + variables + auth scope menghindari eksekusi ulang resolver; DataLoader menangani deduplikasi per-request (kepedulian yang berbeda — ia bukan cache lintas-request).

## Mengapa ini penting

Desain single-endpoint/POST merusak HTTP caching yang naif, sehingga interviewer ingin mendengar jawaban yang **berlapis**: normalized entity cache di client, persisted query + `@cacheControl` untuk membuka caching CDN/edge, dan di mana DataLoader berperan (per-request, bukan lintas-request).

Normalized client cache

Persisted query + CDN

Sisi server

Mengapa ini penting

Pertanyaan terkait