النسخة التجريبية من واجهة برمجة تطبيقات التوجيه الثابت لمشغّل الخدمة

Brendan Kenny

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

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

يُعدّ التحميل المُسبَق للتنقّل أحد الأساليب التي تُستخدَم لمحاولة حلّ المشكلة، إذ يسمح بتقديم طلبات التنقّل عبر الشبكة في وقتٍ موازي لوقت بدء الخدمة، ولكنّه يقتصر على طلبات التنقّل الأولية ولا يزال يتضمّن الخدمة في المسار الحرج. منذ إطلاق ميزة preloaded navigation (التحميل المُسبَق للتنقّل)، تم بذل جهود متعدّدة لتطوير حلّ أكثر عموميةً للتعامل مع المشاكل، بما في ذلك طرق لمنع حظر بعض الطلبات عند بدء تشغيل worker الخدمة على الإطلاق.

واجهة برمجة التطبيقات Service Worker Static Routing API

بدءًا من الإصدار 116 من Chrome، أصبحت واجهة برمجة التطبيقات التجريبية Service Worker Static Routing API متوفرة لاختبار الخطوة الأولى من هذا الحل. عند تثبيت عامل خدمة، يمكنه استخدام واجهة برمجة التطبيقات Service Worker Static Routing API لتحديد كيفية جلب مسارات موارد معيّنة بشكل صريح.

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

لاستخدام واجهة برمجة التطبيقات، يستدعي عامل الخدمة event.registerRouter في الحدث install مع مجموعة من القواعد:

self.addEventListener('install', event => {
  if (event.registerRouter) {
    // Go straight to the network and bypass invoking "fetch" handlers for all
    // same-origin URLs that start with '/form/'.
    event.registerRouter([{
      condition: {
        urlPattern: {pathname: '/form/*'},
      },
      source: 'network',
    }]);
  }
});

تحتوي كل قاعدة بشكل عام على سمتَين:

• condition: لتحديد وقت تطبيق القاعدة باستخدام URL Pattern API لمحاولة مطابقة مسارات الموارد. يمكن أن يأخذ السمة مثيل URLPattern أو العنصر العادي المكافئ المتوافق مع تمريره إلى مُنشئ URLPattern (على سبيل المثال، new URLPattern({pathname: '*.jpg'}) أو {pathname: '*.jpg'} فقط).

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

• source: تُحدِّد كيفية تحميل الموارد التي تتطابق مع condition. في الوقت الحالي، لا تتوفّر سوى القيمة 'network' (باستثناء الخدمة العاملة لتحميل المورد عبر الشبكة مباشرةً)، ولكننا نخطّط لتوسيع نطاق ذلك ليشمل قيمًا أخرى في المستقبل.

حالات الاستخدام

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

على سبيل المثال، إذا كان موقعك الإلكتروني يستخدم استراتيجية الاعتماد على ذاكرة التخزين المؤقت أولاً (الرجوع إلى الشبكة)، ولكن هناك بعض المحتوى الذي نادرًا ما تتم زيارته ، ما يجعله غير مفيد أو قليل الفائدة في الوصول إلى ذاكرة التخزين المؤقت (مثل المحتوىarkived أو خلاصات RSS). يمكن فقط ضبط مسارَي الجلسة للتحميل من الشبكة في الخدمة العاملة، ولكن لا يزال على الخدمة العاملة بدء التشغيل وتنفيذه لتحديد كيفية معالجة هذه الطلبات.

في المقابل، تتجاهل واجهة برمجة التطبيقات لمسار التوجيه الثابت مشغّل الخدمة بالكامل باستخدام بضعة أسطر توضيحية:

self.addEventListener('install', event => {
  if (event.registerRouter) {
    event.registerRouter([{
      condition: {
        urlPattern: {pathname: '/feeds/*.xml'},
      },
      source: 'network',
    }, {
      condition: {
        urlPattern: {pathname: '/archives/*'},
      },
      source: 'network',
    }]);
  }
});

مع تطور واجهة برمجة التطبيقات Service Worker Static Routing API، من المخطّط أن يصبح هذا الإعداد أكثر مرونة وأن يتيح المزيد من السيناريوهات، مثل التشغيل التلقائي لعمليات جلب البيانات من الشبكة وبدء الخدمة العاملة. اطّلِع على الشرح المفصّل لمواصفات "الشكل النهائي" المحتمل لواجهة برمجة التطبيقات لمزيد من التفاصيل.

تجربة واجهة برمجة التطبيقات Service Worker Static Routing API

تتوفّر واجهة برمجة التطبيقات Service Worker Static Routing API في Chrome اعتبارًا من الإصدار 116، وهي متاحة في إصدار تجريبي، مما يتيح للمطوّرين اختبار واجهة برمجة التطبيقات على موقعهم الإلكتروني مع مستخدمين حقيقيين لقياس تأثيرها. اطّلِع على "البدء باستخدام مرحلة التجربة والتقييم" للحصول على معلومات أساسية عن مرحلة التجربة والتقييم.

للاختبار على الجهاز، يمكن تفعيل واجهة برمجة التطبيقات Service Worker Static Routing API باستخدام علامة chrome://flags/#service-worker-static-router أو من خلال تشغيل Chrome من سطر الأوامر مثل --enable-features=ServiceWorkerStaticRouter.

الملاحظات والاتجاهات المستقبلية

لا تزال واجهة برمجة التطبيقات Service Worker Static Routing API قيد التطوير بشكل نشط. إذا كنت تعتقد أنّ هذه الميزة مفيدة لك، يُرجى تجربتها من خلال الإصدار التجريبي من الميزة وتقديم ملاحظاتك حول واجهة برمجة التطبيقات وطريقة التنفيذ والوظائف المتاحة.