Cum faci caching pentru un API GraphQL?

Question

IT Interview Practice · Accepted Answer

Caching-ul în GraphQL este mai greu decât în REST deoarece există un singur endpoint, iar cererile sunt de obicei POST, așa că cache-ul HTTP bazat pe URL nu funcționează din start. În schimb, faci caching pe trei straturi: **client**, **transport/CDN** și **server**.

## Cache normalizat pe client

Apollo Client și Relay stochează rezultatele într-un **cache normalizat** cheiat după `__typename` + `id`. Fiecare obiect este stocat o singură dată; interogări diferite care fac referire la același `User:1` îl partajează, așa că o mutație care actualizează o entitate reîmprospătează automat fiecare vizualizare.

```graphql
# Ambele interogări scriu în aceeași intrare normalizată User:1 din cache-ul clientului
query A { user(id: "1") { id name } }
query B { post(id: "9") { author { id name } } }  # author este tot User:1
```

De aceea câmpurile ar trebui să returneze `id` — cache-ul are nevoie de o cheie stabilă pentru a deduplica.

## Persisted queries + CDN

**Persisted queries** înlocuiesc șirul interogării cu un hash. Clientul trimite un hash scurt în locul unui corp POST lung; serverul caută interogarea înregistrată.

```js
// Automatic Persisted Queries: mai întâi un GET minuscul doar cu hash-ul
// GET /graphql?extensions={"persistedQuery":{"sha256Hash":"abc..."}}
// -> pentru că este un GET cu o cheie stabilă, un CDN poate face cache RĂSPUNSULUI la edge
```

Transformarea interogărilor de citire în GET-uri cacheabile permite unui **CDN** să le servească la edge și reduce payload-urile. Indiciile `@cacheControl` (max-age, scope) permit serverului să declare TTL-uri per câmp pe care CDN-ul și cache-ul serverului Apollo le respectă.

## Pe partea de server

Un cache de răspuns (de ex. cel al Apollo) cheiat după interogare + variabile + scope de autentificare evită re-rularea resolverelor; DataLoader se ocupă de deduplicarea per-cerere (o preocupare diferită — nu este un cache între cereri).

## De ce contează

Designul cu un singur endpoint/POST strică caching-ul HTTP naiv, așa că intervievatorii vor să audă răspunsul **pe straturi**: cache de entități normalizat pe client, persisted queries + `@cacheControl` pentru a debloca caching-ul CDN/edge și unde se încadrează DataLoader (per-cerere, nu între cereri).

Cache normalizat pe client

Persisted queries + CDN

Pe partea de server

De ce contează

Întrebări conexe