إنشاء تطبيقات ويب تقدّمية متعدّدة على النطاق نفسه

كيفية إنشاء تطبيقات PWA متعددة، بالاستفادة من اسم النطاق نفسه، لإعلام المستخدم بأنّه ينتمي إلى المؤسسة أو الخدمة نفسها

Chase Phillips

Demián Renzulli

Matt Giuca

ناقشت "ديميان" في مشاركة مدونة تطبيقات الويب التقدّمية في مدونة مواقع إلكترونية متعددة المصادر التحديات التي تواجهها المواقع الإلكترونية التي تم إنشاؤها على مصادر متعددة عند محاولة إنشاء تطبيق ويب تقدّمي واحد يضم كل هذه المصادر.

مثال على هذا النوع من بنية المواقع الإلكترونية هو مواقع التجارة الإلكترونية حيث:

• الصفحة الرئيسية على https://www.example.com.
• تتم استضافة صفحات الفئات على https://category.example.com.
• صفحات تفاصيل المنتج على https://product.example.com.

وفقًا لما ناقشناه في المقالة، تفرض سياسة المصدر نفسه قيودًا متعددة، ما يمنع مشاركة مشغِّلي الخدمات وذاكرات التخزين المؤقت والأذونات في جميع المصادر. لهذا السبب، ننصح بشدة بتجنُّب هذا النوع من الإعدادات، وبالنسبة إلى المواقع الإلكترونية التي تحتوي على مواقع تم إنشاؤها بهذه الطريقة، نقترح محاولة الانتقال إلى بنية موقع إلكتروني ذات مصدر واحد متى أمكن ذلك.

في هذه المشاركة، نلقي نظرة على الحالة المعاكسة: بدلاً من تطبيق ويب تقدّمي واحد (PWA) على مستوى مصادر مختلفة، سنحلّل حالة الشركات التي تريد تقديم تطبيقات PWA متعدّدة، مع الاستفادة من اسم النطاق نفسه وإبلاغ المستخدم بأنّ تطبيقات الويب التقدّمية (PWA) هذه تنتمي إلى المؤسسة أو الخدمة نفسها.

ربما لاحظت أنّنا نستخدم عبارات مختلفة ولكن مترابطة، مثل النطاقات والأصول. قبل المضي قدمًا، دعنا نراجع هذه المفاهيم.

المصطلحات الفنية

• النطاق: أي تسلسل من التصنيفات كما هو محدّد في نظام أسماء النطاقات (DNS). على سبيل المثال: com وexample.com نطاقان.
• اسم المضيف: إدخال نظام أسماء نطاقات يتم حله إلى عنوان IP واحد على الأقل. على سبيل المثال: سيكون www.example.com اسم مضيف، ويمكن أن يكون example.com اسم مضيف إذا كان له عنوان IP، ولن يتم تحويل com إلى عنوان IP مطلقًا، وبالتالي لا يمكن أن يكون اسم مضيف أبدًا.
• المصدر: مزيج من المخطَّط واسم المضيف والمنفذ (اختياريًا). على سبيل المثال، https://www.example.com:443 هو أصل.

كما يوحي اسمها، تفرض سياسة المصدر نفسه قيودًا على المصادر، لذلك سنشير في الغالب إلى المصطلح في المقالة. ومع ذلك، سنستخدم "النطاقات" أو "النطاقات الفرعية" من حين لآخر لوصف الأسلوب المستخدَم، وذلك لإنشاء "المصادر" المختلفة.

حالة تطبيقات الويب التقدّمية المتعددة ذات الصلة

في بعض الحالات، قد ترغب في إنشاء تطبيقات مستقلة، مع الاستمرار في تحديدها على أنها تابعة للمؤسسة أو "العلامة التجارية" نفسها. ويمكنك إعادة استخدام اسم النطاق نفسه لإنشاء هذه العلاقة. مثال:

• يريد أحد مواقع التجارة الإلكترونية إنشاء تجربة مستقلة للسماح للبائعين بإدارة مخزونهم، مع التأكد من فهمهم أنه ينتمي إلى الموقع الإلكتروني الرئيسي الذي يشتري فيه المستخدمون المنتجات.
• لنفترض أن هناك مواقع أخبار رياضية ترغب في إنشاء تطبيق محدد لحدث رياضي كبير، للسماح للمستخدمين بتلقي إحصاءات حول مسابقاتهم المفضلة عبر الإشعارات، وتثبيته كتطبيق ويب تقدّمي، مع التأكّد من تعريف المستخدمين عليه باعتباره تطبيقًا من تصميم شركة الأخبار.
• لنفترض أن هناك شركة تريد إنشاء تطبيقات منفصلة للمحادثة والبريد والتقويم، وتريدها أن تعمل كتطبيقات فردية مرتبطة باسم الشركة.

استخدام مصادر منفصلة

النهج الموصى به في مثل هذه الحالات ينطبق على كل تطبيق مختلف من حيث مفهومه ومصدره الخاص.

إذا كنت تريد استخدام اسم النطاق نفسه بداخل كل منها، يمكنك إجراء ذلك باستخدام النطاقات الفرعية. على سبيل المثال، يمكن لشركة توفر العديد من التطبيقات أو الخدمات على الإنترنت استضافة تطبيق بريد على https://mail.example.com وتطبيق تقويم على https://calendar.example.com، مع تقديم الخدمة الرئيسية لنشاطها التجاري في https://www.example.com. مثال آخر هو موقع إلكتروني رياضي يريد إنشاء تطبيق مستقل مخصّص بالكامل لحدث رياضي مهم، مثل بطولة كرة قدم في https://footballcup.example.com، يمكن للمستخدمين تثبيته واستخدامه بشكل مستقل عن الموقع الإلكتروني الرياضي الرئيسي الذي تتم استضافته في https://www.example.com. قد يكون هذا النهج مفيدًا أيضًا للأنظمة الأساسية التي تتيح للعملاء إنشاء تطبيقات مستقلة خاصة بهم تحت العلامة التجارية للشركة. على سبيل المثال، تطبيق يتيح للتجّار إنشاء تطبيقات الويب التقدّمية الخاصة بهم على https://merchant1.example.com وhttps://merchant2.example.com وغير ذلك.

يضمن استخدام مصادر مختلفة العزلة بين التطبيقات، ما يعني أنّ كل تطبيق يمكنه إدارة ميزات المتصفّح المختلفة بشكل مستقل، بما في ذلك:

• قابلية التثبيت: لكلّ تطبيق بيان خاص به ويوفّر تجربة خاصة به للتثبيت.
• مساحة التخزين: لكل تطبيق ذاكرات تخزين مؤقتة خاصة به ومساحة تخزين محلية وجميع أشكال مساحة التخزين على الجهاز بدون مشاركتها مع التطبيقات الأخرى.
• مشغِّلو الخدمات: يتضمّن كل تطبيق مشغّل خدمات خاص به للنطاقات المُسجَّلة.
• الأذونات: يتم أيضًا تحديد نطاق الأذونات حسب المصادر. وبفضل ذلك، سيعرف المستخدمون بالضبط الخدمة التي يمنحون الأذونات لها، وستتم إضافة ميزات مثل الإشعارات بشكلٍ صحيح إلى كل تطبيق.

إنّ إنشاء مثل هذه الدرجة من العزلة هو الخيار الأكثر ربحًا في حالة استخدام تطبيقات الويب التقدّمية المتعددة والمستقلة، لذا ننصحك بشدة باستخدام هذا النهج.

إذا أرادت التطبيقات على النطاقات الفرعية مشاركة البيانات المحلية مع بعضها البعض، سيظل بإمكانها إجراء ذلك عبر ملفات تعريف الارتباط، أو في سيناريوهات أكثر تقدمًا، يمكنها التفكير في مزامنة مساحة التخزين من خلال خادم.

تستخدم المصدر نفسه.

والنهج الثاني هو إنشاء تطبيقات ويب تقدّمية (PWA) مختلفة على المصدر نفسه. ويشمل ذلك السيناريوهات التالية:

مسارات غير متداخلة

تطبيقات ويب تقدّمية (PWA) متعدّدة أو "تطبيقات ويب" مفاهيمية، مستضافة على المصدر نفسه، مع مسارات غير متداخلة مثال:

• https://example.com/app1/
• https://example.com/app2/

المسارات المتداخلة/المدمجة

تطبيقات PWA متعددة على المصدر نفسه، أحدهما متداخل في نطاقه الآخر:

• https://example.com/ ("التطبيق الخارجي")
• https://example.com/app/ ("التطبيق الداخلي")

تتيح لك واجهة برمجة تطبيقات مشغّل الخدمات وتنسيق البيان تنفيذ أحد الإجراءَين السابقَين، باستخدام تحديد نطاق على مستوى المسار. ومع ذلك، في كلتا الحالتين، يؤدي استخدام المصدر نفسه إلى ظهور الكثير من المشاكل والقيود، ويرجع جذورها إلى أنّ المتصفح لن يعتبرها تمامًا "تطبيقات" مختلفة، لذلك لا ننصح بهذا الأسلوب.

في القسم التالي، نحلّل هذه التحديات بمزيد من التفصيل، وما يمكن فعله، إذا لم يكن استخدام المصادر المنفصلة خيارًا متاحًا.

تحديات لتطبيقات الويب التقدّمية (PWA) المتعدّدة ذات المصدر نفسه

في ما يلي بعض المشاكل العملية المشتركة بين منهجَين من المصدر نفسه:

• مساحة التخزين: تتم مشاركة ملفات تعريف الارتباط ومساحة التخزين المحلية وجميع أشكال التخزين على الجهاز بين التطبيقات. لهذا السبب، إذا قرَّر المستخدم محو البيانات المحلية لتطبيق واحد، سيتم حجب جميع البيانات من المصدر ولا تتوفّر أي طريقة لإجراء ذلك لتطبيق واحد. ويُرجى ملاحظة أنّ Chrome وبعض المتصفحات الأخرى سيطلب من المستخدمين بشكل نشط حجب البيانات المحلية عند إلغاء تثبيت أحد التطبيقات، وسيؤثّر ذلك في بيانات التطبيقات الأخرى على المصدر أيضًا. هناك مشكلة أخرى وهي أنّه على التطبيقات أيضًا مشاركة حصة مساحة التخزين الخاصة بها، ما يعني أنّه إذا شغل أي منهما مساحة كبيرة جدًا، سيتأثر التطبيق الآخر سلبًا.
• الأذونات: ترتبط الأذونات بالمصدر. ويعني هذا أنّه في حال منح المستخدم إذنًا لتطبيق واحد، سيتم تطبيقه على جميع التطبيقات على ذلك المصدر في الوقت نفسه. قد يبدو ذلك أمرًا جيدًا (عدم الحاجة إلى طلب الإذن عدة مرات)، ولكن تذكر: إذا حظر المستخدم الإذن لأحد التطبيقات، فسيمنع ذلك الآخرين من طلب ذلك الإذن أو استخدام تلك الميزة.
• إعدادات المستخدم: يتم ضبط الإعدادات أيضًا حسب المصدر. على سبيل المثال، إذا كان هناك تطبيقان بأحجام خطوط مختلفة، وأراد المستخدم ضبط التكبير في مستوى واحد فقط منهما لتعويض ذلك، فلن يتمكن من القيام بذلك بدون تطبيق الإعداد على التطبيقات الأخرى أيضًا.

وتجعل هذه التحديات من الصعب تعزيز هذا النهج. ومع ذلك، إذا لم تتمكّن من استخدام مصدر منفصل (مثلاً نطاق فرعي) من خلال خيارَي المصدر نفسه اللذين قدّمناهما في قسم استخدام مصادر منفصلة، يُنصح بشدة باستخدام مسارات غير متداخلة، وذلك على مستوى المسارات المتداخلة/المدمجة.

كما ذكرنا، إنّ التحديات التي تتم مناقشتها في هذا القسم شائعة لكل من منهجَي المصدر نفسه. في القسم التالي، سنتعمق أكثر في تفاصيل سبب كون استخدام المسارات المتداخلة/المدمجة أقل استراتيجية ننصح بها.

التحديات الإضافية للمسارات المتداخلة/المدمجة

المشكلة الإضافية في نهج المسارات المتداخلة/المدمجة (حيث https://example.com/ هو التطبيق الخارجي وhttps://example.com/app/ هو التطبيق الداخلي)، هي أنّ جميع عناوين URL في التطبيق الداخلي سيتم اعتبارها جزءًا من كل من التطبيق الخارجي والتطبيق الداخلي.

من الناحية العملية، يعرض هذا المشاكل التالية:

• الترويج للتثبيت: إذا زار المستخدم التطبيق الداخلي (في متصفِّح الويب مثلاً)، عندما يكون التطبيق الخارجي مثبّتًا من قبل على جهاز المستخدم، لن يعرض المتصفّح إعلانات البانر الترويجية للتثبيت، ولن يتم تشغيل حدث beforeInstallPrompt. يرجع السبب في ذلك إلى أنّ المتصفّح سيتحقّق مما إذا كانت الصفحة الحالية تابعة لتطبيق سبق وتم تثبيته، وسيستنتج ذلك. والحل البديل لذلك هو تثبيت التطبيق الداخلي يدويًا (من خلال خيار قائمة المتصفح "إنشاء اختصار") أو تثبيت التطبيق الداخلي أولاً قبل التطبيق الخارجي.
• الإشعار وواجهة برمجة التطبيقات لوضع الشارات: إذا كان التطبيق الخارجي مثبّتًا ولكنّه غير مثبّت، ستُنسَب عن طريق الخطأ الإشعارات والشارات الواردة من التطبيق الداخلي إلى التطبيق الخارجي (وهو أقرب نطاق تضمين لتطبيق مثبَّت). تعمل هذه الميزة بشكل صحيح في حالة تثبيت كلا التطبيقين على جهاز المستخدم.
• التقاط الروابط: قد يلتقط التطبيق الخارجي عناوين URL التي تنتمي إلى التطبيق الداخلي. ومن المحتمل أن يحدث ذلك بشكل خاص إذا كان التطبيق الخارجي مثبّتًا على عكس التطبيق الداخلي. وبالمثل، فإن الروابط داخل التطبيق الخارجي التي ترتبط بالتطبيق الداخلي لن تربط الالتقاط داخل التطبيق الداخلي، لأنها تُعتبر ضمن نطاق التطبيق الخارجي. بالإضافة إلى ذلك، في نظامي التشغيل ChromeOS وAndroid، في حال إضافة هذه التطبيقات إلى "متجر Play" (كأنشطة ويب موثوقة)، سيسجّل التطبيق الخارجي جميع الروابط. حتى إذا تم تثبيت التطبيق الداخلي، فسيظل نظام التشغيل يقدم للمستخدم خيار فتحها في التطبيق الخارجي.

الخلاصة

تناولنا في هذه المقالة الطرق المختلفة التي يمكن من خلالها للمطوّرين إنشاء تطبيقات ويب تقدّمية متعدّدة مرتبطة ببعضها البعض ضمن النطاق نفسه.

باختصار، ننصح بشدة باستخدام مصدر مختلف (على سبيل المثال باستخدام النطاقات الفرعية) لاستضافة تطبيقات الويب التقدّمية المستقلة. وتمثل استضافتها على نفس المصدر الكثير من التحديات، ويرجع ذلك أساسًا إلى أن المتصفح لن يأخذها في الاعتبار كتطبيقات مختلفة.

• مصادر منفصلة: إجراء مقترَح
• المصدر نفسه، مسارات غير متداخلة: لا يُنصَح به
• المصدر نفسه، ومسارات متداخلة/متداخلة: لا يُنصح بهذا الإجراء أبدًا

إذا لم يكن من الممكن استخدام مصادر مختلفة، باستخدام مسارات غير متداخلة (مثل https://example.com/app1/ وhttps://example.com/app2/، ننصح بشدة باستخدام مسارات متداخلة أو متداخلة، مثل https://example.com/ (للتطبيق الخارجي) وhttps://example.com/app/ (للتطبيق الداخلي).

مراجع إضافية

• تطبيقات الويب التقدّمية في مواقع إلكترونية متعددة المصادر

مع جزيل الشكر على مراجعاتهم الفنية واقتراحاتهم: جو ميدلي و"دومينيك إن جي" و"آلان كاتر" و"دانيال ميرفي" و"بيني ماكلاشلان" و"توماس شتاينر" و"داروين هوانغ"

صورة من تصوير تيم موسولد على قناة UnLaunch