أنت في صعوباتٍ بشأن موثوقية الشبكة. تُعد ذاكرة التخزين المؤقت لبروتوكول HTTP في المتصفح خط الدفاع الأول، ولكن كما تعلمت، لا تكون فعالة إلا عند تحميل إصدارات مختلفة من عناوين URL التي زرتها في السابق. ولا يكفي ذاكرة التخزين المؤقت لـ HTTP وحدها.
لحسن الحظ، تتوفر أداتان جديدتان يمكنك من خلالهما تحويل النتيجة إلى صالحك: مشغِّلو الخدمات وواجهة برمجة التطبيقات Cache Storage API. نظرًا لاستخدامهما معًا غالبًا، فمن الجدير التعرف علىهما معًا في نفس الوقت.
مشغِّلو الخدمات
يتم دمج مشغّل الخدمة في المتصفح ويتم التحكّم فيه من خلال رمز JavaScript إضافي الذي تكون مسؤولاً عن إنشائه. يمكنك نشر هذا إلى جانب الملفات الأخرى التي تشكل تطبيق الويب الفعلي.
لدى عامل الخدمات بعض القوى الخاصة. ومن بين واجبات أخرى، ينتظر التطبيق بصبر حتى يقدم تطبيق الويب طلبًا صادرًا، ثم يبدأ في التنفيذ من خلال اعتراضه. ولك مطلق الحرية في اتخاذ الإجراءات التي يتخذها مشغّل الخدمات بشأن هذا الطلب الذي تم اعتراضه.
بالنسبة إلى بعض الطلبات، قد يكون الإجراء الأفضل هو السماح بمواصلة الطلب على الشبكة، تمامًا مثلما يحدث إذا لم يكن هناك عامل خدمات على الإطلاق.
ومع ذلك، يمكنك الاستفادة من الطلبات الأخرى بمرونة أكبر من ذاكرة التخزين المؤقت لبروتوكول HTTP في المتصفح، وعرض استجابة سريعة بشكل موثوق به بدون الحاجة إلى القلق بشأن الشبكة. وهذا يستلزم استخدام الجزء الآخر من اللغز: واجهة برمجة تطبيقات ذاكرة التخزين المؤقت.
واجهة برمجة التطبيقات Cache Storage API
تفتح واجهة برمجة التطبيقات Cache Storage API مجموعة جديدة كليًا من الاحتمالات، من خلال منح المطوّرين إمكانية التحكّم الكامل في محتوى ذاكرة التخزين المؤقت. فبدلاً من الاعتماد على مزيج من عناوين HTTP وheuristics المضمنة في المتصفح، تعرض واجهة برمجة تطبيقات ذاكرة التخزين المؤقت منهجًا يستند إلى الرمز للتخزين المؤقت. تكون واجهة برمجة التطبيقات Cache Storage API مفيدة على وجه الخصوص عند استدعائها من JavaScript لمشغِّل الخدمة.
مهلاً، هل هناك ذاكرة تخزين مؤقت أخرى يجب التفكير فيها الآن؟
من المحتمل أنك تطرح على نفسك أسئلة مثل "هل ما زال أحتاج إلى تهيئة عناوين HTTP؟" و"ماذا يمكنني أن أفعل بذاكرة التخزين المؤقت الجديدة هذه التي لم تكن ممكنة في ذاكرة التخزين المؤقت لبروتوكول HTTP؟" لا داعي للقلق، فهذه ردود فعل طبيعية.
ولا يزال ننصحك بضبط عناوين Cache-Control على خادم الويب، حتى إذا كنت تعرف أنّك تستخدم Cache Storage API. يمكنك عادةً الإفلات من خلال ضبط Cache-Control: no-cache لعناوين URL التي لم يتم تحويلها، و/أو Cache-Control: max-age=31536000 لعناوين URL التي تحتوي على معلومات حول الإصدارات، مثل علامات التجزئة.
عند ملء ذاكرة التخزين المؤقت لواجهة برمجة التطبيقات Cache Storage API، يتحقّق المتصفِّح تلقائيًا من البحث عن الإدخالات الحالية في ذاكرة التخزين المؤقت لبروتوكول HTTP ويستخدم هذه الإدخالات في حال العثور عليها. وإذا كنت تضيف عناوين URL ذات إصدارات مختلفة إلى ذاكرة التخزين المؤقت
لواجهة برمجة تطبيقات التخزين في ذاكرة التخزين المؤقت، يتجنب المتصفح طلب الشبكة الإضافي. ويتمثل الجانب العكسي في أنّه إذا كنت تستخدم عناوين Cache-Control تم ضبطها بشكل غير صحيح، مثل تحديد مدة طويلة لذاكرة التخزين المؤقت لعنوان URL لم يتم إصداره، قد ينتهي بك الأمر
بحدوث مشكلة، وذلك بإضافة المحتوى القديم إلى واجهة برمجة تطبيقات ذاكرة التخزين المؤقت. يعد ترتيب سلوك ذاكرة التخزين المؤقت لبروتوكول HTTP
شرطًا أساسيًا لاستخدام واجهة برمجة تطبيقات ذاكرة التخزين المؤقت للتخزين المؤقت بشكل فعال.
أما بالنسبة إلى ما أصبح ممكنًا الآن مع واجهة برمجة التطبيقات الجديدة هذه، فإن الإجابة هي: الكثير. تتضمن بعض الاستخدامات الشائعة التي قد تكون صعبة أو مستحيلة باستخدام ذاكرة التخزين المؤقت HTTP فقط ما يلي:
- استخدام أسلوب "إعادة التحميل في الخلفية" للمحتوى المخزَّن مؤقتًا والمعروف باسم "القديمة أثناء إعادة التحقق"
- يمكنك فرض حدّ أقصى على عدد مواد العرض التي سيتم تخزينها مؤقتًا، وتطبيق سياسة مخصّصة لانتهاء الصلاحية لإزالة السلع عند بلوغ هذا الحدّ.
- المقارنة بين استجابات الشبكة المُخزَّنة مؤقتًا سابقًا واستجابات الشبكة الحديثة لمعرفة ما إذا كان قد حدث أي تغيير، وتمكين المستخدم من تحديث المحتوى (باستخدام زر، على سبيل المثال) عندما يتم تحديث البيانات فعليًا.
يمكنك الاطّلاع على ذاكرة التخزين المؤقت لواجهة برمجة التطبيقات: دليل سريع للحصول على مزيد من المعلومات.
صواميل ومسامير واجهة برمجة التطبيقات
هناك بعض الأشياء التي يجب مراعاتها فيما يتعلق بتصميم واجهة برمجة التطبيقات:
- ويتم استخدام كائنات
Requestكمفاتيح فريدة عند القراءة والكتابة في ذاكرات التخزين المؤقت هذه. وتسهيلاً لك، يمكنك إدخال سلسلة عنوان URL، مثل'https://example.com/index.html'، كمفتاح بدلاً من عنصرRequestفعلي، وستتعامل واجهة برمجة التطبيقات مع ذلك تلقائيًا نيابةً عنك. - يتم استخدام كائنات
Responseكقيم في ذاكرات التخزين المؤقت هذه. - ويتم تجاهل عنوان
Cache-ControlفيResponseمحدَّد بشكل فعّال عند تخزين البيانات مؤقتًا. لا توجد عمليات فحص تلقائية أو مدمجة لانتهاء الصلاحية أو مدى الحداثة، وبعد تخزين أحد العناصر في ذاكرة التخزين المؤقت، سيبقى ظاهرًا إلى أن يزيله الرمز البرمجي بشكل صريح. (هناك مكتبات لتبسيط صيانة ذاكرة التخزين المؤقت نيابةً عنك. وسيتم تناولها لاحقًا في هذه السلسلة). - وعلى عكس واجهات برمجة التطبيقات القديمة والمتزامنة مثل
LocalStorage، تكون جميع عمليات واجهة برمجة تطبيقات Cache Storage API غير متزامنة.
تحويلة سريعة: الوعود وعدم المزامنة/الانتظار
يستخدم مشغّلو الخدمات وواجهة برمجة التطبيقات Cache Storage API
مفاهيم البرمجة غير المتزامنة.
وبشكل خاص، يعتمدون بشكل كبير على الوعود التي تمثل النتيجة المستقبلية
للعمليات غير المتزامنة. يجب أن تتعرف على
الوعود
وبنية
async/await
ذات الصلة قبل البدء.
لا تنشر هذا الرمز... بعد
وعلى الرغم من أنّها توفّر أساسًا مهمًا ويمكن استخدامها كما هي، فإنّ كلاً من مشغّلي الخدمات وواجهة برمجة تطبيقات Cache Storage API هما وحدات أساسية ذات مستوى أقل بشكل فعّال، مع عدد من الحالات الهامشية و "الأمور". تتوفر بعض الأدوات ذات المستوى الأعلى التي يمكنها المساعدة في تسهيل الوحدات الصعبة في واجهات برمجة التطبيقات هذه وتوفير كل ما تحتاجه لإنشاء عامل خدمات جاهز للإنتاج. يتناول الدليل التالي إحدى الأدوات التالية: Workbox.