Créer plusieurs progressive web apps sur le même domaine

Créer plusieurs PWA en tirant parti du même nom de domaine pour informer l'utilisateur qu'il appartient à la même organisation ou au même service

Chase Phillips

Demián Renzulli

Matt Giuca

Dans l'article de blog sur les progressive web apps in multi-origines, Demian a décrit les défis auxquels les sites construits sur plusieurs origines sont confrontés lorsqu'ils tentent de créer une seule progressive web app englobant toutes ces applications.

Il peut s'agir, par exemple, d'un site d'e-commerce dans lequel:

• La page d'accueil se trouve à l'adresse https://www.example.com.
• Les pages de catégorie sont hébergées sur https://category.example.com.
• Pages d'informations détaillées sur le produit à l'adresse https://product.example.com.

Comme indiqué dans l'article, la règle sur la même origine impose plusieurs restrictions qui empêchent le partage de service workers, de caches et d'autorisations entre les origines. C'est pourquoi nous vous recommandons vivement d'éviter ce type de configuration et, pour ceux qui ont déjà des sites créés de cette manière, d'envisager de migrer vers une architecture de site à origine unique dans la mesure du possible.

Évitez d'utiliser des origines différentes pour les sections d'un même site lorsque vous essayez de créer une application Web progressive unifiée.

Dans cet article, nous allons examiner le cas inverse: au lieu d'utiliser une seule PWA pour différentes origines, nous analyserons le cas d'entreprises qui souhaitent fournir plusieurs PWA en tirant parti du même nom de domaine, et indiquer à l'utilisateur que ces PWA appartiennent à la même organisation ou au même service.

Comme vous l'avez peut-être remarqué, nous utilisons des termes différents, mais liés entre eux, comme les domaines et les origines. Avant de continuer, examinons ces concepts.

Termes techniques

• Domaine:n'importe quelle séquence de libellés, telle que définie dans le système de noms de domaine (DNS). Par exemple, com et example.com sont des domaines.
• Nom d'hôte:entrée DNS qui résout au moins une adresse IP. Par exemple, www.example.com pourrait être un nom d'hôte, example.com pourrait être un nom d'hôte s'il avait une adresse IP, et com ne serait jamais résolu en une adresse IP et donc il ne pourrait jamais être un nom d'hôte.
• Origine:combinaison d'un schéma, d'un nom d'hôte et (éventuellement) d'un port. Par exemple, https://www.example.com:443 est une origine.

Comme son nom l'indique, le règlement concernant la même origine impose des restrictions sur les origines. Nous ferons donc référence à ce terme dans tout l'article. Néanmoins, nous utiliserons de temps en temps des "domaines" ou "sous-domaines" pour décrire la technique employée afin de créer les différentes "origines".

Avantages de plusieurs PWA associées

Dans certains cas, vous pouvez créer des applications indépendantes, tout en les identifiant comme appartenant à la même organisation ou à la même "marque". Réutiliser le même nom de domaine est un bon moyen d'établir cette relation. Exemple :

• Un site d'e-commerce souhaite créer une expérience autonome pour permettre aux vendeurs de gérer leur inventaire, tout en s'assurant qu'ils comprennent qu'il appartient au site Web principal sur lequel les utilisateurs achètent les produits.
• Un site d'actualités sportives souhaite créer une application spécifique pour un événement sportif majeur, afin de permettre aux utilisateurs de recevoir des statistiques sur leurs compétitions préférées via des notifications et de l'installer en tant que progressive web app, tout en s'assurant que les utilisateurs la reconnaissent comme une application conçue par la société de presse.
• Une entreprise souhaite créer des applications de chat, de messagerie et d'agenda distinctes, et souhaite qu'elles fonctionnent en tant qu'applications individuelles liées au nom de l'entreprise.

L'entreprise propriétaire d'example.com souhaite fournir trois applications ou PWA indépendantes en utilisant le même nom de domaine pour établir la relation entre elles.

Utiliser des origines distinctes

Dans de tels cas, l'approche recommandée consiste à mettre en ligne chaque application conceptuellement distincte sur sa propre origine.

Si vous souhaitez utiliser le même nom de domaine dans chacun d'eux, vous pouvez utiliser des sous-domaines. Par exemple, une entreprise qui fournit plusieurs applications ou services Internet peut héberger une application de messagerie sur https://mail.example.com et une application d'agenda dans https://calendar.example.com, tout en proposant le service principal de son entreprise à https://www.example.com. Autre exemple : un site sportif qui souhaite créer une application indépendante entièrement dédiée à un événement sportif important, tel qu'un championnat de football à https://footballcup.example.com, que les utilisateurs peuvent installer et utiliser indépendamment du site de sport principal hébergé à https://www.example.com. Cette approche peut également être utile pour les plates-formes permettant aux clients de créer leurs propres applications indépendantes sous la marque de l'entreprise. Par exemple, une application qui permet aux marchands de créer leurs propres PWA sur https://merchant1.example.com, https://merchant2.example.com, etc.

L'utilisation de différentes origines garantit l'isolation entre les applications, ce qui signifie que chacune d'elles peut gérer différentes fonctionnalités du navigateur de manière indépendante, y compris:

• Facilité d'installation:chaque application a son propre fichier manifeste et fournit sa propre expérience à installer.
• Stockage:chaque application possède ses propres caches, son propre espace de stockage local, et essentiellement toutes les formes de stockage local de l'appareil, sans les partager avec les autres.
• Service worker:chaque application possède son propre service worker pour les niveaux d'accès enregistrés.
• Autorisations:les autorisations sont également définies par origine. Grâce à cela, les utilisateurs sauront exactement pour quel service ils accordent des autorisations, et des fonctionnalités telles que les notifications seront correctement attribuées à chaque application.

Créer un tel degré d'isolation est le plus souhaitable dans le cas d'utilisation de plusieurs PWA indépendantes. C'est pourquoi nous vous recommandons vivement cette approche.

Si les applications situées sur des sous-domaines souhaitent partager des données locales entre elles, elles peuvent toujours le faire via des cookies. Pour des scénarios plus avancés, elles peuvent également synchroniser le stockage via un serveur.

Il est recommandé de créer différentes PWA dans des origines distinctes, à l'aide de sous-domaines.

Utiliser la même origine

La deuxième approche consiste à créer les différentes PWA sur la même origine. Cela inclut les scénarios suivants:

Tracés qui ne se chevauchent pas

Plusieurs PWA ou "applications Web" conceptuelles, hébergées sur la même origine, avec des chemins d'accès qui ne se chevauchent pas Exemple :

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

Chevauchement/trajets imbriqués

Plusieurs PWA d'origine, dont le champ d'application est imbriqué dans l'autre:

• https://example.com/ (l'"application externe")
• https://example.com/app/ (l'application interne)

L'API Service Worker et le format de fichier manifeste vous permettent d'effectuer l'une des opérations ci-dessus, à l'aide d'un champ d'application au niveau du chemin. Toutefois, dans les deux cas, l'utilisation de la même origine présente de nombreux problèmes et limites, dont la cause provient du fait que le navigateur ne les considérera pas comme des "applications" distinctes. Par conséquent, cette approche est déconseillée.

Nous vous déconseillons d'utiliser des chemins (qui se chevauchent ou non) pour fournir deux PWA indépendantes ("app1", "app2") sous la même origine.

Dans la section suivante, nous analyserons ces défis plus en détail et ce que vous pouvez faire s'il n'est pas possible d'utiliser des origines distinctes.

Défis liés à plusieurs PWA de même origine

Voici quelques problèmes pratiques communs aux deux approches de même origine:

• Stockage:les cookies, le stockage local et toutes les formes de stockage local de l'appareil sont partagés entre les applications. Pour cette raison, si l'utilisateur décide d'effacer les données locales d'une application, toutes les données de l'origine seront effacées. Notez que Chrome et d'autres navigateurs invitent activement les utilisateurs à effacer les données locales lors de la désinstallation de l'une des applications, ce qui affectera également les données des autres applications d'origine. Un autre problème est que les applications doivent également partager leur quota de stockage, ce qui signifie que si l'un d'entre eux prend trop d'espace, l'autre en sera affecté.
• Autorisations:les autorisations sont liées à l'origine. Cela signifie que si l'utilisateur accorde une autorisation à une application, celle-ci s'appliquera simultanément à toutes les applications de cette origine. Cela peut sembler être une bonne chose (ne pas avoir à demander une autorisation plusieurs fois), mais n'oubliez pas que si l'utilisateur bloque l'autorisation d'une application, les autres ne pourront pas demander cette autorisation ou utiliser cette fonctionnalité.
• Paramètres utilisateur:les paramètres sont également définis par origine. Par exemple, si deux applications ont des tailles de police différentes et que l'utilisateur souhaite ajuster le zoom dans une seule d'entre elles pour compenser cela, il ne pourra pas le faire sans appliquer le paramètre aux autres applications également.

Compte tenu de ces difficultés, il est difficile d'encourager cette approche. Néanmoins, si vous ne pouvez pas utiliser une origine distincte (par exemple, un sous-domaine), comme indiqué dans la section Utiliser des origines distinctes, nous vous recommandons vivement d'utiliser des chemins d'accès qui ne se chevauchent pas plutôt que des chemins qui se chevauchent ou qui sont imbriqués.

Comme indiqué, les défis abordés dans cette section sont communs aux deux approches de même origine. Dans la section suivante, nous verrons plus en détail pourquoi l'utilisation de chemins qui se chevauchent/imbriquement est la stratégie la moins recommandée.

Autres défis liés aux chemins qui se chevauchent/imbriquement

Le problème supplémentaire lié à l'approche des chemins qui se chevauchent/imbriquement (où https://example.com/ est l'application externe et https://example.com/app/ est l'application interne) est que toutes les URL de l'application interne seront considérées comme faisant partie à la fois de l'application externe et de l'application interne.

En pratique, cela présente les problèmes suivants:

• Promotion d'installation:si l'utilisateur accède à l'application interne (dans un navigateur Web, par exemple), lorsque l'application externe est déjà installée sur son appareil, le navigateur n'affiche pas les bannières promotionnelles d'installation et l'événement "BeforeInstallPrompt" ne se déclenche pas. En effet, le navigateur vérifie si la page actuelle appartient à une application déjà installée, et il en conclut que c'est le cas. La solution de contournement consiste à installer manuellement l'application interne (via l'option de menu "Créer un raccourci" du navigateur) ou à installer l'application interne en premier, avant l'application externe.
• Notification et API Badging: si l'application externe est installée, mais pas l'application interne, les notifications et les badges provenant de l'application interne seront attribués par erreur à l'application externe (qui est le champ d'application le plus proche d'une application installée). Cette fonctionnalité fonctionne correctement lorsque les deux applications sont installées sur l'appareil de l'utilisateur.
• Capture de lien : l'application externe peut capturer les URL appartenant à l'application interne. Cela est particulièrement probable si l'application externe est installée, mais pas l'application interne. De même, les liens de l'application externe qui renvoient à l'application interne ne seront pas capturés dans l'application interne, car ils sont considérés comme faisant partie du champ d'application de l'application externe. De plus, sur ChromeOS et Android, si ces applications sont ajoutées au Play Store (en tant que Activités Web approuvées), l'application externe capturera tous les liens. Même si l'application interne est installée, le système d'exploitation offre toujours à l'utilisateur la possibilité de les ouvrir dans l'application externe.

Conclusion

Dans cet article, nous avons examiné les différentes façons dont les développeurs peuvent créer plusieurs progressive web apps liées les unes aux autres dans le même domaine.

En résumé, nous vous recommandons vivement d'utiliser une origine différente (en utilisant des sous-domaines, par exemple) pour héberger des PWA indépendantes. Leur hébergement dans la même origine présente de nombreux défis, principalement parce que le navigateur ne les considérera pas comme des applications distinctes.

• Origines distinctes: recommandé
• Origine identique, chemins ne se chevauchant pas: déconseillé
• Origine identique, chemins qui se chevauchent/imbriquement: Pas du tout recommandé

S'il n'est pas possible d'utiliser des origines différentes, il est fortement recommandé d'utiliser des chemins qui ne se chevauchent pas (par exemple, https://example.com/app1/ et https://example.com/app2/) plutôt que des chemins qui se chevauchent ou sont imbriqués, tels que https://example.com/ (pour l'application externe) et https://example.com/app/ (pour l'application interne).

Ressources supplémentaires

• Progressive web apps sur des sites multi-origines

Nous vous remercions pour leurs avis techniques et leurs suggestions: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner et Darwin Huang.

Photo par Tim Mossholder, publiée sur Unsplash