كيفية إنشاء تطبيقات متقدّمة متعددة للويب، والاستفادة من اسم النطاق نفسه، لإعلام المستخدم بأنّها تنتمي إلى المؤسسة أو الخدمة نفسها
في مقالة المدونة "تطبيقات الويب التقدّمية في المواقع الإلكترونية التي تتضمّن مصادر متعددة" ، ناقش "ديميان" التحديات التي تواجه المواقع الإلكترونية التي تم إنشاؤها من مصادر متعددة عند محاولة إنشاء تطبيق ويب تقدّمي واحد يشملها جميعًا.
ومن الأمثلة على هذا النوع من بنية الموقع الإلكتروني موقع تجارة إلكترونية يتضمّن ما يلي:
- يمكن العثور على الصفحة الرئيسية على الرابط
https://www.example.com. - تتم استضافة صفحات الفئات على الرابط
https://category.example.com. - يمكنك الاطّلاع على صفحات تفاصيل المنتج على
https://product.example.com.
كما هو موضّح في المقالة، تفرض سياسة المصدر نفسه قيودًا متعددة، ما يمنع مشاركة مهام الخدمة وذاكرات التخزين المؤقت والأذونات على مستوى جميع المصادر. لهذا السبب، ننصحك بشدة بتجنُّب هذا النوع من الإعدادات، وننصح مالكي المواقع الإلكترونية التي تم إنشاؤها بهذه الطريقة بالتفكير في نقل بياناتها إلى بنية موقع إلكتروني واحد عند الإمكان.
في هذه المشاركة، نلقي نظرة على الحالة المعاكسة: بدلاً من تطبيق متعدّد الخدمات التقدّمية (PWAs) على مصادر مختلفة، سنحلّل حالة الشركات التي تريد توفير تطبيقات متعدّدة متقدّمة (PWAs)، والاستفادة من اسم النطاق نفسه، وإعلام المستخدم بأنّ تطبيقات متعدّدة متقدّمة (PWAs) هذه تنتمي إلى المؤسسة أو الخدمة نفسها.
كما قد لاحظت، نستخدم مصطلحات مختلفة ولكنها مترابطة، مثل النطاقات والأصول. قبل المضي قدمًا، لنراجع هذه المفاهيم.
المصطلحات الفنية
- النطاق: أي تسلسل من التصنيفات على النحو المحدّد في نظام أسماء النطاقات (DNS).
على سبيل المثال:
comوexample.comهما نطاقان. - اسم المضيف: إدخال نظام أسماء النطاقات الذي يُحلّل إلى عنوان IP واحد على الأقل على سبيل المثال:
www.example.comسيكون اسم مضيف، وexample.comيمكن أن يكون اسم مضيف إذا كان لديه عنوان IP، ولن يتم تحويلcomأبدًا إلى عنوان IP ، وبالتالي لا يمكن أن يكون اسم مضيف. - المصدر: هو مزيج من مخطط واسم المضيف ومنفذ (اختياري). على سبيل المثال،
https://www.example.com:443هو مصدر.
كما يوحي الاسم، تفرض سياسة المحتوى من المصدر نفسه قيودًا على المصادر، لذلك سنشير إلى هذا المصطلح في معظم أقسام المقالة. ومع ذلك، سنستخدم "النطاقات" أو "النطاقات الفرعية" من وقت إلى آخر لوصف التقنية المستخدَمة من أجل إنشاء "المصادر" المختلفة.
حالة تطبيقات الويب التقدّمية المتعددة (PWA) ذات الصلة
في بعض الحالات، قد تحتاج إلى إنشاء تطبيقات مستقلة، ولكنك لا تزال تريد تحديدها على أنّها تابعة للمؤسسة أو "العلامة التجارية" نفسها. إنّ إعادة استخدام اسم النطاق نفسه هو طريقة جيدة لإنشاء هذه العلاقة. على سبيل المثال:
- يريد موقع إلكتروني للتجارة الإلكترونية إنشاء تجربة مستقلة للسماح للبائعين بإدارة مستودعهم، مع التأكّد من أنّهم يدركون أنّه ينتمي إلى الموقع الإلكتروني الرئيسي الذي يشتري منه المستخدمون المنتجات.
- يريد أحد المواقع الإخبارية الرياضية إنشاء تطبيق معيّن لحدث رياضي كبير، للسماح للمستخدمين بتلقّي إحصاءات حول المنافسات المفضّلة لديهم من خلال الإشعارات، وتثبيت التطبيق كتطبيق ويب تقدّمي مع التأكّد من أنّ المستخدمين يتعرّفون عليه باعتباره تطبيقًا من ابتكار شركة الأخبار.
- تريد شركة إنشاء تطبيقات محادثة وبريد إلكتروني وتقويم منفصلة وتريد أن تعمل كتطبيقات فردية مرتبطة باسم الشركة.
استخدام مصادر منفصلة
والنهج الموصى به في مثل هذه الحالات هو لكل تطبيق متميز من الناحية النظرية يكون منشورًا على أصله.
إذا كنت تريد استخدام اسم النطاق نفسه بداخلها، يمكنك إجراء ذلك باستخدام النطاقات الفرعية. على سبيل المثال، يمكن لشركة تقدّم عدة تطبيقات أو خدمات على الإنترنت أن تستضيف تطبيق بريد إلكتروني على https://mail.example.com وتطبيق تقويم على
https://calendar.example.com، مع تقديم الخدمة الرئيسية لنشاطها التجاري على https://www.example.com. مثال آخر هو موقع إلكتروني رياضي يريد
إنشاء تطبيق مستقل مخصّص بالكامل لحدث رياضي مهم، مثل بطولة كرة قدم في https://footballcup.example.com، يمكن
للمستخدمين تثبيته واستخدامه بشكل مستقل عن الموقع الإلكتروني الرياضي الرئيسي المستضاف على
https://www.example.com. قد يكون هذا النهج مفيدًا أيضًا للمنصّات التي تسمح للعملاء بإنشاء تطبيقات مستقلة خاصة بهم تحت علامة الشركة التجارية.
على سبيل المثال، تطبيق يتيح للتجّار إنشاء تطبيقات ويب تقدّمية (PWA) خاصة بهم على
https://merchant1.example.com وhttps://merchant2.example.com وغير ذلك.
يضمن استخدام مصادر مختلفة عزل التطبيقات، ما يعني أنّه يمكن لكل منها إدارة ميزات المتصفّح المختلفة بشكل مستقل، بما في ذلك:
- قابلية التثبيت: يحتوي كل تطبيق على بيان خاص به ويقدّم تجربة تثبيت خاصة به.
- مساحة التخزين: يتوفّر لكل تطبيق ذاكرات تخزين مؤقتة ومساحة تخزين محلية، بالإضافة إلى جميع أشكال مساحة التخزين على الجهاز، بدون مشاركتها مع التطبيقات الأخرى.
- خدمة العمال: يحتوي كل تطبيق على خدمة عامل خاصة به للملف الشخصي المسجَّل.
- الأذونات: يتم أيضًا تحديد نطاق الأذونات حسب المصادر. وبفضل ذلك، سيصبح بإمكان المستخدمين معرفة الخدمة التي يمنحون أذونات لها بالضبط، وسيكون بإمكانهم تحديد مصدر ميزات مثل الإشعارات بشكلٍ صحيح.
إنّ توفير هذا المستوى من العزل هو الخيار الأكثر رواجًا في حالة استخدام التطبيقات المتوافقة مع معايير الويب المتعددة والمستقلة، لذا ننصح بشدة باتّباع هذا النهج.
إذا أرادت التطبيقات على النطاقات الفرعية مشاركة البيانات المحلية مع بعضها، سيظل بإمكانها إجراء ذلك من خلال ملفات تعريف الارتباط، أو في سيناريوهات أكثر تقدمًا، يمكنها التفكير في مزامنة مساحة التخزين من خلال خادم.
باستخدام المصدر نفسه
أما المنهج الثاني، فهو إنشاء تطبيقات الويب التقدّمية المختلفة على المصدر نفسه. ويشمل ذلك السيناريوهات التالية:
المسارات غير المتداخلة
تطبيقات ويب متعدّدة أو "تطبيقات ويب" ذات مفهوم جديد مستضافة على المصدر نفسه، مع مسارات غير متداخلة على سبيل المثال:
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. والسبب في ذلك هو أنّ المتصفّح سيتحقّق ممّا إذا كانت الصفحة الحالية تنتمي إلى تطبيق مثبّت، وسيتوصّل إلى نتيجة مفادها أنّه كذلك. ويتمثل الحلّ في تثبيت التطبيق الداخلي يدوياً (من خلال خيار "إنشاء اختصار" في قائمة المتصفّح)، أو تثبيت التطبيق الداخلي أولاً قبل التطبيق الخارجي.
- Notification API وBadging API: إذا كان التطبيق الخارجي مثبّتًا ولكن التطبيق الداخلي غير مثبّت، سيتم إسناد الإشعارات والشارات الواردة من التطبيق الداخلي عن طريق الخطأ إلى التطبيق الخارجي (الذي يمثّل أقرب نطاق شامل لتطبيق مثبّت). تعمل هذه الميزة بشكل صحيح في حال تثبيت كلا التطبيقَين على جهاز المستخدم.
- جمع الروابط: قد يجمع التطبيق الخارجي عناوين URL التي تنتمي إلى التطبيق الداخلي، ويُرجى العِلم أنّه من المرجّح حدوث ذلك بشكل خاص إذا كان التطبيق الخارجي مثبّتًا ولكن التطبيق الداخلي غير مثبّت. وبالمثل، لن يؤدي استخدام الروابط داخل التطبيق الخارجي التي تؤدي إلى التطبيق الداخلي إلى تسجيل الروابط في التطبيق الداخلي، لأنّها تُعتبر ضمن نطاق التطبيق الخارجي. بالإضافة إلى ذلك، على أجهزة ChromeOS وAndroid، إذا تمت إضافة هذه التطبيقات إلى "متجر Play" (بصفتها أنشطة ويب موثوق بها)، سيحتسِب التطبيق الخارجي جميع الروابط. حتى إذا كان التطبيق الداخلي مثبّتًا، سيظل نظام التشغيل يقدّم للمستخدم خيار فتحه في التطبيق الخارجي.
الخاتمة
في هذه المقالة، اطّلعنا على الطرق المختلفة التي يمكن للمطوّرين من خلالها إنشاء تطبيقات ويب تقدّمية متعددة مرتبطة ببعضها ضمن النطاق نفسه.
باختصار، ننصحك بشدة باستخدام مصدر مختلف (مثلاً باستخدام ملف subdomains) لاستضافة تطبيقات متجر بلاي للأعمال المستقلة. ويواجه استضافتهم في نفس المصدر العديد من التحديات، ويرجع ذلك أساسًا إلى أن المتصفح لن يعتبرها تطبيقات مختلفة تمامًا.
- مصادر منفصلة: إجراء يُنصح به
- المصدر نفسه، والمسارات غير المتداخلة: غير مقترَح
- المصدر نفسه مع مسارات متداخلة أو متداخلة: لا ننصح باستخدامه بشدة
إذا لم يكن من الممكن استخدام مصادر مختلفة، ننصح بشدة باستخدام مسارات غير متداخلة (مثل
https://example.com/app1/ وhttps://example.com/app2/) بدلاً من استخدام مسارات متداخلة أو متداخلة، مثل https://example.com/
(للتطبيق الخارجي) وhttps://example.com/app/ (للتطبيق الداخلي).
مراجع إضافية
مع جزيل الشكر على المراجعات الفنية والاقتراحات: جو ميديل، دومينيك نج، وألان كاتلر، ودانيل ميرفي، وبنّي ماكلاشان، وتوم شتاينر، ودارون هوانغ
صورة التقطها تيم موسبورن على قناة Unفاق