التحديات والحلول البديلة لإنشاء تطبيقات ويب تقدّمية في المواقع الإلكترونية المتعددة المصادر
تاريخ النشر: 19 آب (أغسطس) 2019
في السابق، كانت هناك بعض المزايا لاستخدام بنى متعددة المصادر. ويطرح هذا النهج العديد من التحديات أمام تطبيقات الويب التقدّمية. على وجه الخصوص، تفرض سياسة المصدر نفسه قيودًا على مشاركة عناصر مثل عاملي الخدمة وذاكرات التخزين المؤقت والأذونات، وعلى توفير تجربة مستقلة على مستوى مصادر متعددة.
التعرّف على الاستخدامات الجيدة والسيئة للمصادر المتعددة، وشرح التحديات والحلول البديلة لإنشاء تطبيقات ويب تقدّمية على مواقع إلكترونية ذات مصادر متعددة
الاستخدامات الجيدة والسيئة للمصادر المتعددة
هناك بعض الأسباب المشروعة التي تدفع المواقع الإلكترونية إلى استخدام بنية متعددة المصادر، وهي ترتبط في معظمها بتوفير مجموعة مستقلة من تطبيقات الويب أو إنشاء تجارب معزولة تمامًا عن بعضها البعض. هناك أيضًا استخدامات يجب تجنُّبها.
الجيد
اطّلِع أولاً على الأسباب المفيدة:
الموقع الجغرافي / اللغة: استخدام نطاق مستوى أعلى لرمز البلد لفصل المواقع الإلكترونية التي سيتم عرضها في بلدان مختلفة (مثل
https://www.google.com.ar)، أو استخدام نطاقات فرعية لتقسيم المواقع الإلكترونية المستهدفة لمواقع جغرافية مختلفة (مثل:https://newyork.craigslist.org) أو لتقديم محتوى بلغة معيّنة (مثلhttps://en.wikipedia.org).تطبيقات ويب مستقلة: استخدام نطاقات فرعية مختلفة لتقديم تجارب يختلف غرضها بشكل كبير عن الموقع الإلكتروني على المصدر الرئيسي على سبيل المثال، في موقع إخباري، يمكن عرض تطبيق الويب الخاص بألعاب الكلمات المتقاطعة عمدًا من
https://crosswords.example.com، ويمكن تثبيته واستخدامه كتطبيق ويب تقدّمي مستقل، بدون الحاجة إلى مشاركة أي موارد أو وظائف مع الموقع الإلكتروني الرئيسي.
السيئ
إذا لم تكن تفعل أيًا من هذه الإجراءات، من المحتمل أن يكون استخدام بنية متعددة المصادر عائقًا عند إنشاء "تطبيقات ويب تقدّمية".
على الرغم من ذلك، تواصل العديد من المواقع الإلكترونية استخدام هذه البنية بدون سبب معيّن أو لأسباب "قديمة". أحد الأمثلة على ذلك هو استخدام نطاقات فرعية لفصل أجزاء من موقع إلكتروني بشكل عشوائي، في حين أنّ هذه الأجزاء يجب أن تكون جزءًا من تجربة موحّدة.
على سبيل المثال، لا ننصح بشدة باستخدام الأنماط التالية:
أقسام الموقع الإلكتروني: فصل الأقسام المختلفة من الموقع الإلكتروني على نطاقات فرعية في المواقع الإخبارية، من الشائع رؤية الصفحة الرئيسية على الرابط:
https://www.example.com، بينما يظهر قسم الرياضة على الرابطhttps://sports.example.com، وقسم السياسة على الرابطhttps://politics.example.com، وهكذا. في حالة موقع إلكتروني للتجارة الإلكترونية، يمكنك استخدام شيء مثلhttps://category.example.comلفئات المنتجات، وhttps://product.example.comلصفحات المنتجات، وما إلى ذلك.مسار المستخدم: هناك طريقة أخرى لا ننصح بها، وهي فصل الأجزاء الصغيرة المختلفة من الموقع الإلكتروني، مثل صفحات تسجيل الدخول أو مسارات الشراء في نطاقات فرعية. على سبيل المثال، استخدام
https://login.example.comوhttps://checkout.example.com.
في الحالات التي لا يمكن فيها الانتقال إلى مصدر واحد، إليك قائمة بالتحديات والحلول البديلة (حيثما أمكن) التي يمكن أخذها في الاعتبار عند إنشاء "تطبيقات ويب تقدّمية".
التحديات والحلول البديلة لتطبيقات الويب التقدّمية (PWA) على مستوى المصادر المختلفة
عند إنشاء موقع إلكتروني على مصادر متعددة، يكون من الصعب تقديم تجربة موحّدة لتطبيق الويب التقدّمي، ويعود السبب في ذلك بشكل أساسي إلى سياسة المصدر نفسه التي تفرض عددًا من القيود. لنلقِ نظرة على كل منها على حدة.
مشغِّلو الخدمات
يجب أن يكون مصدر عنوان URL لبرنامج نصي خاص بعامل الخدمة هو نفسه مصدر الصفحة التي تستدعي register(). هذا يعني أنّه، على سبيل المثال، لا يمكن لصفحة على https://www.example.com استدعاء register() باستخدام عنوان URL خاص بعامل الخدمة على https://section.example.com.
يجب أيضًا مراعاة أنّ مشغّل الخدمات يمكنه التحكّم فقط في الصفحات المستضافة ضمن المصدر والمسار الذي ينتمي إليه. هذا يعني أنّه إذا كان مشغّل الخدمات مستضافًا على https://www.example.com، يمكنه التحكّم فقط في عناوين URL من هذا المصدر (وفقًا للمسار المحدّد في المعلَمة scope)، ولكنّه لن يتحكّم في أي صفحة في نطاقات فرعية أخرى، مثل تلك الموجودة في https://section.example.com.
في هذه الحالة، الحل الوحيد هو استخدام عدة برامج لتنفيذ الخدمة (واحد لكل مصدر).
التخزين المؤقت
يقتصر استخدام الكائن Cache وindexedDB وlocalStorage أيضًا على مصدر واحد. وهذا يعني أنّه لا يمكن الوصول إلى الذاكرات المؤقتة التي تخص https://www.example.com من https://www.section.example.com مثلاً.
في ما يلي بعض الإجراءات التي يمكنك اتّخاذها لإدارة الذاكرات المؤقتة بشكلٍ سليم في سيناريوهات مثل هذه:
الاستفادة من التخزين المؤقت في المتصفّح: ننصح دائمًا باتّباع أفضل الممارسات التقليدية للتخزين المؤقت في المتصفّح. توفّر هذه التقنية ميزة إضافية تتمثّل في إعادة استخدام الموارد المخزّنة مؤقتًا على مستوى المصادر، وهو ما لا يمكن تنفيذه باستخدام ذاكرة التخزين المؤقت الخاصة ببرنامج عامل الخدمة. للاطّلاع على أفضل الممارسات حول كيفية استخدام HTTP Cache مع برامج الخدمة، يمكنك الاطّلاع على هذه المشاركة.
الحفاظ على حجم صغير لعملية تثبيت عامل الخدمة: إذا كنت تحتفظ بعدة عوامل خدمة، تجنَّب فرض تكلفة تثبيت كبيرة على المستخدمين في كل مرة ينتقلون فيها إلى مصدر جديد. بعبارة أخرى، لا يتم التخزين المؤقت المسبق إلا للموارد الضرورية للغاية.
الأذونات
يقتصر نطاق الأذونات أيضًا على المصادر. هذا يعني أنّه إذا منح المستخدم إذنًا معيّنًا للمصدر https://section.example.com، لن يتم نقله إلى مصادر أخرى، مثل https://www.example.com.
بما أنّه لا توجد طريقة لمشاركة الأذونات بين المصادر، الحلّ الوحيد هنا هو طلب الإذن على كل نطاق فرعي مطلوب فيه ميزة معيّنة (مثل الموقع الجغرافي). بالنسبة إلى الإشعارات الفورية على الويب، يمكنك الاحتفاظ بملف تعريف ارتباط لتتبُّع ما إذا كان المستخدم قد وافق على الإذن في نطاق فرعي آخر، وذلك لتجنُّب طلب الإذن مرة أخرى.
تثبيت
لتثبيت تطبيق ويب تقدّمي، يجب أن يكون لكل مصدر بيان خاص به يتضمّن start_url يكون نسبيًا إلى نفسه. وهذا يعني أنّ المستخدم الذي يتلقّى طلب التثبيت على مصدر معيّن (مثل https://section.example.com) لن يتمكّن من تثبيت تطبيق الويب التقدّمي الذي يتضمّن start_url على مصدر مختلف (مثل https://www.example.com).
بعبارة أخرى، لن يتمكّن المستخدمون الذين يتلقّون طلب التثبيت في نطاق فرعي إلا من تثبيت تطبيقات الويب التقدّمية للصفحات الفرعية، وليس لعنوان URL الرئيسي للتطبيق.
هناك أيضًا مشكلة تتمثل في إمكانية تلقّي المستخدم نفسه لطلبات تثبيت متعددة عند التنقّل في الموقع الإلكتروني، إذا كان كل نطاق فرعي يستوفي معايير التثبيت، ويطلب من المستخدم تثبيت تطبيق الويب التقدّمي.
للتخفيف من هذه المشكلة، يمكنك التأكّد من عدم عرض الطلب إلا على المصدر الرئيسي. عندما ينتقل المستخدم إلى نطاق فرعي يستوفي معايير التثبيت:
- الاستماع إلى حدث
beforeinstallprompt - منع ظهور الطلب من خلال الاتصال بـ
event.preventDefault()
بهذه الطريقة، يمكنك التأكّد من عدم عرض الطلب في أجزاء غير مقصودة من الموقع الإلكتروني، مع إمكانية مواصلة عرضه، مثلاً، في المصدر الرئيسي (مثل الصفحة الرئيسية).
الوضع المستقل
أثناء التنقّل في نافذة مستقلة، سيتصرف المتصفّح بشكل مختلف عندما ينتقل المستخدم إلى خارج النطاق الذي يحدّده بيان PWA. ويعتمد السلوك على إصدار المتصفّح والمورّد. على سبيل المثال، تفتح أحدث إصدارات Chrome علامة تبويب مخصّصة في Chrome عندما يخرج المستخدم من النطاق في الوضع المستقل.
في معظم الحالات، ليس هناك حلّ لهذه المشكلة، ولكن يمكن تطبيق حلّ بديل على أجزاء صغيرة من التجربة مستضافة في نطاقات فرعية (مثل: إجراءات تسجيل الدخول):
- يمكن فتح عنوان URL الجديد،
https://login.example.com، داخل إطار iframe بملء الشاشة. - بعد إكمال المهمة داخل إطار iframe (مثل عملية تسجيل الدخول)، يمكن استخدام postMessage() لنقل أي معلومات ناتجة من إطار iframe إلى الصفحة الرئيسية.
- كخطوة أخيرة، بعد أن تتلقّى الصفحة الرئيسية الرسالة، يمكن إلغاء تسجيل المستمعين، ويمكن أخيرًا إزالة iframe من DOM.
الخاتمة
تفرض سياسة المصدر نفسه العديد من القيود على المواقع الإلكترونية التي تم إنشاؤها استنادًا إلى مصادر متعددة وتريد تقديم تجربة متسقة لتطبيقات الويب التقدّمية. لهذا السبب، ننصح بشدة بعدم تقسيم المواقع الإلكترونية إلى مصادر مختلفة من أجل تقديم أفضل تجربة للمستخدمين.
بالنسبة إلى المواقع الإلكترونية الحالية التي تم إنشاؤها بهذه الطريقة، قد يكون من الصعب جعل تطبيقات الويب التقدّمية التي تتضمّن مصادر متعددة تعمل بشكل صحيح، ولكننا استكشفنا بعض الحلول المحتملة. قد يكون لكلّ منهما مزايا وعيوب، لذا استخدِم تقديرك الخاص عند تحديد الطريقة التي يجب اتّباعها على موقعك الإلكتروني.
عند تقييم استراتيجية طويلة الأمد أو إعادة تصميم الموقع الإلكتروني، ننصحك بنقل المحتوى إلى مصدر واحد، إلا إذا كان هناك سبب مهم لإبقاء بنية المصادر المتعددة.
نتوجّه بالشكر الجزيل إلى كلّ من "بيني ماكلاكلان" و"بول كوفيل" و"دومينيك نغ" و"ألبرتو ميدينا" و"بيت ليباج" و"جو ميدلي" و"تشيني تساي" و"مارتن شيرلي" و"أندريه باندارا" على مراجعاتهم الفنية واقتراحاتهم.