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

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

Jeff Posnick

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

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

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

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

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

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

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

واجهة Cache Storage API

Browser Support

Source

تفتح واجهة 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 فقط ما يلي:

استخدِم نهج "إعادة التحميل في الخلفية" للمحتوى المخزَّن مؤقتًا، والمعروف باسم 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.