GraphQL cache करणे REST पेक्षा कठीण आहे कारण एकच endpoint असतो आणि requests सहसा POST असतात, त्यामुळे URL-आधारित HTTP caching थेट चालत नाही. त्याऐवजी तुम्ही तीन layers वर cache करता: client, transport/CDN, आणि server.
Apollo Client आणि Relay results एका मध्ये + नुसार keyed करून साठवतात. प्रत्येक 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 परत करावा — deduplicate करण्यासाठी cache ला एक स्थिर key लागतो.
Persisted queries query string ला एका hash ने बदलतात. Client लांब POST body ऐवजी छोटा hash पाठवतो; server नोंदणीकृत 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
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 नुसार keyed केलेले response cache (उदा. Apollo चे) resolvers पुन्हा चालवणे टाळते; DataLoader per-request de-duplication हाताळतो (हा वेगळा विषय आहे — ते cross-request cache नाही).
एकल-endpoint/POST रचना naive HTTP caching मोडते, त्यामुळे interviewers ना स्तरीय (layered) उत्तर ऐकायचे असते: client वर normalized entity cache, CDN/edge caching उघडण्यासाठी persisted queries + @cacheControl, आणि DataLoader कुठे बसतो (per-request, cross-request नाही).
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या