GraphQL cache করা REST-এর চেয়ে কঠিন কারণ এখানে একটিমাত্র endpoint থাকে এবং request সাধারণত POST হয়, তাই URL-ভিত্তিক HTTP caching সরাসরি কাজ করে না। এর বদলে আপনি তিনটি স্তরে cache করেন: client, transport/CDN, এবং server।
Apollo Client এবং Relay ফলাফলগুলো একটি -এ সংরক্ষণ করে, যার key হলো + । প্রতিটি 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
এ কারণেই field-গুলোর id ফেরত দেওয়া উচিত — deduplicate করতে cache-এর একটি স্থিতিশীল key দরকার।
Persisted query 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 query-গুলোকে cacheable GET-এ পরিণত করলে একটি CDN সেগুলোকে edge-এ পরিবেশন করতে পারে, এবং payload ছোট হয়। @cacheControl hint (max-age, scope) server-কে প্রতি-field TTL ঘোষণা করতে দেয়, যা CDN ও Apollo server cache মেনে চলে।
query + variables + auth scope দিয়ে key করা একটি response cache (যেমন Apollo-এর) resolver পুনরায় চালানো এড়ায়; DataLoader প্রতি-request de-duplication সামলায় (এটি ভিন্ন একটি বিষয় — এটি cross-request cache নয়)।
single-endpoint/POST নকশা naive HTTP caching ভেঙে দেয়, তাই interviewer-রা স্তরভিত্তিক উত্তর শুনতে চান: client-এ normalized entity cache, CDN/edge caching খুলে দিতে persisted query + @cacheControl, এবং DataLoader কোথায় খাপ খায় (প্রতি-request, cross-request নয়)।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন