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