Att cacha GraphQL är svårare än REST eftersom det finns en enda endpoint och förfrågningar oftast är POST, så URL-baserad HTTP-caching fungerar inte direkt. Istället cachar du i tre lager: klient, transport/CDN och server.
Apollo Client och Relay lagrar resultat i en med + som nyckel. Varje objekt lagras en gång; olika frågor som refererar till samma delar det, så en mutation som uppdaterar en entitet uppdaterar automatiskt varje vy.
__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 är därför fält bör returnera id — cachen behöver en stabil nyckel för att deduplicera.
Persisted queries ersätter frågesträngen med en hash. Klienten skickar en kort hash istället för en lång POST-kropp; servern slår upp den registrerade frågan.
// 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
Att omvandla läsfrågor till cachebara GET-anrop låter ett CDN leverera dem vid edge och krymper nyttolasten. @cacheControl-tips (max-age, scope) låter servern deklarera TTL:er per fält som CDN:et och Apollo-serverns cache respekterar.
En svars-cache (t.ex. Apollos) med frågan + variabler + auth-scope som nyckel undviker att köra resolvers på nytt; DataLoader hanterar deduplicering per förfrågan (ett annat problem — det är inte en cache som spänner över flera förfrågningar).
Designen med en enda endpoint/POST bryter naiv HTTP-caching, så intervjuare vill höra det lagrade svaret: normaliserad entitets-cache på klienten, persisted queries + @cacheControl för att låsa upp CDN-/edge-caching, och var DataLoader passar in (per förfrågan, inte över flera förfrågningar).
Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera