كيفية إنشاء تطبيقات متقدّمة متعددة للويب، والاستفادة من اسم النطاق نفسه، لإعلام المستخدم بأنّها تنتمي إلى المؤسسة أو الخدمة نفسها
في مقالة المدونة "تطبيقات الويب التقدّمية في المواقع الإلكترونية التي تتضمّن مصادر متعددة"، ناقش "ديميان" التحديات التي تواجهها المواقع الإلكترونية التي تم إنشاؤها من مصادر متعددة عند محاولة إنشاء تطبيق ويب تقدّمي واحد يشملها جميعًا.
ومن الأمثلة على هذا النوع من بنية الموقع الإلكتروني موقع تجارة إلكترونية يتضمّن ما يلي:
- يمكن العثور على الصفحة الرئيسية على الرابط
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هو مصدر.
كما يوحي الاسم، تفرض سياسة المحتوى من المصدر نفسهقيودًا على المصادر، لذلك سنشير إلى هذه السياسة في معظم أقسام المقالة. ومع ذلك، سنستخدم "النطاقات" أو "النطاقات الفرعية" من حين لآخر لوصف التقنية المستخدَمة من أجل إنشاء "المصادر" المختلفة.
أهمية إنشاء تطبيقات متعدّدة ومتعلّقة
في بعض الحالات، قد تحتاج إلى إنشاء تطبيقات مستقلة، ولكنك لا تزال تريد تحديدها على أنّها تابعة للمؤسسة أو "العلامة التجارية" نفسها. إنّ إعادة استخدام اسم النطاق نفسه هو طريقة جيدة لإنشاء هذه العلاقة. على سبيل المثال:
- يريد موقع إلكتروني للتجارة الإلكترونية إنشاء تجربة مستقلة للسماح للبائعين بإدارة مستودعاتهم، مع التأكّد من أنّهم يفهمون أنّها تنتمي إلى الموقع الإلكتروني الرئيسي الذي يشتري منه المستخدمون المنتجات.
- يريد موقع إلكتروني لأخبار الرياضة إنشاء تطبيق معيّن لحدث رياضي كبير، للسماح للمستخدمين بتلقّي إحصاءات عن المسابقات المفضّلة لديهم من خلال الإشعارات، وتثبيته كتطبيق ويب تقدّمي، مع التأكّد من أنّه يُعرَف من قِبل المستخدمين على أنّه تطبيق أنشأته شركة الأخبار.
- تريد شركة إنشاء تطبيقات محادثة وبريد إلكتروني وتقويم منفصلة وتريد أن تعمل هذه التطبيقات كتطبيقات فردية مرتبطة باسم الشركة.
استخدام مصادر منفصلة
إنّ المنهج المُقترَح في مثل هذه الحالات هو أن يتم نشر كل تطبيق مختلف من الناحية المفهومية على مصدره الخاص.
إذا كنت تريد استخدام اسم النطاق نفسه في كلّها، يمكنك إجراء ذلك من خلال
استخدام النطاقات الفرعية. على سبيل المثال، يمكن لشركة تقدّم عدة تطبيقات أو خدمات على الإنترنت أن تستضيف تطبيق بريد إلكتروني على 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 وما إلى ذلك
يضمن استخدام مصادر مختلفة عزل التطبيقات، ما يعني أنّه يمكن لكل منها إدارة ميزات المتصفّح المختلفة بشكل مستقل، بما في ذلك:
- قابلية التثبيت: يحتوي كل تطبيق على بيان خاص به ويقدّم تجربة تثبيت خاصة به.
- التخزين: يتضمّن كل تطبيق ذاكرة التخزين المؤقت ومساحة التخزين المحلية وجميع أشكال التخزين على الجهاز بدون مشاركتها مع التطبيقات الأخرى.
- خدمات Worker: يحتوي كل تطبيق على خدمة 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. والسبب في ذلك هو أنّ المتصفّح سيتحقّق ممّا إذا كانت الصفحة الحالية تنتمي إلى تطبيق تم تثبيته من قبل، وسيتوصّل إلى نتيجة مفادها أنّها تنتمي إلى تطبيق. ويتمثل الحلّ في تثبيت التطبيق الداخلي يدوياً (من خلال خيار "إنشاء اختصار" في قائمة المتصفّح)، أو تثبيت التطبيق الداخلي أولاً، قبل التطبيق الخارجي.
- Notification API وBadging API: إذا كان التطبيق الخارجي مثبّتًا ولكن التطبيق الداخلي غير مثبّت، سيتم إسناد الإشعارات والشارات الواردة من التطبيق الداخلي عن طريق الخطأ إلى التطبيق الخارجي (الذي يمثّل أقرب نطاق شامل لتطبيق مثبّت). تعمل هذه الميزة بشكل صحيح في حال تثبيت كلا التطبيقَين على جهاز المستخدم.
- جمع الروابط: قد يجمع التطبيق الخارجي عناوين URL التي تنتمي إلى التطبيق الداخلي، ويُرجى العِلم أنّه من المرجّح حدوث ذلك بشكل خاص إذا كان التطبيق الخارجي مثبّتًا ولكن التطبيق الداخلي غير مثبّت. وبالمثل، لن يؤدي استخدام الروابط داخل التطبيق الخارجي التي تؤدي إلى التطبيق الداخلي إلى تسجيل الروابط في التطبيق الداخلي، لأنّها تُعتبر ضمن نطاق التطبيق الخارجي. بالإضافة إلى ذلك، على أجهزة ChromeOS وAndroid، إذا تمت إضافة هذه التطبيقات إلى "متجر Play" (بصفتها أنشطة ويب موثوق بها)، سيحتسِب التطبيق الخارجي جميع الروابط. حتى إذا كان التطبيق الداخلي مثبّتًا، سيظل نظام التشغيل يقدّم للمستخدم خيار فتحها في التطبيق الخارجي.
الخاتمة
في هذه المقالة، اطّلعنا على الطرق المختلفة التي يمكن للمطوّرين من خلالها إنشاء تطبيقات ويب تقدّمية متعددة مرتبطة ببعضها ضمن النطاق نفسه.
باختصار، ننصحك بشدة باستخدام مصدر مختلف (مثلاً باستخدام ملف subdomains) لاستضافة تطبيقات متقدّمة للويب مستقلة. ويؤدي استضافتها في المصدر نفسه إلى مثيل العديد من التحديات، ويرجع ذلك بشكل أساسي إلى أنّ المتصفّح لن يتعامل مع هذين التطبيقين كتطبيقَين مختلفَين.
- مصادر منفصلة: إجراء يُنصح به
- المصدر نفسه، والمسارات غير المتداخلة: غير مقترَح
- المصدر نفسه والمسارات المتداخلة/المُدمجة: لا يُنصح به بشدة
إذا لم يكن من الممكن استخدام مصادر مختلفة، ننصح بشدة باستخدام مسارات غير متداخلة (مثل
https://example.com/app1/ وhttps://example.com/app2/) بدلاً من استخدام مسارات متداخلة أو متداخلة، مثل https://example.com/
(للتطبيق الخارجي) وhttps://example.com/app/ (للتطبيق الداخلي).
مراجع إضافية
مع جزيل الشكر على المراجعات الفنية والاقتراحات: جو ميديل، دومينيك نج، وألان كاتلر، ودانيل ميرفي، وبنّي ماكلاشان، وتوم شتاينر، ودارون هوانغ
صورة Tim Mossholder على Unsplash