ناقش ديميان Demian التحديات التي تواجهها المواقع متعددة الأصول multiple origins عند محاولة إنشاء تطبيق ويب تقدمي واحد يشملها جميعًا، وذلك في مقال تطبيق الويب التقدمي على أصول متعددة.
يعد موقع التجارة الإلكترونية الافتراضي www.example.com
مثالًا على موقع متعدد الأصول، إذا كان:
-
الصفحة الرئيسية مُستضافة على العنوان
https://www.example.com
. -
صفحات الفئات مستضافة على عنوان مختلف مثلًا:
https://category.example.com
. -
صفحات تفاصيل المنتج مستضافة على عنوان ثالث مختلف، مثلًا:
https://product.example.com
.
تُقيِّد سياسة الأصل المشترك same-origin مشاركة عمّال الخدمة service workers وذاكرة التخزين المؤقت cache، والأذونات permessions، عبر الأصول المختلفة، لذا نوصي بشدة بتجنب هذا النوع من إعداد المواقع (سياسة الأصل المشترك)، ونوصي من لديهم مواقع مبنية بهذه الطريقة بالفعل، بالنظر في الانتقال إلى معمارية الموقع ذات الأصل الواحد single origin إذا أمكن.
تجنب استخدام أصول مختلفة لأقسام نفس الموقع عند بنائك تطبيق PWA واحد يشملها جميعًا.
سنعتني في هذا المقال بالحالة المعاكسة، بدلًا من توفير تطبيق ويب تقدمي واحد مجزأ على أصول مختلفة، فإننا سنهتم بحالة الشركات التي ترغب بتوفير تطبيقات ويب تقدمية PWA متعددة، تعمل على نفس اسم النطاق، وذلك لإعلام مستخدميها أن تطبيقات الويب التقدمية هذه تنتمي لنفس الشركة أو الخدمة.
لكن قبل البدء سنراجع أهم المفاهيم التقنية التي ستلزمنا، وذلك بالاعتماد على رابط موقع التجارة الالكترونية الافتراضي https://www.example.com
:
مصطلحات تقنية
-
النطاق Domain: هو أي تسلسل من العناوين الموجودة في نظام أسماء النطاقات DNS، مثلًا يعد
com
وexample.com
نطاقان، لكن الفرق هنا أنcom
هو النطاق الرئيسي بينما تُعدexample.com
أو مثلًاtest.com
وblog.com
نطاقات فرعية sub domains من النطاق الرئيسيcom
، أيضًا يعد كلًا منweb.example.com
وapp.example.com
مثلًا وغيرها، نطاقات فرعية sub domains من نطاقها الرئيسيwww.example.com
الذي يُعد كما قلنا نطاق فرعي بالنسبة للنطاق الرئيسي العامcom
وهلم جرًا. -
اسم المضيف Host name: هو اسم مخصص لأي جهاز متصل بشبكة، يُحلّل إلى (ويقابل) عنوان IP الجهاز في نظام أسماء النطاقات DNS، مثلًا
www.example.com
هو اسم مضيف. -
الأصل Origin: هو تجميعة من كلًا من البروتوكول، واسم المضيف، والمنفذ (اختياريًا)، مثلًا يعد العنوان
https://www.example.com:443
أصل.
إنشاء علاقة بين تطبيقات الويب التقدمية PWA
قد ترغب في بعض الحالات بإنشاء تطبيقات مستقلة، رغم أنك لا تزال مقررًا أنها متعلقة ببعضها وتنتمي لنفس المؤسسة أو العلامة التجارية brand. يُعد إعادة استخدام نفس اسم النطاق لجميع هذه المواقع طريقة جيدة لتأسيس علاقة قوية بينها، مثلًا:
-
يريد موقع التجارة الإلكترونية
https://www.example.com
إنشاء تجربة موقع مستقلة تسمح للبائعين بإدارة مخزونهم، مع التأكيد لهم أن هذا الموقع بتجربته المستقلة ينتمي إلى موقع التجارة الرئيسي الذي يشتري المستخدمون منه المنتجات. - تريد شركة إخبارية إنشاء تطبيق محدد لحدث رياضي عظيم، وذلك للسماح للمستخدمين بتلقي إحصائيات حول مسابقاتهم المفضلة عبر الإشعارات، وتمكينهم من تثبيت تطبيق PWA هذا على أجهزتهم بالتالي مشاهدة المحتوى الرياضي بسهولة، هذا مع التأكيد للمستخدمين أن التطبيق الرياضي يتبع لتلك الشركة الإخبارية.
- تريد إحدى الشركات إنشاء تطبيقات منفصلة لكلًا من الدردشة chat ورسائل البريد mail والتقويم calender وتريد أن تعمل هذه التطبيقات بشكل منفصل لكن تكون مرتبطة باسم الشركة.
تريد الشركة المالكة لموقع example.com توفير ثلاثة تطبيقات PWA مستقلة، باستخدام نفس اسم المجال لتأسيس علاقة قوية بينها.
استخدام أصول منفصلة
الطريقة الموصى بها في مثل هذه الحالات، هي بناء كل تطبيق ذي هدف خاص على أصل origin خاص.
إذا كنت تريد استخدام نفس اسم النطاق لجميع تطبيقات PWA المرتبطة ببعضها، فيمكنك القيام بذلك باستخدام النطاقات الفرعية sub domains. مثلًا يمكن لشركة تقدم خدمات إنترنت متعددة استضافة تطبيق بريد على الأصل https://mail.example.com
وتطبيق تقويم على الأصل https://calendar.example.com
، وتقديم الخدمة الرئيسية لأعمالها على الأصل https://www.example.com
.
وهناك مثال آخر لاستخدام النطاقات الفرعية للحصول على أصول مختلفة، وهو موقع رياضي يريد إنشاء تطبيق مستقل مخصص تمامًا لحدث رياضي مهم، مثل بطولة كرة القدم، وذلك على https://footballcup.example.com
، يمكن للمستخدمين تثبيت موقع البطولة هذا على أجهزتهم واستخدامه بشكل مستقل عن موقع الرياضة الرئيسي المستضاف على https://www.example.com
.
قد تكون هذه الطريقة مفيدة أيضًا للأنظمة التي تتيح للعملاء إنشاء تطبيقاتهم المستقلة بهم تحت علامة الشركة التجارية، كأن يتيح أحد تطبيقات الويب للتجار إنشاء تطبيقاتهم الخاصة على نطاقات فرعية بأسمائهم مثل https://ahmad.example.com
وhttps://ali.example.com
وغيرها.
يضمن استخدام أصول مختلفة العزل بين التطبيقات، أي يمكن لكل تطبيق من تطبيقات PWA المتعلقة ببعضها، إدارة ميزات المتصفح المختلفة بشكل مستقل، بما في ذلك:
- قابلية التثبيت Installability: حيث يوجد لكل تطبيق منها ملف بيان موارد Manifest، يوفر تجربة التطبيق الخاصة القابلة للتثبيت.
- التخزين Storage: يوجد لكل تطبيق منها ذاكرة تخزين مؤقتة cache، وميزات تخزين محلي local storage، وجميع أشكال التخزين المحلي للجهاز device-local بشكل أساسي.
- عمال الخدمة Service Workers: يوجد لكل تطبيق منها عامل خدمة مسؤول عن نطاقات التطبيق المسجلة فيه.
- الأذونات Permissions: يعطَى لكل تطبيق من تطبيقات PWA المرتبطة ببعضها عبر النطاقات الفرعية والمختلفة في الأصل، أذونات بشكل منفصل عن غيره، وهذا يفيد المستخدمين في معرفة الخدمة التي يمنحونها أذوناتهم بالضبط، كما تُنسب الإشعارات بدقة لكل تطبيق.
يُوصى باتباع هذه الدرجة من العزلة (الأصول المختلفة) عند بناء عدة تطبيقات ويب تقدمية PWA مستقلة Independent.
إذا أرادت تطبيقات النطاقات الفرعية مشاركة بياناتها المحلية مع بعضها البعض، فبإمكانها القيام بذلك عبر ملفات تعريف الارتباط cookies، أو بطريقة متقدمة أكثر، يمكنها مزامنة التخزين بواسطة الخادم.
يعد بناء تطبيقات ويب تقدمية PWA مختلفة على نطاقات منفردة باستخدام النطاقات الفرعية ممارسة جيدة.
استخدام نفس الأصل
الطريقة الثانية هي بناء تطبيقات PWA المتعلقة ببعضها، على نفس الأصل same origin، ويتضمن ذلك السيناريوهات التالية:
مسارات غير متراكبة
أي تُستضاف تطبيقات PWA المتعلقة ببعضها على نفس الأصل، لكن مع مسارات paths غير متراكبة non-overlapping، مثلًا:
المسارات المتراكبة أو المتداخلة
أي تستضاف تطبيقات الويب التقديمة PWA المتعددة على نفس الأصل، لكن أحد نطاقاتها متداخل nested داخل الآخر، مثلًا:
- https://example.com (التطبيق الخارجي)
- https://example.com/app (التطبيق الداخلي)
يسمح لك كلًا من الواجهة البرمجية Service Worker وتنسيق ملف بيان الموارد manifest بتطبيق الطريقتين السابقتين، وذلك بتحديد النطاقات فرعية أو رئيسية بناء على مستوى المسار path-level، لكن في كلتا الحالتين، يؤدي استخدام نفس الأصل إلى العديد من التحديات والمحدوديّات، النابعة من حقيقة أن المتصفح لن يعتبرها تطبيقات متمايزة، بالتالي لا يُنصح بهذا الأسلوب.
سنحلِّل تلك التحديات بالتفصيل في الفقرة القادمة، وسنذكر ما الذي يمكن فعله إذا لم يكن من الملائم استخدام أصول منفصلة.
لا يُنصح باستخدام المسارات المتداخلة وغير المتداخلة لاستضافة تطبيقين PWA مستقلين على نفس الأصل.
التحديات التي تواجه تطبيقات PWA على نفس الأصل
فيما يلي بعضًا من المشكلات العملية التي تواجهنا عند استخدام المسارات المتراكبة وغير المتراكبة لنفس الأصل:
- التخزين Storage: تُشارَك ملفات تعريف الارتباط cookies وبيانات التخزين المحلي local storage وجميع أشكال التخزين المحلي للجهاز device-local بين التطبيقات ذات نفس الأصل origin. لهذا، فإذا قرر المستخدم مسح البيانات المحلية لأحد تطبيقات PWA المتعلقة ببعضها، فستُمسح بيانات جميع التطبيقات المشتركة بنفس الأصل مع ذلك التطبيق، فلا توجد طريقة لمسح بيانات تطبيق واحد فقط منها بعينه. تحث بعض المتصفحات مثل Chrome وغيره المستخدمين دومًا على مسح البيانات المحلية عند إلغاء تثبيت أحد التطبيقات، وهذا سيؤثر على بيانات التطبيقات الأخرى المشتركة معه في نفس الأصل، والتحدي الآخر الممكن أن تواجهه بالنسبة للتخزين في التطبيقات المشتركة بنفس الأصل، هو أن هذه التطبيقات بطبعها تشارك بعضها حصة التخزين الخاصة بها، بالتالي إذا كان أيًا منها يشغَل مساحة تخزينية كبيرة جدًا، فسيتأثر الآخر سلبًا.
- الأذونات Permissions: إذا منح المستخدم إذنًا لأحد تطبيقات PWA المتعلقة ببعضها، فسيُمنح نفس الإذن لجميع التطبيقات المشتركة في نفس الأصل مع ذلك التطبيق، فالأذونات مرتبطة بالأصل أيضًا كما التخزين. قد يبدو هذا ميزة، بحيث لا تضطر جميع تلك التطبيقات إلى طلب نفس الإذن، أي طلب نفس الإذن عدة مرات، لكن التحدي هنا يكمن في حظر المستخدم إذنًا لأحد التطبيقات، فوقتها تُمنع التطبيقات الأخرى المشتركة في الأصل من طلب هذا الإذن، بالتالي لا تستطيع جميعها استخدام ميزة التطبيق التي تتطلب ذلك الإذن.
- إعدادات المستخدم User settings: تعيّن إعدادات المستخدم لتطبيقات الويب أيضًا بالإعتماد على الأصل، مثلًا، إذا كان لتطبيقان مشتركان في الأصل أحجام خطوط مختلفة، ويريد المستخدم ضبط تكبير حجم خط أحدهما فقط، فسيَكبُر حجم خط التطبيقات الأخرى المشتركة معه في نفس الأصل.
تجعلنا التحديات السابقة نتجنب هذا النهج (الأصل المشترك). لكن، إذا كنت لا تستطيع استخدام أصل منفصل (مثل نطاق فرعي) لكل تطبيق من تطبيقات PWA المتعلقة ببعضها، فيمكنك ترشيح خيار المسارات غير المتداخلة بدلًا من خيار المسارات المتراكبة أو المتداخلة ضمن خيارَي استخدام نفس الأصل في الأعلى.
تحديات إضافية للمسارات المتراكبة أو المتداخلة
المشكلة الإضافية المتعلقة بنهج المسارات المتراكبة أو المتداخلة (حيث https://example.com هو التطبيق الخارجي والمسار https://example.com/app هو للتطبيق الداخلي)، هو أن جميع عناوين URL في التطبيق الداخلي ستُعتبر جزءًا من كلا التطبيقين الداخلي والخارجي. وهذا يسبب عمليًا المشكلات التالية:
- إمكانية التثبيت Installation: إذا زار المستخدم التطبيق الداخلي (مثلًا في متصفح ويب)، وكان التطبيق الخارجي مثبتًا بالفعل في جهاز المستخدم، فلن يعرض المتصفح لافتات لتثبيت التطبيق الداخلي. وذلك لأن المتصفح عندما يتحقق من إنتماء الصفحة الحالية إلى تطبيق مثبت بالفعل أم لا، فإنه سيعتبر التطبيق الداخلي مثبت على الجهاز كون التطبيق الخارجي مثبت بالفعل، ويمكن أن تُحل هذه المشكلة بتثبيت التطبيق الداخلي يدويًا (عبر خيار "إنشاء اختصار" في المتصفح)، أو تثبيت التطبيق الداخلي أولاً، قبل التطبيق الخارجي.
- الواجهتان البرمجيتان Notification و Padging: إذا تم تثبيت التطبيق الخارجي دون الداخلي، فستُنسب الإشعارات والشارات القادمة من التطبيق الداخلي عن طريق الخطأ إلى التطبيق الخارجي، إذ تنسب الإشعارات والشارات بدقة لكل تطبيق في حال ثبِّت كليها على جهاز المستخدم.
- التقاط الرابط Link Capturing: إذا تم تثبيت التطبيق الخارجي دون الداخلي، فلن يتم التقاط روابط التطبيق الداخلي المرتبطة بالتطبيق الخارجي، أي بدلًا من أن يُفتح الرابط الداخلي في نفس التبويبة ضمن نطاق تصفح التطبيق الخارجي، فإنه سيُفتح في تبويبة جديدة لأن المتصفح سعتبره تطبيقًا غريبًا (تطبيق مختلف غير مرتبط به). لكن إذا أضيفت تطبيقات PWA هذه إلى المتجر على نظامَي Chrome OS وAndroid، فسيلتقط التطبيق الخارجي تلك الروابط، وأيضًا إذا تم تثبيت التطبيق الداخلي، فسيظل نظام التشغيل يوفر للمستخدم خيار فتح تلك الروابط المتعلقة بالتطبيق الداخلي في التطبيق الخارجي.
الخاتمة
تطرقنا في هذا المقال إلى الطرق المختلفة الممكن للمطورين من خلالها إنشاء العديد من تطبيقات الويب التقدمية المتعلقة ببعضها على نفس النطاق (وهذا مختلف عن استخدام نطاقات وأصول مختلفة لأقسام موقع واحد كبير).
باختصار، نوصي بشدة باستخدام أصل مختلف (مثلًا باستخدام النطاقات الفرعية) لاستضافة تطبيقات PWA المستقلة، إذ يؤدي استضافتها على نفس الأصل إلى عدة تحديات، كون المتصفح لن يعتبرها تطبيقات متمايزة، إذن الخلاصة أن هناك ثلاث حالات لاستضافة تطبيقات PWA المتعلقة ببعضها على نفس النطاق:
- على أصول منفصلة: موصى بها.
- على نفس الأصل بمسارات غير متداخلة: ليست مستحسنة.
- على نفس الأصل بمسارات متراكبة overlapping أو متداخلة nested: لا ينصح بها بشدة.
إذا لم يكن بإمكانك استخدام أصول مختلفة، فاستخدم مسارات غير متداخلة، مثلًا https://example.com/app1
وhttps://example.com/app2
، بدلًا من المسارات المتراكبة أو المتداخلة مثل https: //example.com
(للتطبيق الخارجي) وعنوان https://example.com/app
(للتطبيق الداخلي).
ترجمة -وبتصرف- للمقال Building multiple Progressive Web Apps on the same domain من موقع web.dev.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.