مشغّلو الخدمات وواجهة برمجة التطبيقات cache Storage

Jeff Posnick

تواجهك مشكلة في موثوقية الشبكة. إنّ ذاكرة التخزين المؤقت لبروتوكول HTTP في المتصفّح هي أول خط دفاع، ولكن كما لاحظت، لا تكون فعالة إلا عند تحميل عناوين URL التي تتضمّن إصدارات مختلفة وسبق لك زيارتها. إنّ ذاكرة التخزين المؤقت لبروتوكول HTTP وحدها ليست كافية.

لحسن الحظ، تتوفّر أداتان جديدتان للمساعدة في تحسين الأداء: خدمة العمال وCache Storage API. وبما أنّه يتم استخدامهما معًا كثيرًا، من المفيد التعرّف عليهما في الوقت نفسه.

مشغّلو الخدمات

يتم دمج عامل الخدمة في المتصفّح ويتم التحكّم فيه من خلال رمز برمجي إضافي قليل باستخدام JavaScript تكون أنت المسؤول عن إنشائه. ويتم نشر هذا الملف إلى جانب الملفات الأخرى التي تشكّل تطبيق الويب الفعلي.

يمتلك موظّف الخدمة بعض الصلاحيات الخاصة. ومن بين مهامه الأخرى، ينتظر بصبر لإرسال طلب برمجي من تطبيق الويب، ثم يتدخل في العملية ويinterceptه. إنّ الإجراء الذي يتّخذه عامل الخدمة بشأن هذا الطلب الذي تم اعتراضه هو قرار يعود إليك.

بالنسبة إلى بعض الطلبات، قد يكون أفضل إجراء هو السماح للطلب بمواصلة الانتقال إلى الشبكة، تمامًا كما سيحدث في حال عدم توفّر عامل خدمة على الإطلاق.

بالنسبة إلى الطلبات الأخرى، يمكنك الاستفادة من ميزة أكثر مرونة مقارنةً بذاكرة التخزين المؤقت لبروتوكول HTTP في المتصفّح، وتقديم استجابة سريعة وموثوقة بدون القلق بشأن الشبكة. ويتطلّب ذلك استخدام القطعة الأخرى من اللغز: واجهة برمجة التطبيقات Cache Storage API.

واجهة برمجة التطبيقات Cache Storage API

توفّر واجهة برمجة التطبيقات Cache Storage API مجموعة جديدة تمامًا من الاحتمالات، من خلال منح المطوّرين التحكّم الكامل في محتوى ذاكرة التخزين المؤقت. بدلاً من الاعتماد على مجموعة من عناوين HTTP والإرشادات المضمّنة في المتصفّح، تعرض Cache Storage API نهجًا مستندًا إلى الرموز البرمجية للتخزين المؤقت. تكون واجهة برمجة التطبيقات 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 Storage API، سيتجنّب المتصفّح إرسال طلب إضافي إلى الشبكة. ينطبق العكس على ذلك، فإذا كنت تستخدم رؤوس Cache-Control تم ضبطها بشكلٍ خاطئ، مثل تحديد مدة تخزين مؤقت طويلة لعنوان URL غير مرتبط بإصدار، قد يؤدي ذلك إلى تفاقم المشكلة من خلال إضافة هذا المحتوى القديم إلى واجهة برمجة التطبيقات Cache Storage API. إنّ ترتيب سلوك ذاكرة التخزين المؤقت على HTTP هو شرط أساسي لاستخدام واجهة برمجة التطبيقات Cache Storage API بفعالية.

في ما يتعلّق بالميزات التي يمكن تحقيقها الآن باستخدام واجهة برمجة التطبيقات الجديدة هذه، الإجابة هي: الكثير. تشمل بعض استخدامات ملف التخزين المؤقت لبروتوكول HTTP الشائعة التي قد تكون صعبة أو مستحيلة باستخدام ذاكرة التخزين المؤقت لبروتوكول HTTP فقط ما يلي:

• استخدِم أسلوب "التحديث في الخلفية" للمحتوى المخزّن مؤقتًا، والمعروف باسم stale-while-revalidate.
• يمكنك فرض حد أقصى لعدد مواد العرض التي يتم تخزينها مؤقتًا، وتطبيق سياسة انتهاء صلاحية مخصّصة لإزالة العناصر عند بلوغ هذا الحدّ.
• قارِن بين البيانات المخزّنة مؤقتًا في السابق والاستجابات الجديدة من الشبكة لمعرفة ما إذا كان هناك أي تغيير، وأتِح للمستخدم تعديل المحتوى (باستخدام زر مثلاً) عند تعديل البيانات فعليًا.

اطّلِع على Cache API: دليل سريع للاطّلاع على مزيد من المعلومات.

أساسيات واجهة برمجة التطبيقات

هناك بعض النقاط التي يجب أخذها في الاعتبار بشأن تصميم واجهة برمجة التطبيقات:

• يتم استخدام عناصر Request كمفاتيح فريدة عند القراءة والكتابة في هذه الذاكرات التخزينية المؤقتة. لتسهيل الأمر، يمكنك إدخال سلسلة عنوان URL مثل 'https://example.com/index.html' كمفتاح بدلاً من عنصر Request فعلي، وستتولى واجهة برمجة التطبيقات ذلك تلقائيًا نيابةً عنك.
• تُستخدَم عناصر Response كقيم في هذه الذاكرات المؤقتة.
• يتم تجاهل عنوان Cache-Control في Response معيّن بشكل فعّال عند تخزين البيانات مؤقتًا. لا تتوفّر عمليات فحص تلقائية أو مضمّنة لصلاحية البيانات أو حداثتها، وبعد تخزين عنصر في ذاكرة التخزين المؤقت، سيظل متوفّرًا إلى أن يزيله رمزك البرمجي صراحةً. (تتوفّر مكتبات لتبسيط صيانة ملف التخزين المؤقت نيابةً عنك. وسيتم تناولها لاحقًا في هذه السلسلة.)
• على عكس واجهات برمجة التطبيقات القديمة المتزامنة، مثل LocalStorage، تكون جميع عمليات Cache Storage API غير متزامنة.

نظرة سريعة على ميزتَي promises وasync/await

يستخدم كلّ من مهام الخدمة وCache Storage API مفاهيم البرمجة غير المتزامنة. وعلى وجه الخصوص، تعتمد هذه الوظائف بشكل كبير على الوعود لتمثيل النتيجة المستقبلية للعمليات غير المتزامنة. يجب التعرّف على التعهدات، والبنية ذات الصلة async/await قبل البدء.

لا تنشئ هذا الرمز البرمجي بعد.

على الرغم من أنّهما يقدّمان أساسًا مهمًا ويمكن استخدامهما كما هما، إلا أنّ كلّ من "خدمة العمال" وCache Storage API هما في الواقع وحدات أساسية من المستوى الأدنى، مع عدد من الحالات الشاذة والمشاكل. هناك بعض الأدوات من المستوى الأعلى التي يمكن أن تساعد في تسهيل الخطوات الصعبة في واجهات برمجة التطبيقات هذه، وتوفير كل ما تحتاجه لإنشاء عامل خدمة جاهز للنشر. يتناول الدليل التالي إحدى هذه الأدوات: Workbox.