التحديات والحلول البديلة لإنشاء تطبيقات ويب تقدّمية في المواقع الإلكترونية المتعددة المصادر.
الخلفية
كانت هناك بعض المزايا في الماضي لاستخدام بُنى متعددة المصادر، ولكن بالنسبة إلى تطبيقات الويب التقدّمية، يواجه هذا النهج العديد من التحديات. وعلى وجه الخصوص، تفرض سياسة المصدر نفسه قيودًا على مشاركة عناصر مثل عاملي الخدمة وذاكرات التخزين المؤقت والأذونات، وكذلك على تقديم تجربة مستقلة على مستوى عدة مصادر. ستصف هذه المقالة الاستخدامات الجيدة والسيئة للمصادر المتعددة، بالإضافة إلى التحديات والحلول البديلة لإنشاء تطبيقات ويب تقدّمية في مواقع إلكترونية متعددة المصادر.
الاستخدامات الجيدة والسيئة للأصول المتعددة
هناك بضعة أسباب مشروعة لاستخدام بنية متعددة المصادر على المواقع الإلكترونية، يرتبط غالبًا بتوفير مجموعة مستقلة من تطبيقات الويب أو إنشاء تجارب معزولة تمامًا عن بعضها البعض. هناك أيضًا استخدامات يجب تجنبها.
الجيد
لنلقِ نظرة على الأسباب المفيدة أولاً:
الأقلمة / اللغة: استخدام نطاق المستوى الأعلى الذي يتم ترميزه حسب البلد، أو لفصل المواقع الإلكترونية التي سيتم عرضها في بلدان مختلفة (مثل
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) من مصادر مختلفة
عند إنشاء موقع إلكتروني من مصادر متعددة، يكون توفير تجربة موحّدة لتطبيق الويب التقدّمي (PWA) أمرًا صعبًا، ويرجع ذلك في الغالب إلى سياسة المصدر نفسه التي تفرض عددًا من القيود. لنلقِ نظرة على كل منهما.
مشغِّلو الخدمات
يجب أن يكون أصل عنوان URL للنص البرمجي لمشغِّل الخدمات مطابقًا لأصل الصفحة التي تستدعي register()، على سبيل المثال، لا يمكن لصفحة في https://www.example.com استدعاء register() من خلال عنوان URL لمشغِّل الخدمات على https://section.example.com.
ملاحظة أخرى هي أنّ عامل الخدمة يمكنه فقط التحكّم في الصفحات المستضافة ضمن المصدر والمسار الذي ينتمي إليه. وهذا يعني أنّه إذا كان مشغّل الخدمات مستضافًا على https://www.example.com، يمكنه فقط التحكّم في عناوين URL من هذا المصدر (وفقًا للمسار المحدّد في مَعلمة النطاق)، ولكن لن يتحكّم في أي صفحة في النطاقات الفرعية الأخرى، مثل تلك في https://section.example.com.
في هذه الحالة، يكون الحل الوحيد هو استخدام عاملي خدمة متعددين (عامل واحد لكل مصدر).
التخزين المؤقت
يتم أيضًا حصر عنصر ذاكرة التخزين المؤقت وقاعدة البيانات المفهرَسة وLocalStorage بمصدر واحد. يعني هذا أنّه لا يمكن الوصول إلى ذاكرات التخزين التي تنتمي إلى 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) لن يتمكّن من تثبيت تطبيق الويب التقدّمي 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.
الخلاصة
تفرض سياسة المصدر نفسه العديد من القيود على المواقع الإلكترونية التي تم إنشاؤها استنادًا إلى مصادر متعدّدة وتريد توفير تجربة تطبيقات ويب تقدّمية متسقة. لهذا السبب، ننصح بشدة بعدم تقسيم المواقع الإلكترونية إلى مصادر مختلفة لتوفير أفضل تجربة للمستخدمين.
بالنسبة إلى المواقع الإلكترونية الحالية التي تم إنشاؤها بهذه الطريقة، قد يصعب عمل تطبيقات الويب التقدّمية المتعددة المصادر بشكل صحيح، ولكننا اكتشفنا بعض الحلول البديلة. يمكن أن يأتي كل منها بمقايضات، لذا استخدم حكمك عند تحديد الأسلوب الذي يجب اتباعه على موقع الويب.
عند تقييم استراتيجية طويلة الأمد أو إعادة تصميم موقع إلكتروني، ننصحك بالنقل إلى مصدر واحد، ما لم يكن هناك سبب مهم للحفاظ على البنية متعددة المصادر.
شكرًا جزيلاً على اقتراحاتهم ومراجعاتهم الفنية: "بيني مكلاشلان" و"بول كوفل" و"دومينيك نغ" و"ألبرتو ميدينا" و"بيت ليبيج" و"جو ميدلي" و"تشيني تساي" و"مارتن شيرل" و"أندريه باندارا".