Caching av GraphQL er vanskeligere enn REST fordi det er ett endepunkt og forespørsler vanligvis er POST, så URL-basert HTTP-caching fungerer ikke rett ut av boksen. I stedet cacher du i tre lag: klient, transport/CDN og server.
Apollo Client og Relay lagrer resultater i en nøklet på + . Hvert objekt lagres én gang; ulike spørringer som refererer til samme deler det, så en mutation som oppdaterer én entitet oppdaterer automatisk alle visninger.
__typenameidUser:1# Begge spørringer skriver til samme normaliserte oppføring User:1 i klient-cachen
query A { user(id: "1") { id name } }
query B { post(id: "9") { author { id name } } } # author er også User:1
Dette er grunnen til at felt bør returnere id — cachen trenger en stabil nøkkel for å deduplisere.
Persisted queries erstatter spørringsstrengen med en hash. Klienten sender en kort hash i stedet for en lang POST-body; serveren slår opp den registrerte spørringen.
// Automatic Persisted Queries: først en liten GET med bare hashen
// GET /graphql?extensions={"persistedQuery":{"sha256Hash":"abc..."}}
// -> fordi det er en GET med en stabil nøkkel, kan en CDN cache SVARET på edge
Å gjøre lesespørringer om til cachebare GET-er lar en CDN servere dem på edge, og krymper payloads. @cacheControl-hint (max-age, scope) lar serveren deklarere TTL-er per felt som CDN-en og Apollo-serverens cache respekterer.
En respons-cache (f.eks. Apollos) nøklet på spørring + variabler + auth-scope unngår å kjøre resolvers på nytt; DataLoader håndterer deduplisering per forespørsel (et annet anliggende — det er ikke en cache på tvers av forespørsler).
Designet med ett endepunkt/POST bryter naiv HTTP-caching, så intervjuere vil høre det lagdelte svaret: normalisert entitets-cache på klienten, persisted queries + @cacheControl for å låse opp CDN-/edge-caching, og hvor DataLoader passer inn (per forespørsel, ikke på tvers av forespørsler).
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner