يشير التخزين المؤقت في وقت التشغيل إلى إضافة الردود تدريجيًا إلى ذاكرة التخزين المؤقت "أثناء التنقل". إنّ التخزين المؤقت في وقت التشغيل لا يساعد في تعزيز موثوقية الطلب الحالي، ولكن يمكن أن يساعد في زيادة موثوقية الطلبات المستقبلية لعنوان URL نفسه.
تُعدّ ذاكرة التخزين المؤقت لبروتوكول HTTP في المتصفح مثالاً على التخزين المؤقت في وقت التشغيل، ولا تتم تعبئتها إلا بعد طلب عنوان URL معيّن. إلا أن عاملي الخدمة يسمحون لك بتنفيذ التخزين المؤقت لوقت التشغيل الذي يتجاوز ما يمكن أن تقدمه ذاكرة التخزين المؤقت HTTP وحدها.
يعد الانتقال إلى موقع استراتيجي
على عكس التخزين المؤقت (الذي يحاول دائمًا عرض مجموعة من الملفات المحددة مسبقًا من ذاكرة التخزين المؤقت)، يمكن أن يجمع التخزين المؤقت لوقت التشغيل بين الوصول إلى الشبكة وذاكرة التخزين المؤقت بعدة طرق. يُشار إلى كل مجموعة بشكل عام باسم استراتيجية التخزين المؤقت. تشمل استراتيجيات التخزين المؤقت الرئيسية ما يلي:
- الشبكة أولاً
- ذاكرة التخزين المؤقت أولاً
- إعادة إثبات الملكية القديمة
الشبكة أولاً
في هذا النهج، يحاول عامل الخدمة أولاً استرداد استجابة من الشبكة. إذا نجح طلب الشبكة، هذا أمر رائع. يتم إرجاع الرد إلى تطبيق الويب، ويتم تخزين نسخة من الرد باستخدام واجهة برمجة تطبيقات مساحة تخزين ذاكرة التخزين المؤقت - إما إنشاء إدخال جديد أو تحديث إدخال سابق لعنوان URL ذاته.
إذا تعذّر طلب الشبكة تمامًا أو استغرق وقتًا طويلاً لعرض استجابة، سيتم عرض أحدث استجابة من ذاكرة التخزين المؤقت بدلاً من ذلك.
ذاكرة التخزين المؤقت أولاً
إنّ استراتيجية التخزين المؤقت أولاً هي عكس الاعتماد على الشبكة أولاً. في هذا النهج، عندما يعترض مشغّل الخدمة طلبًا، يستخدم أولاً واجهة Cache Storage API لمعرفة ما إذا كانت تتوفّر استجابة مخزّنة مؤقتًا أم لا. إذا كان الأمر كذلك، يتم إرجاع هذه الاستجابة إلى تطبيق الويب.
ومع ذلك، إذا كان هناك خطأ في ذاكرة التخزين المؤقت، سينتقل عامل الخدمة إلى الشبكة ويحاول استرداد الاستجابة هناك. بافتراض أن طلب الشبكة ناجح، يتم إرجاعه إلى تطبيق الويب ويتم حفظ نسخة في ذاكرة التخزين المؤقت. وسيتم استخدام هذه النسخة المخزَّنة مؤقتًا لتجاوز الشبكة في المرة التالية التي يتم فيها تقديم طلب للحصول على عناوين URL نفسها.
إعادة إثبات الملكية القديمة
فعملية إعادة التحقق القديمة هي نوع من الهجين. وعند استخدامه، سيتحقق عامل الخدمة على الفور من استجابة مخزَّنة مؤقتًا، وإذا عثر على استجابة، سيعيدها إلى تطبيق الويب.
في هذه الأثناء، بغض النظر عمّا إذا كان هناك تطابق في ذاكرة التخزين المؤقت، يعمل عامل الخدمة أيضًا على تنشيط طلب الشبكة للحصول على استجابة "حديثة". ويتم استخدام هذه الاستجابة لتحديث أي استجابة مخزّنة مؤقتًا مسبقًا. إذا كان فحص ذاكرة التخزين المؤقت الأولي مفقودًا، فيتم أيضًا تمرير نسخة من استجابة الشبكة مرة أخرى إلى تطبيق الويب.
لماذا يجب عليك استخدام Workbox؟
ترتبط استراتيجيات التخزين المؤقت هذه بوصفات الطعام التي تحتاج عادةً إلى إعادة كتابتها في مشغّل الخدمات لديك مرارًا وتكرارًا. وبدلاً من اللجوء إلى ذلك، يوفّر Workbox حزمة منها كجزء من مكتبة الاستراتيجيات الخاصة بها لكي يتسنى لك إحالتها إلى مشغّل الخدمات.
يوفّر Workbox أيضًا إمكانية تحديد الإصدارات، ما يسمح لك بانتهاء صلاحية الإدخالات المخزّنة مؤقتًا تلقائيًا، أو إشعار تطبيق الويب عند توفّر تحديثات لإدخال تم تخزينه مؤقتًا في السابق.
أي من مواد العرض يجب تخزينها مؤقتًا، بأي استراتيجية؟
يمكن اعتبار التخزين المؤقت في وقت التشغيل مكملاً للتخزين المؤقت. وإذا كانت جميع مواد العرض مخزَّنة مؤقتًا بشكل مسبق، تكون قد انتهيت من ذلك، فلا يوجد أي شيء يحتاج إلى تخزينه مؤقتًا في وقت التشغيل. فعلى الرغم من ذلك، من المحتمل أنك لن تعمد إلى حفظ كل شيء مسبقًا، وذلك بالنسبة إلى أي تطبيق ويب معقد نسبيًا.
تُعدّ ملفات الوسائط الأكبر حجمًا ومواد العرض المقدمة من مضيف تابع لجهة خارجية مثل شبكة توصيل المحتوى (CDN) أو ردود واجهة برمجة التطبيقات (API) أمثلة قليلة على أنواع مواد العرض التي لا يمكن تخزينها مؤقتًا بشكل فعال. استخدِم لوحة "الشبكة" في "أدوات مطوري البرامج" لتحديد الطلبات التي تندرج في هذه الفئة، وفكِّر في المفاضلة المناسبة بين الحداثة والموثوقية.
استخدام ميزة "التحقق القديمة أثناء إعادة التحقق" لمنح الأولوية للموثوقية قبل التحديث
وبما أنّ الاستراتيجية القديمة أثناء إعادة التحقّق تعرض استجابة مخزّنة مؤقتًا على الفور تقريبًا، بعد ملء ذاكرة التخزين المؤقت عن طريق الطلب الأول، سينتهي بك الأمر بشهد أداء سريع موثوق به عند استخدام هذه الاستراتيجية. يأتي هذا مع مقايضة استعادة بيانات الاستجابة التي قد تكون قديمة مقارنة بما يمكن استرداده من الشبكة. يعمل استخدام هذه الاستراتيجية على أفضل نحو مع مواد عرض مثل صور الملفات الشخصية للمستخدمين أو استجابات واجهة برمجة التطبيقات الأولية المستخدَمة لتعبئة طريقة عرض، عندما تعلم أنّ عرض عنصر بشكل فوري هو أمر أساسي، حتى إذا كان قيمته قديمة.
استخدام الشبكة أولاً لإعطاء الأولوية للحداثة على الموثوقية
بطريقة ما، فإن استخدام استراتيجية "الشبكة أولاً" يؤدي إلى الاعتراف بالهزيمة في معركتك أمام الشبكة - يتم إعطاء الأولوية لتلك الاستراتيجية، إلا أنّ ذلك يؤدي إلى عدم اليقين بشأن الموثوقية. بالنسبة إلى أنواع معيّنة من مواد العرض، من المفضّل الحصول على رد جديد لاستعادة المعلومات القديمة. ربما تفضّل الحداثة عند تقديم طلب من واجهة برمجة التطبيقات لنص المقالة التي يتم تعديلها بشكل متكرر، على سبيل المثال.
باستخدام استراتيجية تركّز على الشبكة أولاً داخل مشغّل الخدمات، بدلاً من الاكتفاء بمواجهة الشبكة مباشرةً، ستستفيد من إمكانية التراجع إلى شيء ما، حتى إذا كان ردًّا من المحتمل أن يكون قديمًا. لن تكون سريعًا بشكل موثوق، ولكن على الأقل ستكون موثوقًا به أثناء عدم الاتصال بالإنترنت.
استخدام ذاكرة التخزين المؤقت أولاً لعناوين URL المكرّرة
في الاستراتيجية المستندة إلى ذاكرة التخزين المؤقت أولاً، لا يتم تعديل الإدخال بعد تخزينه مؤقتًا. لهذا السبب، تأكد من استخدامه فقط مع مواد العرض التي تعرف أنه من غير المرجح أن تتغير. على وجه الخصوص، تعمل هذه الميزة بشكل أفضل مع عناوين URL التي تحتوي على معلومات حول تحديد الإصدارات، وهي النوع نفسه من عناوين URL التي يجب عرضها أيضًا مع عنوان الاستجابة Cache-Control: max-age=31536000.