GraphQL cache गर्नु REST भन्दा कठिन छ किनभने एउटै endpoint हुन्छ र requests सामान्यतया POST हुन्छन्, त्यसैले URL-आधारित HTTP caching सिधै काम गर्दैन। बरु तपाईंले तीन तह मा cache गर्नुहुन्छ: client, transport/CDN, र server।
Apollo Client र Relay ले results लाई + द्वारा keyed मा भण्डारण गर्छन्। हरेक object एक पटक भण्डारण हुन्छ; उही लाई सन्दर्भ गर्ने फरक query हरूले त्यसलाई साझा गर्छन्, त्यसैले एउटा 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 ले दर्ता गरिएको 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
पढ्ने query हरूलाई cacheable GET मा बदल्नाले CDN लाई तिनीहरूलाई edge मा serve गर्न दिन्छ, र payload हरू सानो पार्छ। @cacheControl hints (max-age, scope) ले server लाई प्रति-field TTL घोषणा गर्न दिन्छ जसलाई 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 भाँच्छ, त्यसैले interviewer हरू तहगत जवाफ सुन्न चाहन्छन्: client मा normalized entity cache, CDN/edge caching खोल्न persisted queries + @cacheControl, र DataLoader कहाँ फिट हुन्छ (per-request, cross-request होइन)।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्