Caching GraphQL is harder than REST because there is one endpoint and requests are usually POST, so URL-based HTTP caching does not work out of the box. You cache at three layers instead: client, transport/CDN, and server.
Apollo Client and Relay store results in a keyed by + . Every object is stored once; different queries that reference the same share it, so a mutation that updates one entity refreshes every view automatically.
__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
This is why fields should return id — the cache needs a stable key to deduplicate.
Persisted queries replace the query string with a hash. The client sends a short hash instead of a long POST body; the server looks up the registered query.
// 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
Turning read queries into cacheable GETs lets a CDN serve them at the edge, and shrinks payloads. @cacheControl hints (max-age, scope) let the server declare per-field TTLs the CDN and Apollo server cache respect.
A response cache (e.g. Apollo's) keyed by the query + variables + auth scope avoids re-running resolvers; DataLoader handles per-request de-duplication (a different concern — it is not a cross-request cache).
The single-endpoint/POST design breaks naive HTTP caching, so interviewers want to hear the layered answer: normalized entity cache on the client, persisted queries + @cacheControl to unlock CDN/edge caching, and where DataLoader fits (per-request, not cross-request).
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate