مشغّلو الخدمات من مصادر خارجية: تجربة الجلب من مصادر خارجية

Jeff Posnick

تحذير: المعلومات الواردة في هذه المشاركة قديمة. لم يعُد الإجراء fetchForeign متاحًا للاختبار في Chrome، وتمت إزالته من مواصفات مهام الخدمة.

الخلفية

تمنح خدمات Worker لمطوّري الويب إمكانية الاستجابة لطلبات الشبكة التي تقدّمها تطبيقات الويب، ما يسمح لهم بمواصلة العمل حتى في حال عدم الاتصال بالإنترنت، ومكافحة شبكة Lie-Fi، وتنفيذ تفاعلات معقدة مع ذاكرة التخزين المؤقت، مثل stale-while-revalidate. ولكنّ مشغّلات الخدمات كانت مرتبطة في السابق بمصدر معيّن. وبصفتك مالك تطبيق ويب، تقع على عاتقك مسؤولية كتابة مشغّل خدمات ونشره لمنع جميع طلبات الشبكة التي يقدّمها تطبيق الويب. في هذا النموذج، يتحمّل كل عامل خدمة مسؤولية معالجة الطلبات من مصادر مختلفة، مثل واجهة برمجة تطبيقات تابعة لجهة خارجية أو خطوط ويب.

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

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

• مزوّدو واجهات برمجة التطبيقات الذين يستخدمون واجهات RESTful
• موفّرو خطوط الويب
• مقدّمو خدمة الإحصاءات
• موفِّرو استضافة الصور
• شبكات توصيل المحتوى العامة

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

المتطلبات الأساسية

الرمز المميّز لمرحلة التجربة والتقييم

لا تزال ميزة "الاسترجاع من مصدر خارجي" تجريبية. ولتجنّب طرح هذا التصميم قبل الأوان قبل أن يتم تحديده بالكامل والاتفاق عليه من قِبل مورّدي المتصفّحات، تم تنفيذه في الإصدار 54 من Chrome كإصدار تجريبي. طالما أنّ ميزة "الاسترداد من مصدر خارجي" لا تزال تجريبية، لاستخدام هذه الميزة الجديدة مع الخدمة التي تستضيفها، عليك طلب رمز مميّز يكون نطاقه محصورًا بمصدر خدمتك المحدّد. يجب تضمين الرمز المميّز كعنوان استجابة HTTP في جميع طلبات الموارد من مصادر متعددة التي تريد التعامل معها من خلال ميزة "الاسترداد من مصدر خارجي"، بالإضافة إلى الاستجابة لمورد JavaScript الخاص بعامل الخدمة:

Origin-Trial: token_obtained_from_signup

ستنتهي الفترة التجريبية في آذار (مارس) 2017. نتوقع أن ننتهي من إجراء أي تغييرات ضرورية لتحسين أداء الميزة، ونأمل أن نتمكّن من تفعيلها تلقائيًا. إذا لم يتم تفعيل ميزة "الاسترداد من مصدر خارجي" تلقائيًا بحلول ذلك الوقت، سيتوقّف عمل الوظيفة المرتبطة برموز Origin Trial المتوفّرة حاليًا.

لتسهيل تجربة ميزة "الاسترداد من مصدر خارجي" قبل التسجيل للحصول على رمز مميز رسمي لبرنامج Origin Trial، يمكنك تجاوز الشرط في Chrome على جهاز الكمبيوتر المحلي من خلال الانتقال إلى chrome://flags/#enable-experimental-web-platform-features وتفعيل علامة "ميزات منصة الويب التجريبية". يُرجى العِلم أنّه يجب إجراء ذلك في كل مثيل من متصفّح Chrome الذي تريد استخدامه في تجاربك المحلية، في حين أنّ الميزة ستتوفّر لجميع مستخدمي Chrome باستخدام رمز مميّز لإصدار أوّلي.

HTTPS

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

استخدام ميزة "الاسترداد من مصدر خارجي"

بعد الانتهاء من المتطلبات الأساسية، لنلقِ نظرة على التفاصيل الفنية اللازمة لبدء تشغيل عامل خدمة جلب خارجي.

تسجيل مشغّل الخدمة

إنّ أول تحدّي من المرجّح أن تواجهه هو كيفية تسجيل عامل الخدمة. إذا سبق لك العمل مع عمال الخدمات، من المرجّح أن تكون على دراية بما يلي:

// You can't do this!
if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('service-worker.js');
}

يكون رمز JavaScript هذا لتسجيل عامل خدمة تابع للطرف الأول منطقيًا في سياق تطبيق ويب يتم تشغيله من قِبل مستخدم ينتقل إلى عنوان URL تتحكم فيه. ولكنّ هذا النهج غير مناسب لتسجيل عامل خدمة تابع لجهة خارجية، لأنّ التفاعل الوحيد الذي سيجريه المتصفّح مع خادمك هو طلب مورد فرعي معيّن، وليس التنقّل الكامل. إذا طلب المتصفّح، على سبيل المثال، صورة من خادم شبكة توصيل المحتوى (CDN) الذي تديره، لا يمكنك إضافة مقتطف JavaScript هذا إلى ردّك والتوقع أن يتم تنفيذه. يجب استخدام طريقة مختلفة لتسجيل عامل الخدمة خارج سياق تنفيذ JavaScript العادي.

يتم تقديم الحلّ على شكل عنوان HTTP يمكن أن يتضمّنه خادمك في أي استجابة:

Link: </service-worker.js>; rel="serviceworker"; scope="/"

لنقسّم مثال العنوان هذا إلى مكوّناته، مع الفصل بين كل مكوّن بحرف ;.

• يجب إدخال العنصر </service-worker.js>، ويتم استخدامه لتحديد مسار ملف worker الخدمة (استبدِل /service-worker.js بالمسار المناسب لملف النص البرمجي). يتوافق ذلك مباشرةً مع سلسلة scriptURL التي سيتم تمريرها كأول مَعلمة إلى navigator.serviceWorker.register(). يجب أن تكون القيمة محاطة بعلامات <> (على النحو المطلوب في مواصفات رأس Link)، وإذا تم تقديم عنوان URL نسبي بدلاً من عنوان URL مطلق، سيتم تفسيره على أنّه نسبي إلى الموقع الجغرافي للاستجابة.
• يجب أيضًا إدراج rel="serviceworker" بدون الحاجة إلى تخصيصه.
• scope=/ هو بيان نطاق اختياري، وهو ما يعادل سلسلة options.scope التي يمكنك تمريرها كمَعلمة ثانية إلى navigator.serviceWorker.register(). في العديد من حالات الاستخدام، لا بأس باستخدام النطاق التلقائي، لذا يمكنك عدم تضمين هذا الحقل ما لم تكن بحاجة إليه. تنطبق القيود نفسها حول الحد الأقصى المسموح به للنطاق، بالإضافة إلى إمكانية تخفيف هذه القيود من خلال عنوان Service-Worker-Allowed، على عمليات تسجيل عنوان Link.

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

تذكَّر أنّ ميزة "الاسترداد من مصدر خارجي" يتم تنفيذها حاليًا كجزء من الإصدار التجريبي من الإصدار الأصلي، لذا عليك تضمين عنوان Origin-Trial صالح أيضًا إلى جانب عنوان استجابة الرابط. الحد الأدنى لمجموعة رؤوس الاستجابة التي يجب إضافتها لتسجيل عامل خدمة الجلب الخارجي هو

Link: </service-worker.js>; rel="serviceworker"
Origin-Trial: token_obtained_from_signup

ملاحظة: قد لاحظ القرّاء الملاحظون لمواصفات موظّف الخدمة وسيلة أخرى لإجراء تسجيل موظّف الخدمة، وذلك من خلال عنصر <link rel="serviceworker"> DOM. يتم حاليًا التحكّم في إتاحة التسجيل المستنِد إلى <link> في Chrome من خلال إصدار Origin Trial نفسه المستخدَم في عنوان Link، لذا لم يتم تفعيله تلقائيًا بعد. يواجه التسجيل المستنِد إلى <link> القيود نفسها التي يواجهها التسجيل المستنِد إلى JavaScript في ما يتعلّق بتسجيل الجلب الخارجي، لذا لأغراض هذه المقالة، يجب استخدام العنوان Link.

تصحيح أخطاء التسجيل

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

هل يتم إرسال رؤوس الاستجابة الصحيحة؟

لتسجيل عامل خدمة الجلب الخارجي، عليك ضبط رأس Link في استجابة لمورد مستضاف على نطاقك، كما هو موضّح سابقًا في هذه المشاركة. خلال فترة "الإصدار التجريبي من المصدر"، وافترضنا أنّه لم يتم ضبط chrome://flags/#enable-experimental-web-platform-features، عليك أيضًا ضبط عنوان استجابة Origin-Trial. يمكنك التأكّد من أنّ خادم الويب يضبط هذه العناوين من خلال الاطّلاع على الإدخال في لوحة الشبكة في "أدوات مطوّري البرامج":

هل تم تسجيل مشغّل خدمات "الاسترداد من المواقع الخارجية" بشكلٍ صحيح؟

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

معالِج حدث التثبيت

بعد تسجيل عامل الخدمة التابع لجهة خارجية، ستتوفّر له فرصة الردّ على حدثَي install وactivate، تمامًا مثل أي عامل خدمة آخر. ويمكن أن يستفيد من هذه الأحداث، على سبيل المثال، لتعبئة ذاكرات التخزين المؤقت بالموارد المطلوبة أثناء الحدث install، أو لتقليم ذاكرات التخزين المؤقت القديمة في الحدث activate.

بالإضافة إلى الأنشطة العادية لتخزين أحداث install في ذاكرة التخزين المؤقت، هناك خطوة إضافية مطلوب تنفيذها داخل معالِج أحداث install الخاص بعامل الخدمة التابع لجهة خارجية. يجب أن تستدعي رمزك registerForeignFetch()، كما هو موضّح في المثال التالي:

self.addEventListener('install', event => {
    event.registerForeignFetch({
    scopes: [self.registration.scope], // or some sub-scope
    origins: ['*'] // or ['https://example.com']
    });
});

هناك خياران للضبط، وكلاهما مطلوب:

• تأخذ دالة scopes صفيفًا من سلسلة واحدة أو أكثر، يمثّل كلّ منها نطاقًا للطلبات التي ستؤدي إلى تشغيل حدث foreignfetch. لكن، انتظِر، قد تعتقد أنّك سبق أن حدّدت نطاقًا أثناء تسجيل مشغّل الخدمات. هذا صحيح، ولا يزال النطاق العام ذا صلة. يجب أن يكون كل نطاق تحدّده هنا مساويًا للنطاق العام لخدمة Worker أو نطاقًا فرعيًا منه. تسمح لك القيود الإضافية على النطاق هنا بنشر عامل خدمة مخصّص لجميع الأغراض يمكنه التعامل مع أحداث fetch التابعة للطرف الأول (للطلبات المقدَّمة من موقعك الإلكتروني) وأحداث foreignfetch التابعة لجهات خارجية (للطلبات المقدَّمة من نطاقات أخرى)، وتوضيح أنّه يجب أن يؤدي فقط إلى بدء foreignfetch مجموعة فرعية من نطاقك الأكبر. من الناحية العملية، إذا كنت بصدد نشر عامل خدمة مخصّص للتعامل مع أحداث foreignfetch التابعة لجهات خارجية فقط، ستحتاج إلى استخدام نطاق واحد وواضح يساوي النطاق العام لعامل الخدمة. وهذا ما سيفعله المثال أعلاه باستخدام القيمة self.registration.scope.
• يقبل origins أيضًا صفيفًا من سلسلة واحدة أو أكثر، ويسمح لك بحصر معالِج foreignfetch بالردّ على الطلبات الواردة من نطاقات معيّنة فقط. على سبيل المثال، إذا سمحت صراحةً بـ "https://example.com"، سيؤدي طلب مُرسَل من صفحة مستضافة على https://example.com/path/to/page.html لمورد معروض من نطاق الجلب الخارجي إلى تنشيط معالِج الجلب الخارجي، ولكن لن يؤدي الطلبات المُرسَلة من https://random-domain.com/path/to/page.html إلى تنشيط المعالِج. ما لم يكن لديك سبب محدّد لتشغيل منطق الجلب الخارجي لمجموعة فرعية فقط من مصادر البيانات البعيدة، يمكنك ببساطة تحديد '*' كقيمة وحيدة في الصفيف، وسيتم السماح بجميع مصادر البيانات.

معالج حدث foreignfetch

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

ملاحظة: هناك قيد إضافي في التنفيذ الحالي لمتصفّح Chrome: إنّ طلبات GET أو POST أو HEAD التي تحتوي فقط على عناوين مُدرَجة في القائمة الآمنة لبروتوكول مشاركة الموارد المشتركة المنشأ (CORS) هي فقط المؤهّلة للجلب من مصدر خارجي. لا يشكّل هذا التقييد جزءًا من مواصفات الجلب الخارجي، وقد يتمّ تخفيف قيوده في الإصدارات المستقبلية من Chrome.

في الخدمة التقليدية التي تقدّمها الجهة الأولى، سيؤدي كل طلب إلى بدء حدث fetch يمكن لعامل الخدمة الردّ عليه. يتم منح عامل الخدمة التابع لجهة خارجية فرصة معالجة حدث مختلف قليلاً، يُسمى foreignfetch. من الناحية المفهومية، يتشابه الحدثان تمامًا، ويمنحانك الفرصة لفحص الطلب الوافد، وتقديم ردّ عليه اختياريًا من خلال respondWith():

self.addEventListener('foreignfetch', event => {
    // Assume that requestLogic() is a custom function that takes
    // a Request and returns a Promise which resolves with a Response.
    event.respondWith(
    requestLogic(event.request).then(response => {
        return {
        response: response,
        // Omit to origin to return an opaque response.
        // With this set, the client will receive a CORS response.
        origin: event.origin,
        // Omit headers unless you need additional header filtering.
        // With this set, only Content-Type will be exposed.
        headers: ['Content-Type']
        };
    })
    );
});

على الرغم من أوجه التشابه في المفهوم، هناك بعض الاختلافات في الممارسة عند الاتصال بـ respondWith() على ForeignFetchEvent. بدلاً من تقديم Response فقط (أو Promise الذي يحلّ محل Response) إلى respondWith()، كما تفعل مع FetchEvent، عليك تمرير Promise الذي يحلّ محل عنصر بخصائص محدّدة إلى respondWith() في ForeignFetchEvent:

• يجب إدخال العنصر response، ويجب ضبطه على العنصر Response الذي سيتم إرجاعه إلى العميل الذي قدّم الطلب. إذا قدّمت أي قيمة غير Response صالحة، سيتم إنهاء طلب العميل بظهور خطأ في الشبكة. على عكس استدعاء respondWith() داخل معالج حدث fetch، يجب تقديم Response هنا، وليس Promise الذي يتم حلّه باستخدام Response. يمكنك إنشاء استجابتك من خلال سلسلة وعد، ويجب تمرير هذه السلسلة كمَعلمة إلى respondWith() في foreignfetch، ولكن يجب أن يتم حلّ السلسلة باستخدام عنصر يحتوي على سمة response التي تم ضبطها على عنصر Response. يمكنك الاطّلاع على عرض توضيحي لهذا الإجراء في نموذج الرمز أعلاه.
• ‫origin هو اختياري، ويتم استخدامه لتحديد ما إذا كان الردّ الذي يتم إرجاعه مبهمًا أم لا. في حال عدم تضمين هذا العنصر، سيكون الردّ غير واضح، ولن يتمكّن العميل من الوصول إلا إلى جزء محدود من نص الردّ وعناوينه. إذا تم تقديم الطلب باستخدام mode: 'cors'، سيتم التعامل مع عرض استجابة غير شفافة على أنّه خطأ. ومع ذلك، إذا حدّدت قيمة سلسلة تساوي مصدر العميل البعيد (يمكن الحصول عليها من خلال event.origin)، يعني ذلك أنّك توافق صراحةً على تقديم استجابة مفعَّلة بتنسيق CORS إلى العميل.
• يكون الخيار headers اختياريًا أيضًا، ولا يكون مفيدًا إلا إذا كنت تحدّد أيضًا origin وتُرسل استجابة CORS. سيتم تلقائيًا تضمين العناوين الواردة في قائمة عناوين الاستجابة المسموح بها في CORS فقط في استجابتك. إذا كنت بحاجة إلى فلترة البيانات المعروضة بشكل أكبر، تأخذ الرؤوس قائمة بأسماء رؤوس واحدة أو أكثر، وستستخدمها كقائمة مسموح بها للرؤوس التي سيتم عرضها في الاستجابة. يتيح لك ذلك تفعيل بروتوكول مشاركة الموارد المشتركة المنشأ (CORS) مع مواصلة منع عرض عناوين الاستجابة الحسّاسة المحتملة مباشرةً على العميل البعيد.

من المهمّ ملاحظة أنّه عند تشغيل معالِج foreignfetch، يمكنه الوصول إلى جميع بيانات الاعتماد والإذن الشامل للمصدر الذي يستضيف الخدمة العاملة. بصفتك مطوّرًا ينشر عامل خدمة أجنبيًا مزوّدًا بميزة الجلب، تقع على عاتقك مسؤولية التأكّد من عدم تسرُّب أي بيانات استجابة مميّزة لا يمكن الحصول عليها بخلاف ذلك بموجب بيانات الاعتماد هذه. إنّ طلب الموافقة على طلبات CORS هو خطوة واحدة للحدّ من التعرّض غير المقصود، ولكن بصفتك مطوّرًا، يمكنك إرسال طلبات fetch() بشكل صريح داخل معالِج foreignfetch لا يستخدم بيانات الاعتماد الضمنية من خلال:

self.addEventListener('foreignfetch', event => {
    // The new Request will have credentials omitted by default.
    const noCredentialsRequest = new Request(event.request.url);
    event.respondWith(
    // Replace with your own request logic as appropriate.
    fetch(noCredentialsRequest)
        .catch(() => caches.match(noCredentialsRequest))
        .then(response => ({response}))
    );
});

اعتبارات العميل

هناك بعض الاعتبارات الإضافية التي تؤثّر في كيفية تعامل عامل خدمة الجلب الأجنبي مع الطلبات المقدَّمة من عملاء خدمتك.

العملاء الذين لديهم عامل خدمة تابع للجهة الأولى

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

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

داخل مشغّل خدمة تابع للجهة الأولى، سيؤدي استخدام fetch() لاسترداد موارد من مصادر متعددة إلى تنشيط مشغّل خدمة جلب الموارد الخارجي المناسب. وهذا يعني أنّ الرمز البرمجي التالي يمكنه الاستفادة من معالِج foreignfetch:

// Inside a client's first-party service-worker.js:
self.addEventListener('fetch', event => {
    // If event.request is under your foreign fetch service worker's
    // scope, this will trigger your foreignfetch handler.
    event.respondWith(fetch(event.request));
});

وبالمثل، إذا كانت هناك معالجات جلب تابعة للطرف الأول، ولكنّها لا تستدعي event.respondWith() عند معالجة طلبات موردك من مصادر متعددة، سيتم تلقائيًا "تجاهل" الطلب وتوجيهه إلى معالج foreignfetch:

// Inside a client's first-party service-worker.js:
self.addEventListener('fetch', event => {
    if (event.request.mode === 'same-origin') {
    event.respondWith(localRequestLogic(event.request));
    }

    // Since event.respondWith() isn't called for cross-origin requests,
    // any foreignfetch handlers scoped to the request will get a chance
    // to provide a response.
});

إذا كان معالِج fetch تابع للجهة الأولى يستدعي event.respondWith() ولكنّه لا يستخدم fetch() لطلب مورد ضمن نطاق الجلب الخارجي، لن تحصل الخدمة الخارجية التي تُجري الجلب على فرصة لمعالجة الطلب.

التطبيقات التي لا تستخدم عامل الخدمة الخاص بها

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

جمع كل المعلومات معًا: الأماكن التي يبحث فيها العملاء عن ردّ

مع الأخذ في الاعتبار المعلومات الواردة أعلاه، يمكننا تجميع تسلسل هرمي للمصادر التي سيستخدمها العميل للعثور على استجابة لطلب من مصدر مختلف.

1. معالِج fetch لمشغّل خدمات تابع للطرف الأول (إذا كان متوفّرًا)
2. معالِج foreignfetch لمشغّل خدمات تابع لجهة خارجية (إذا كان متوفّرًا، وطلبات مصادر متعددة فقط)
3. ذاكرة التخزين المؤقت لبروتوكول HTTP في المتصفّح (إذا كانت هناك استجابة جديدة)
4. الشبكة

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

مزيد من المعلومات

• شرح عملية الجلب من مصدر خارجي
• نموذج الرمز البرمجي والعرض التوضيحي المباشر
• أداة تتبُّع مشاكل موظّفي الخدمة

البقاء على اطّلاع

إنّ تنفيذ Chrome لمرحلة تجربة وتقييم ميزة "الاسترداد من مصدر خارجي" عرضة للتغيير بينما نعالج الملاحظات الواردة من المطوّرين. سنحرص على تعديل هذا المنشور باستمرار من خلال التغييرات المضمّنة، وسنُشير إلى التغييرات المحدّدة أدناه عند حدوثها. سنشارك أيضًا معلومات عن التغييرات الرئيسية من خلال حساب Twitter @chromiumdev.