في مشاركة حول تطبيقات الويب التقدّمية في المواقع الإلكترونية المتعددة المصادر، ناقش "ديميان" التحديات التي تواجهها المواقع الإلكترونية المتعددة المصادر عند محاولة إنشاء تطبيق ويب تقدّمي واحد يشملها جميعًا.
من الأمثلة على هذا النوع من بنية المواقع الإلكترونية موقع للتجارة الإلكترونية حيث:
- يمكنك الانتقال إلى الصفحة الرئيسية من خلال
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/ (للتطبيق الداخلي).
مصادر إضافية
نشكر جو ميدلي ودومينيك نغ وآلان كتر ودانيال مورفي وبيني ماكلاكلان وتوماس شتاينر وداروين هوانغ على مراجعاتهم الفنية واقتراحاتهم.