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