Mehrere progressive Web-Apps in derselben Domain erstellen

Hier erfahren Sie, wie Sie mehrere PWAs mit demselben Domainnamen erstellen, um Nutzer darauf hinzuweisen, dass sie zu derselben Organisation oder demselben Dienst gehören.

Chase Phillips

Demián Renzulli

Matt Giuca

In seinem Blogpost zu progressiven Web-Apps in Websites mit mehreren Quellen erläuterte er die Herausforderungen, mit denen sich Websites mit mehreren Ursprüngen konfrontiert sehen, wenn es darum geht, eine einzelne progressive Web-App zu entwickeln, die alle diese Plattformen umfasst.

Ein Beispiel für diese Art von Websitearchitektur ist eine E-Commerce-Website, auf der:

• Die Startseite befindet sich unter https://www.example.com.
• Die Kategorieseiten werden auf https://category.example.com gehostet.
• Die Produktdetailseiten unter https://product.example.com.

Wie im Artikel erläutert, schränkt die Richtlinie zum gleichen Ursprung die Freigabe von Service Workers, Caches und Berechtigungen über mehrere Ursprünge hinweg ein. Aus diesem Grund empfehlen wir dringend, diese Art der Konfiguration zu vermeiden und Websites, die bereits auf diese Weise erstellte Websites haben, nach Möglichkeit eine Migration zu einer Architektur mit einem einzigen Ursprung in Betracht zu ziehen.

In diesem Beitrag sehen wir uns den umgekehrten Fall an: Anstatt einer einzelnen PWA mit verschiedenen Ursprüngen betrachten wir den Fall von Unternehmen, die mehrere PWAs bereitstellen möchten, denselben Domainnamen nutzen und die Nutzer darauf hinweisen möchten, dass diese PWAs zu derselben Organisation oder demselben Dienst gehören.

Wie Sie vielleicht bemerkt haben, verwenden wir unterschiedliche, aber miteinander in Beziehung stehende Begriffe wie „Domains“ und „Herkunft“. Bevor wir fortfahren, sehen wir uns diese Konzepte an.

Technische Begriffe

• Domain: Eine beliebige Sequenz von Labels, wie im Domain Name System (DNS) definiert. Beispiel: com und example.com sind Domains.
• Hostname: Ein DNS-Eintrag, der auf mindestens eine IP-Adresse verweist. Beispiel: www.example.com ist ein Hostname, example.com könnte ein Hostname sein, wenn es eine IP-Adresse hätte, und com würde niemals in eine IP-Adresse aufgelöst werden und somit auch nie ein Hostname sein.
• Ursprung:Eine Kombination aus Schema, Hostname und Port (optional). Beispiel: https://www.example.com:443 ist ein Ursprung.

Wie der Name schon sagt, schränkt die Richtlinie für denselben Ursprung die Ursprünge ein. Daher wird im Artikel hauptsächlich auf diesen Begriff verwiesen. Trotzdem verwenden wir gelegentlich „Domains“ oder „Subdomains“, um die verwendete Technik zu beschreiben, um die verschiedenen „Ursprünge“ zu erstellen.

Der Vorteil mehrerer, ähnlicher PWAs

In einigen Fällen möchten Sie unabhängige Apps erstellen, sie aber trotzdem derselben Organisation oder „Marke“ zuordnen. Die Wiederverwendung desselben Domainnamens ist eine gute Möglichkeit, diese Beziehung herzustellen. Beispiel:

• Eine E-Commerce-Website möchte eine eigenständige Lösung erstellen, mit der Verkäufer ihr Inventar verwalten können, und gleichzeitig dafür sorgen, dass sie wissen, dass es zur Hauptwebsite gehört, auf der Nutzer Produkte kaufen.
• Eine Website mit Sportnachrichten möchte eine spezielle App für ein großes Sportereignis entwickeln, damit Nutzer Statistiken zu ihren Lieblingswettbewerben per Benachrichtigung erhalten. Die App soll als Progressive Web-App installiert werden und Nutzer sollen erkennen, dass sie von der Nachrichtenagentur entwickelt wurde.
• Ein Unternehmen möchte separate Chat-, E-Mail- und Kalender-Apps entwickeln, die als einzelne Apps funktionieren und mit dem Namen des Unternehmens verknüpft sind.

Separate Ursprünge verwenden

In solchen Fällen wird empfohlen, dass jede konzeptionell unterschiedliche App über einen eigenen Ursprung ausgeführt wird.

Wenn Sie in allen Bereichen denselben Domainnamen verwenden möchten, können Sie Subdomains verwenden. Ein Unternehmen, das mehrere Internetanwendungen oder -dienste anbietet, kann beispielsweise eine E-Mail-Anwendung unter https://mail.example.com und eine Kalenderanwendung unter https://calendar.example.com hosten, während der Hauptdienst des Unternehmens unter https://www.example.com angeboten wird. Ein weiteres Beispiel ist eine Sportwebsite, die eine unabhängige App erstellen möchte, die sich ausschließlich auf ein wichtiges Sportereignis wie eine Fußballmeisterschaft in https://footballcup.example.com konzentriert und die Nutzer unabhängig von der Hauptsportwebsite unter https://www.example.com installieren und verwenden können. Dieser Ansatz kann auch für Plattformen nützlich sein, auf denen Kunden unabhängige Apps unter der Marke des Unternehmens erstellen können. Beispiel: Eine App, mit der Händler ihre eigenen PWAs unter https://merchant1.example.com, https://merchant2.example.com usw. erstellen können.

Die Verwendung unterschiedlicher Ursprünge sorgt für die Isolation zwischen den Anwendungen. Das bedeutet, dass jede von ihnen unabhängig verschiedene Browserfunktionen verwalten kann, darunter:

• Installierbarkeit:Jede App hat ihr eigenes Manifest und ihre eigene installierbare Oberfläche.
• Speicher: Jede App hat eigene Caches, lokalen Speicher und praktisch alle Formen von gerätelokalem Speicher, ohne sie für andere freizugeben.
• Dienstworker: Jede App hat einen eigenen Dienstworker für die registrierten Bereiche.
• Berechtigungen: Berechtigungen sind ebenfalls auf Ursprünge beschränkt. So wissen Nutzer genau, für welchen Dienst sie Berechtigungen erteilen, und Funktionen wie Benachrichtigungen werden jeder App korrekt zugeordnet.

Eine solche Isolation ist im Anwendungsfall mehrerer unabhängiger PWAs am wünschenswertesten. Wir empfehlen diesen Ansatz daher dringend.

Wenn Apps auf Subdomains lokale Daten miteinander teilen möchten, können sie dies weiterhin über Cookies tun. Für erweiterte Szenarien kann auch eine Synchronisierung des Speichers über einen Server in Betracht gezogen werden.

Denselben Ursprung verwenden

Der zweite Ansatz besteht darin, die verschiedenen PWAs mit demselben Ursprung zu erstellen. Dies umfasst die folgenden Szenarien:

Nicht überlappende Pfade

Mehrere PWAs oder konzeptionelle „Web-Apps“, die am selben Ursprung gehostet werden und sich nicht überschneidende Pfade haben. Beispiel:

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

Sich überschneidende/verschachtelte Pfade

Mehrere PWAs mit demselben Ursprung, von denen eine in die andere verschachtelt ist:

• https://example.com/ (die „äußere App“)
• https://example.com/app/ (die „innere App“)

Mit der Service Worker API und dem Manifestformat können Sie beides tun, indem Sie die Beschränkung auf Pfadebene verwenden. In beiden Fällen bringt die Verwendung desselben Ursprungs jedoch viele Probleme und Einschränkungen mit sich, deren Grund darauf zurückzuführen ist, dass der Browser diese nicht vollständig als unterschiedliche „Anwendungen“ betrachtet. Daher wird von diesem Ansatz abgeraten.

Im nächsten Abschnitt werden diese Herausforderungen genauer analysiert und es wird beschrieben, was Sie tun können, wenn die Verwendung separater Ursprünge keine Option ist.

Herausforderungen für mehrere PWAs mit demselben Ursprung

Hier sind einige praktische Probleme, die für beide Same-Origin-Ansätze gemeinsam sind:

• Speicher:Cookies, lokaler Speicher und alle Arten von lokalem Speicher auf dem Gerät werden von Apps gemeinsam genutzt. Wenn der Nutzer also beschließt, die lokalen Daten für eine App zu löschen, werden alle Daten an der Quelle gelöscht. Es gibt keine Möglichkeit, dies für eine einzelne App zu tun. Hinweis: Chrome und einige andere Browser werden Nutzer beim Deinstallieren einer App aktiv auffordern, die lokalen Daten zu löschen. Dies wirkt sich auch auf die Daten der anderen Apps an der Quelle aus. Ein weiteres Problem ist, dass Apps auch ihren Speicherplatzquotient teilen müssen. Wenn also eine der Apps zu viel Speicherplatz belegt, wirkt sich das negativ auf die andere aus.
• Berechtigungen:Browserberechtigungen sind an den Ursprung gebunden. Wenn der Nutzer also einer App eine Berechtigung gewährt, gilt diese gleichzeitig für alle Apps dieses Ursprungs. Das mag zwar gut klingen, weil Sie nicht mehrmals um eine Berechtigung bitten müssen, aber denken Sie daran: Wenn der Nutzer die Berechtigung für eine App blockiert, können auch die anderen Apps diese Berechtigung nicht anfordern oder diese Funktion nicht verwenden. Auch wenn Browserberechtigungen nur einmal pro Ursprung gewährt werden müssen, müssen Berechtigungen auf Systemebene dagegen nur einmal pro App gewährt werden, unabhängig davon, ob mehrere Apps auf denselben Ursprung verweisen.
• Nutzereinstellungen: Die Einstellungen werden auch pro Ursprung festgelegt. Wenn beispielsweise zwei Apps unterschiedliche Schriftgrößen haben und der Nutzer den Zoom nur in einer davon anpassen möchte, um dies auszugleichen, ist das nicht möglich, ohne die Einstellung auch auf die anderen Apps anzuwenden.

Aufgrund dieser Herausforderungen ist es schwierig, diesen Ansatz zu fördern. Wenn Sie jedoch keinen separaten Ursprung (z. B. eine Subdomain) verwenden können, wie im Abschnitt Separate Ursprünge verwenden erläutert, wird von den beiden Optionen für denselben Ursprung dringend empfohlen, nicht überlappende Pfade anstelle von überlappenden/verschachtelten Pfaden zu verwenden.

Wie bereits erwähnt, sind die in diesem Abschnitt beschriebenen Herausforderungen für beide Same-Origin-Ansätze gemeinsam. Im nächsten Abschnitt gehen wir genauer darauf ein, warum die Verwendung überlappender/verschachtelter Pfade die am wenigsten empfohlene Strategie ist.

Zusätzliche Herausforderungen bei sich überschneidenden/verschachtelten Pfaden

Ein weiteres Problem bei überlappenden/verschachtelten Pfaden (https://example.com/ ist die äußere App und https://example.com/app/ die innere App) ist, dass alle URLs in der inneren App sowohl als Teil der äußeren als auch der inneren App betrachtet werden.

In der Praxis ergeben sich daraus die folgenden Probleme:

• Installationsförderung:Wenn der Nutzer die innere App aufruft (z. B. in einem Webbrowser), wenn die äußere App bereits auf dem Gerät des Nutzers installiert ist, werden im Browser keine Werbebanner für die Installation angezeigt und das BeforeInstallPrompt-Ereignis wird nicht ausgelöst. Der Grund dafür ist, dass der Browser prüft, ob die aktuelle Seite zu einer bereits installierten App gehört, und zu dem Schluss kommt, dass dies der Fall ist. Sie können das Problem umgehen, indem Sie die innere App manuell installieren (über die Browsermenüoption „Verknüpfung erstellen“) oder die innere App zuerst vor der äußeren App installieren.
• Benachrichtigungen und die Badging API: Wenn die äußere App installiert ist, die innere App aber nicht, werden Benachrichtigungen und Logos von der inneren App fälschlicherweise der äußeren App zugeordnet, da diese der nächste umschließende Bereich einer installierten App ist. Diese Funktion funktioniert richtig, wenn beide Apps auf dem Gerät des Nutzers installiert sind.
• Linkerfassung: Die äußere App kann URLs erfassen, die zur inneren App gehören. Das ist besonders wahrscheinlich, wenn die äußere App installiert ist, die innere App aber nicht. Ebenso werden Links in der äußeren App, die zur inneren App führen, nicht in der inneren App erfasst, da sie als Teil der äußeren App betrachtet werden. Wenn diese Apps unter ChromeOS und Android dem Play Store hinzugefügt werden (als vertrauenswürdige Webaktivitäten), erfasst die äußere App alle Links. Auch wenn die innere App installiert ist, bietet das Betriebssystem dem Nutzer weiterhin die Möglichkeit, sie in der äußeren App zu öffnen.

Fazit

In diesem Artikel haben wir uns verschiedene Möglichkeiten angesehen, wie Entwickler mehrere miteinander verbundene progressive Web-Apps innerhalb derselben Domain erstellen können.

Zusammenfassend empfehlen wir dringend, einen anderen Ursprung zu verwenden (z.B. durch die Verwendung von Subdomains), um unabhängige PWAs zu hosten. Sie im selben Ursprung zu hosten, birgt viele Herausforderungen, vor allem, weil der Browser sie nicht vollständig als unterschiedliche Anwendungen betrachtet.

• Separate Ursprünge: Empfohlen
• Gleicher Ursprung, nicht überlappende Pfade: Nicht empfohlen
• Gleicher Ursprung, sich überschneidende/verschachtelte Pfade: Dringend nicht empfohlen

Wenn es nicht möglich ist, unterschiedliche Ursprünge zu verwenden, sollten Sie nicht überlappende Pfade (z. B. https://example.com/app1/ und https://example.com/app2/) verwenden, anstatt sich auf überlappende oder verschachtelte Pfade wie https://example.com/ (für die äußere App) und https://example.com/app/ (für die innere App) zu verlassen.

Zusätzliche Ressourcen

• Progressive Web-Apps auf Websites mit mehreren Quellen

Vielen Dank für die technischen Rezensionen und Vorschläge: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner und Darwin Huang

Foto von Tim Mossholder bei Unsplash