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

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

Chase Phillips

Demián Renzulli

Matt Giuca

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

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

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

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

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

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

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

• النطاق: أي تسلسل من التصنيفات كما هو محدّد في نظام أسماء النطاقات (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 وما إلى ذلك.

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

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

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

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

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

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

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

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

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

المسارات المتداخلة أو المتداخلة

تطبيقات ويب تقدّمية متعددة لها المصدر نفسه، ويكون أحد نطاقاتها مضمّنًا في نطاق الآخر:

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

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

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

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

في ما يلي بعض المشاكل العملية الشائعة في كلتا الطريقتين اللتين تستخدمان المصدر نفسه:

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

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

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

تحديات إضافية للمسارات المتداخلة أو المتداخلة

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

في الواقع، يطرح ذلك المشاكل التالية:

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

الخاتمة

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

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

• مصادر منفصلة: يُنصح بذلك
• المصدر نفسه، المسارات غير المتداخلة: غير مقترَحة
• المصدر نفسه، المسارات المتداخلة أو المتداخلة: لا يُنصح بشدة

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

مراجع إضافية

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

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

صورة مقدَّمة من تيم موشولدر على Unsplash