التخزين المؤقت في GraphQL أصعب منه في REST لأن هناك نقطة نهاية واحدة والطلبات عادةً POST، لذا لا يعمل التخزين المؤقت لـ HTTP القائم على URL جاهزًا. تخزّن مؤقتًا عبر ثلاث طبقات بدلًا من ذلك: العميل والنقل/CDN والخادم.
يخزّن Apollo Client وRelay النتائج في مفتاحه + . يُخزَّن كل كائن مرة واحدة؛ فالاستعلامات المختلفة التي تشير إلى نفسه تتشاركه، وبذلك يُحدِّث أي mutation يُعدّل كيانًا كل عرض تلقائيًا.
__typenameidUser:1# كلا الاستعلامين يكتبان إلى المدخل المُطبَّع نفسه User:1 في cache العميل
query A { user(id: "1") { id name } }
query B { post(id: "9") { author { id name } } } # author أيضًا User:1
لهذا ينبغي أن تعيد الحقول id — فالـ cache يحتاج مفتاحًا ثابتًا لإزالة التكرار.
تستبدل الاستعلامات المحفوظة (persisted queries) نصّ الاستعلام بتجزئة (hash). يرسل العميل تجزئة قصيرة بدلًا من جسم POST طويل؛ ويبحث الخادم عن الاستعلام المُسجَّل.
// Automatic Persisted Queries: أولًا طلب GET صغير بالتجزئة فقط
// GET /graphql?extensions={"persistedQuery":{"sha256Hash":"abc..."}}
// -> لأنه GET بمفتاح ثابت، يمكن لـ CDN تخزين الاستجابة مؤقتًا عند الحافة (edge)
تحويل استعلامات القراءة إلى طلبات GET قابلة للتخزين المؤقت يتيح لـ CDN تقديمها عند الحافة، ويقلّص الحمولات. تلميحات @cacheControl (max-age، scope) تتيح للخادم إعلان مدد صلاحية (TTL) لكل حقل يحترمها الـ CDN وcache خادم Apollo.
يتجنّب cache استجابة (مثل الذي في Apollo) مفتاحه الاستعلام + المتغيرات + نطاق المصادقة إعادةَ تشغيل الـ resolvers؛ ويتولّى DataLoader إزالة التكرار لكل طلب (وهي مسألة مختلفة — فهو ليس cache عابرًا للطلبات).
تصميم نقطة النهاية الواحدة/POST يكسر التخزين المؤقت الساذج لـ HTTP، لذا يريد المُحاورون سماع الإجابة الطبقية: cache كيانات مُطبَّع على العميل، وpersisted queries + @cacheControl لفتح التخزين المؤقت عبر CDN/الحافة، وأين يقع DataLoader (لكل طلب، لا عبر الطلبات).
مكتبة من أسئلة مقابلات تقنية المعلومات مع إجابات مفصّلة — من المبتدئ إلى المتقدم.
تبرع