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

Créer plusieurs applications Web progressives en utilisant le même nom de domaine pour indiquer à l'utilisateur qu'elles appartiennent à la même organisation ou au même service

Chase Phillips

Demián Renzulli

Matt Giuca

Dans l'article de blog sur les PWA sur les sites multi-origines, Demian a évoqué les défis auxquels sont confrontés les sites basés sur plusieurs origines lorsqu'ils tentent de créer une seule PWA qui les englobe tous.

Un exemple de ce type d'architecture de site est 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.
• Les pages d'informations détaillées sur les produits sur https://product.example.com.

Comme indiqué dans l'article, la règle de même origine impose plusieurs restrictions, ce qui empêche 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. Si vous avez déjà créé des sites de cette manière, nous vous conseillons 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 examinons le cas inverse : au lieu d'une seule PWA pour différentes origines, nous allons analyser le cas des entreprises qui souhaitent fournir plusieurs PWA, en utilisant le même nom de domaine et en informant 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 interdépendants, tels que les domaines et les origines. Avant de continuer, récapitulons ces concepts.

Termes techniques

• Domaine : toute séquence de libellés tels que définis 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 est un nom d'hôte, example.com pourrait être un nom d'hôte s'il avait une adresse IP, et com ne sera jamais résolu en adresse IP et ne pourra donc jamais être un nom d'hôte.
• Origine : combinaison d'un schéma, d'un nom d'hôte et (facultatif) d'un port. Par exemple, https://www.example.com:443 est une origine.

Comme son nom l'indique, la règle de même origine impose des restrictions sur les origines. Nous ferons donc généralement référence à ce terme tout au long de l'article. Toutefois, nous utiliserons de temps en temps les termes "domaines" ou "sous-domaines" pour décrire la technique utilisée afin de créer les différentes "origines".

Pourquoi utiliser plusieurs PWA associés ?

Dans certains cas, vous pouvez créer des applications indépendantes, mais les identifier comme appartenant à la même organisation ou "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 des 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 qu'application Web progressive, tout en veillant à ce que les utilisateurs la reconnaissent comme une application créée par la société d'actualités.
• Une entreprise souhaite créer des applications de chat, de messagerie et d'agenda distinctes et souhaite qu'elles fonctionnent comme des applications individuelles, liées au nom de l'entreprise.

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

Utiliser des origines distinctes

Dans ce cas, nous vous recommandons de faire en sorte que chaque application distincte sur le plan conceptuel réside sur sa propre origine.

Si vous souhaitez utiliser le même nom de domaine dans chacun d'eux, vous pouvez le faire à l'aide de 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 sur https://calendar.example.com, tout en proposant le service principal de son entreprise à l'adresse https://www.example.com. Un autre exemple est un site de sport qui souhaite créer une application indépendante entièrement dédiée à un événement sportif important, comme un championnat de football à https://footballcup.example.com, que les utilisateurs peuvent installer et utiliser indépendamment du site de sport principal, hébergé sur https://www.example.com. Cette approche peut également être utile pour les plates-formes qui permettent 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 dans https://merchant1.example.com, https://merchant2.example.com, etc.

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

• Installabilité:chaque application possède son propre fichier manifeste et fournit sa propre expérience installable.
• Stockage : chaque application dispose de ses propres caches, de son propre espace de stockage local et de pratiquement toutes les formes de stockage local sur l'appareil, sans les partager avec les autres.
• Service workers : chaque application dispose de son propre service worker pour les champs d'application enregistrés.
• Autorisations : les autorisations sont également limitées par origine. Grâce à cela, les utilisateurs sauront exactement à 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épendants. Nous recommandons donc vivement cette approche.

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

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

Utiliser la même origine

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

Chemins sans chevauchement

Plusieurs PWA ou "applications Web" conceptuelles, hébergées sur la même origine, avec des chemins non superposés. Exemple :

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

Chemins chevauchants/imbriqués

Plusieurs PWA sur la même origine, dont l'un est imbriqué dans l'autre :

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

L'API et le format de fichier manifeste du service worker vous permettent d'effectuer l'une des opérations ci-dessus à l'aide d'un champ d'application au niveau du chemin d'accès. Toutefois, dans les deux cas, l'utilisation de la même origine présente de nombreux problèmes et limites, dont la racine découle du fait que le navigateur ne considère pas pleinement ces éléments 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") avec la même origine.

Dans la section suivante, nous analysons ces défis plus en détail et ce qui peut être fait si l'utilisation d'origines distinctes n'est pas possible.

Défis liés aux PWA multiples de même origine

Voici quelques problèmes pratiques communs aux deux approches d'origine :

• Stockage : les cookies, l'espace de stockage local et toutes les formes de stockage local sur l'appareil sont partagés entre les applications. Par conséquent, si l'utilisateur décide d'effacer les données locales pour une application, toutes les données de l'origine seront effacées. Il n'est pas possible de le faire pour une seule application. Notez que Chrome et certains 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 de l'origine. Autre problème : les applications doivent également partager leur quota de stockage. Par conséquent, si l'une d'elles occupe trop d'espace, l'autre en sera affectée.
• Autorisations : les autorisations du navigateur sont liées à l'origine. Cela signifie que si l'utilisateur accorde une autorisation à une application, elle s'applique simultanément à toutes les applications de cette origine. Cela peut sembler 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 ni utiliser cette fonctionnalité. Notez que même si les autorisations du navigateur ne doivent être accordées qu'une seule fois par origine, les autorisations au niveau du système doivent être accordées une fois par application, que plusieurs applications pointent vers la même origine ou non.
• 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 ne souhaite ajuster le zoom que dans l'une d'elles pour compenser, il ne pourra pas le faire sans appliquer le paramètre aux autres applications.

Ces défis rendent difficile l'encouragement de 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, à partir des deux options d'origine identique que nous avons présentées, il est vivement recommandé d'utiliser des chemins qui ne se chevauchent pas.

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

Autres difficultés liées aux chemins qui se chevauchent/imbriqués

Le problème supplémentaire lié à l'approche des chemins chevauchants/imbriqués (https://example.com/ étant l'application externe et https://example.com/app/ l'application interne) est que toutes les URL de l'application interne seront en fait considérées comme faisant partie à la fois de l'application externe et de l'application interne.

En pratique, cela pose les problèmes suivants:

• Promotion d'installation : si l'utilisateur accède à l'application interne (par exemple, dans un navigateur Web) lorsque l'application externe est déjà installée sur l'appareil de l'utilisateur, le navigateur n'affiche pas les bannières promotionnelles d'installation et l'événement BeforeInstallPrompt n'est pas déclenché. En effet, le navigateur vérifie si la page actuelle appartient à une application déjà installée et conclut qu'elle l'est. Pour contourner ce problème, vous pouvez installer manuellement l'application interne (via l'option de menu du navigateur "Créer un raccourci") ou installer d'abord l'application interne, 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 englobant le plus proche d'une application installée). Cette fonctionnalité fonctionne correctement si les deux applications sont installées sur l'appareil de l'utilisateur.
• Capture de liens : 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 redirigent vers l'application interne ne captureront pas de lien 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 qu'activités Web fiables), l'application externe capture tous les liens. Même si l'application interne est installée, l'OS offre toujours à l'utilisateur la possibilité de l'ouvrir dans l'application externe.

Conclusion

Dans cet article, nous avons examiné 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 (par exemple, en utilisant des sous-domaines) pour héberger des PWA indépendants. Les héberger sous la même origine présente de nombreux défis, principalement parce que le navigateur ne les considère pas complètement comme des applications distinctes.

• Origines distinctes : recommandé
• Même origine, chemins non chevauchants : non recommandé
• Même origine, chemins d'accès qui se chevauchent/imbriquent: fortement déconseillé

Si vous ne pouvez pas utiliser d'origines différentes, nous vous recommandons vivement d'utiliser des chemins non superposés (par exemple, https://example.com/app1/ et https://example.com/app2/) plutôt que des chemins superposés ou imbriqués, comme https://example.com/ (pour l'application externe) et https://example.com/app/ (pour l'application interne).

Autres ressources

• Progressive web apps sur les sites multi-origines

Merci beaucoup pour leurs avis et suggestions techniques : Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner et Darwin Huang

Photo de Tim Mosshold sur Unsplash