GraphQL ને cache કરવું REST કરતાં અઘરું છે કારણ કે એક જ endpoint હોય છે અને requests સામાન્ય રીતે POST હોય છે, તેથી URL-based HTTP caching સીધું કામ કરતું નથી. તેની બદલે તમે ત્રણ layers પર cache કરો છો: client, transport/CDN, અને server.
Apollo Client અને Relay results ને + દ્વારા key કરેલી માં સંગ્રહે છે. દરેક object એક વાર સંગ્રહાય છે; એ જ નો સંદર્ભ આપતી અલગ queries તેને શેર કરે છે, તેથી એક entity ને update કરતું mutation દરેક view ને આપોઆપ refresh કરે છે.
__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
એટલા માટે fields એ id પરત કરવો જોઈએ — cache ને deduplicate કરવા માટે સ્થિર key ની જરૂર છે.
Persisted queries query string ને hash વડે બદલે છે. Client લાંબા POST body ને બદલે એક ટૂંકો hash મોકલે છે; server registered query ને lookup કરે છે.
// 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
Read queries ને cacheable GETs માં ફેરવવાથી CDN તેમને edge પર serve કરી શકે છે, અને payloads નાના થાય છે. @cacheControl hints (max-age, scope) server ને per-field TTLs જાહેર કરવા દે છે જેને CDN અને Apollo server cache માન આપે છે.
Query + variables + auth scope દ્વારા key કરેલી response cache (દા.ત. Apollo ની) resolvers ને ફરીથી ચલાવવાનું ટાળે છે; DataLoader per-request de-duplication સંભાળે છે (એ અલગ ચિંતા છે — તે cross-request cache નથી).
Single-endpoint/POST design naive HTTP caching ને તોડે છે, તેથી interviewers layered જવાબ સાંભળવા માગે છે: client પર normalized entity cache, CDN/edge caching ને અનલોક કરવા persisted queries + @cacheControl, અને DataLoader ક્યાં ફિટ થાય છે (per-request, cross-request નહીં).
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો