At cache GraphQL er sværere end REST, fordi der er ét endpoint, og forespørgsler er som regel POST, så URL-baseret HTTP-caching virker ikke uden videre. I stedet cacher du i tre lag: klient, transport/CDN og server.
Apollo Client og Relay lagrer resultater i en , nøglet på + . Hvert objekt lagres én gang; forskellige forespørgsler, der refererer til samme , deler det, så en mutation, der opdaterer én entitet, opdaterer automatisk alle visninger.
__typenameidUser:1# 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
Det er derfor, felter bør returnere id — cachen har brug for en stabil nøgle til at deduplikere.
Persisted queries erstatter forespørgselsstrengen med et hash. Klienten sender et kort hash i stedet for en lang POST-body; serveren slår den registrerede forespørgsel op.
// 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
At gøre læse-forespørgsler til cachebare GET'er lader et CDN servere dem på edge og formindsker payloads. @cacheControl-hints (max-age, scope) lader serveren deklarere per-felt-TTL'er, som CDN'et og Apollo-serverens cache respekterer.
En response-cache (fx Apollos), nøglet på forespørgsel + variabler + auth-scope, undgår at køre resolvers igen; DataLoader håndterer per-request-deduplikering (et andet anliggende — det er ikke en cross-request-cache).
Designet med ét endpoint/POST bryder naiv HTTP-caching, så interviewere vil høre det lagdelte svar: normaliseret entitets-cache på klienten, persisted queries + @cacheControl for at låse op for CDN/edge-caching, og hvor DataLoader passer ind (per-request, ikke cross-request).
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér