التحديات والحلول البديلة لإنشاء "تطبيقات الويب التقدّمية" في المواقع الإلكترونية المتعددة المصادر
تاريخ النشر: 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 من هذا المصدر (وفقًا للمسار المحدّد في مَعلمة النطاق)، ولكنّه لن يتحكّم في أي صفحة في نطاقات فرعية أخرى، مثل تلك الموجودة في https://section.example.com.
في هذه الحالة، الحلّ الوحيد هو استخدام عدة مشغّلي خدمات (واحد لكل مصدر).
التخزين المؤقت
يقتصر أيضًا كائن Cache وindexedDB وlocalStorage على مصدر واحد. وهذا يعني أنّه لا يمكن الوصول إلى ذاكرات التخزين المؤقت التي تنتمي إلى https://www.example.com، من، على سبيل المثال: https://www.section.example.com.
في ما يلي بعض الإجراءات التي يمكنك اتّخاذها لإدارة ذاكرة التخزين المؤقت بشكل صحيح في سيناريوهات مثل هذه:
الاستفادة من التخزين المؤقت في المتصفّح: ننصح دائمًا باستخدام أفضل الممارسات التقليدية للتخزين المؤقت في المتصفّح. توفّر هذه الطريقة ميزة إضافية تتمثّل في إعادة استخدام الموارد المخزّنة مؤقتًا في جميع المصادر، وهو ما لا يمكن تنفيذه باستخدام ذاكرة التخزين المؤقت الخاصة بمشغّل الخدمات. للاطّلاع على أفضل الممارسات حول كيفية استخدام ذاكرة التخزين المؤقت لبروتوكول HTTP مع مشغّلي الخدمات، يمكنك الاطّلاع على هذا المنشور.
الحفاظ على بساطة عملية تثبيت مشغّل الخدمات: إذا كنت تحتفظ بمشغّلي خدمات متعدّدين، تجنَّب فرض تكلفة تثبيت كبيرة على المستخدمين في كل مرة ينتقلون فيها إلى مصدر جديد. بعبارة أخرى: لا تخزِّن مؤقتًا سوى الموارد الضرورية للغاية.
الأذونات
تقتصر الأذونات أيضًا على المصادر. هذا يعني أنّه إذا منح مستخدم إذنًا معيّنًا للمصدر https://section.example.com، لن يتم نقله إلى مصادر أخرى، مثل https://www.example.com.
بما أنّه لا توجد طريقة لمشاركة الأذونات على مستوى المصادر، فإنّ الحل الوحيد هنا هو طلب الإذن على كل نطاق فرعي تكون فيه ميزة معيّنة مطلوبة (مثل الموقع الجغرافي). بالنسبة إلى ميزات مثل الإشعارات الفورية على الويب، يمكنك الاحتفاظ بملف تعريف ارتباط لتتبُّع ما إذا كان المستخدم قد وافق على الإذن في نطاق فرعي آخر، وذلك لتجنُّب طلبه مرة أخرى.
تثبيت
لتثبيت تطبيق ويب تقدّمي، يجب أن يكون لكل مصدر بيان خاص به يتضمّن start_url مرتبطًا به. يعني ذلك أنّ المستخدم الذي يتلقّى طلب التثبيت من مصدر معيّن (مثلاً: https://section.example.com) لن يتمكّن من تثبيت تطبيق الويب التقدّمي (PWA) الذي يتضمّن start_url من مصدر مختلف (مثلاً: https://www.example.com).
بعبارة أخرى، لن يتمكّن المستخدمون الذين يتلقّون طلب التثبيت في نطاق فرعي من تثبيت تطبيقات الويب التقدّمية إلا للصفحات الفرعية، وليس لعنوان URL الرئيسي للتطبيق.
هناك أيضًا مشكلة تتمثّل في أنّ المستخدم نفسه قد يتلقّى طلبات تثبيت متعددة عند تصفّح الموقع الإلكتروني، إذا كان كل نطاق فرعي يستوفي معايير التثبيت، ويطلب من المستخدم تثبيت تطبيق الويب التقدّمي.
للتخفيف من حدة هذه المشكلة، يمكنك التأكّد من عرض الطلب على المصدر الرئيسي فقط. عندما يزور مستخدم نطاقًا فرعيًا يستوفي معايير التثبيت:
- الاستماع إلى حدث
beforeinstallprompt - منع ظهور الطلب، من خلال استدعاء
event.preventDefault().
بهذه الطريقة، يمكنك التأكّد من عدم ظهور الطلب في أجزاء غير مقصودة من الموقع الإلكتروني، بينما يمكنك مواصلة عرضه، على سبيل المثال، في المصدر الرئيسي (مثل الصفحة الرئيسية).
الوضع المستقل
أثناء التنقّل في نافذة مستقلة، سيتصرف المتصفّح بشكل مختلف عندما ينتقل المستخدم خارج النطاق الذي يحدّده بيان تطبيق الويب التقدّمي. يعتمد السلوك على كل إصدار من المتصفّح والمورّد. على سبيل المثال، تفتح أحدث إصدارات Chrome علامة تبويب مخصّصة في Chrome عندما يخرج المستخدم من النطاق في وضع التطبيق المستقل.
في معظم الحالات، لا يتوفّر حلّ لهذه المشكلة، ولكن يمكن تطبيق حلّ بديل لأجزاء صغيرة من التجربة التي تتم استضافتها في نطاقات فرعية (على سبيل المثال: سير عمل تسجيل الدخول):
- يمكن فتح عنوان URL الجديد،
https://login.example.com، داخل إطار iframe بملء الشاشة. - بعد اكتمال المهمة داخل إطار iframe (على سبيل المثال، عملية تسجيل الدخول)، يمكن استخدام postMessage() لتمرير أي معلومات ناتجة من إطار iframe إلى الصفحة الرئيسية.
- كخطوة أخيرة، بعد أن تتلقّى الصفحة الرئيسية الرسالة، يمكن إلغاء تسجيل المستمعين، وإزالة iframe أخيرًا من نموذج العناصر في المستند (DOM).
الخاتمة
تفرض سياسة المصدر نفسه العديد من القيود على المواقع الإلكترونية التي تم إنشاؤها على مصادر متعددة وتريد تحقيق تجربة متسقة لتطبيقات الويب التقدّمية. لهذا السبب، ننصح بشدة بعدم تقسيم المواقع الإلكترونية إلى مصادر مختلفة، وذلك لتقديم أفضل تجربة للمستخدمين.
بالنسبة إلى المواقع الإلكترونية الحالية التي تم إنشاؤها بهذه الطريقة، قد يكون من الصعب جعل تطبيقات الويب التقدّمية المتعددة المصادر تعمل بشكل صحيح، ولكننا استكشفنا بعض الحلول البديلة المحتملة. وقد يكون لكلّ منها مزايا وعيوب، لذا استخدِم تقديرك الخاص عند تحديد النهج الذي ستتّبعه على موقعك الإلكتروني.
عند تقييم استراتيجية طويلة المدى أو إعادة تصميم الموقع الإلكتروني، ننصحك بالانتقال إلى مصدر واحد، ما لم يكن هناك سبب مهم للاحتفاظ بالبنية المتعددة المصادر.
مع خالص الشكر على المراجعات والاقتراحات الفنية: بيني ماكلاكلان، وبول كوفيل، ودومينيك نغ، وألبرتو مدينا، وبيت ليباج، وجو ميدلي، وتشيني تساي، ومارتن شيرل، وأندريه باندارا.