Mehrere progressive Web-Apps in derselben Domain erstellen

Mehrere PWAs unter Verwendung desselben Domainnamens erstellen, um Nutzer darauf hinzuweisen, dass sie derselben Organisation oder demselben Dienst angehören

Chase Phillips

Demián Renzulli

Matt Giuca

Im Blogpost zu progressiven Web-Apps in Multi-Ursprungs-Websites sprach Demian über die Herausforderungen, denen Websites aus verschiedenen Ursprüngen gegenüberstehen, wenn sie versuchen, eine einzelne progressive Web-App zu erstellen, die alle diese Websites umfasst.

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

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

Wie im Artikel beschrieben, gelten für die Same-Origin-Policy mehrere Einschränkungen, die die gemeinsame Nutzung von Service Workern, Caches und Berechtigungen für verschiedene Ursprünge verhindern. Aus diesem Grund empfehlen wir dringend, diese Art der Konfiguration zu vermeiden und denjenigen, die bereits Websites auf diese Weise erstellt haben, nach Möglichkeit eine Migration auf eine Website-Architektur mit einem einzigen Ursprungsserver in Betracht zu ziehen.

In diesem Beitrag sehen wir uns das Gegenteil an: Statt einer einzelnen PWA aus verschiedenen Ursprüngen analysieren wir Unternehmen, die mehrere PWAs bereitstellen möchten, die denselben Domainnamen nutzen, und machen den Nutzer darauf aufmerksam, dass diese zur selben Organisation oder demselben Dienst gehören.

Wie Sie vielleicht bemerkt haben, verwenden wir verschiedene, aber miteinander verwandte Begriffe wie Domains und Ursprünge. Sehen wir uns diese Konzepte an, bevor wir fortfahren.

Technische Begriffe

• Domain:Eine Folge von Labels, die im Domain Name System (DNS) definiert sind. Beispiel: com und example.com sind Domains.
• Hostname:Ein DNS-Eintrag, der in mindestens eine IP-Adresse aufgelöst wird. Beispiel: www.example.com wäre ein Hostname, example.com könnte ein Hostname sein, wenn er eine IP-Adresse hätte. com würde dann niemals in eine IP-Adresse aufgelöst werden und kann daher auch nie ein Hostname sein.
• Ursprung:Eine Kombination aus Schema, Hostnamen und (optional) Port. Beispiel: https://www.example.com:443 ist ein Ursprung.

Wie der Name schon sagt, legt die Same-Origin-Policy Einschränkungen für den Ursprung fest, sodass wir uns im gesamten Artikel hauptsächlich auf den Begriff beziehen. Trotzdem verwenden wir von Zeit zu Zeit „Domains“ oder „Subdomains“, um die verwendete Technik zu beschreiben und die verschiedenen „Ursprünge“ zu erstellen.

Mehrere verwandte PWAs

In einigen Fällen kann es sinnvoll sein, unabhängige Anwendungen zu erstellen, aber dennoch als zu derselben Organisation oder „Marke“ gehörend zu identifizieren. Die Wiederverwendung desselben Domainnamens ist eine gute Möglichkeit, diese Beziehung herzustellen. Beispiel:

• Eine E-Commerce-Website möchte eine eigenständige Erfahrung schaffen, damit Verkäufer ihr Inventar verwalten können. Gleichzeitig soll klargestellt werden, dass es zur Hauptwebsite gehört, auf der die Nutzer Produkte kaufen.
• Eine Website für Sportnachrichten möchte eine bestimmte App für ein großes Sportereignis erstellen, damit Nutzer per Benachrichtigung Statistiken zu ihren Lieblingswettbewerben erhalten und sie als progressive Web-App installieren können. Gleichzeitig soll sichergestellt werden, dass die Nutzer sie als App des Nachrichtenunternehmens erkennen.
• Ein Unternehmen möchte separate Chat-, E-Mail- und Kalenderanwendungen erstellen und sie als individuelle Apps ausführen, die an den Namen des Unternehmens gebunden sind.

Separate Ursprünge verwenden

Der empfohlene Ansatz in solchen Fällen besteht darin, dass jede konzeptionell unterscheidbare App aus ihrem eigenen Ursprung existiert.

Wenn Sie in allen Domains denselben Domainnamen verwenden möchten, können Sie dazu Subdomains verwenden. Beispiel: Ein Unternehmen, das mehrere Internetanwendungen oder -dienste anbietet, kann eine E-Mail-Anwendung unter https://mail.example.com und eine Kalenderanwendung unter https://calendar.example.com hosten und den Hauptdienst seines Unternehmens unter https://www.example.com anbieten. Ein weiteres Beispiel ist eine Sportwebsite, die eine unabhängige App erstellen möchte, die vollständig einem wichtigen Sportereignis gewidmet ist, z. B. einer Fußballmeisterschaft bei https://footballcup.example.com. Diese App kann Nutzer unabhängig von der Hauptsportwebsite installieren und verwenden, die unter https://www.example.com gehostet wird. Dieser Ansatz kann auch für Plattformen nützlich sein, auf denen Kunden eigene Apps unter der Marke des Unternehmens erstellen können. Beispiel: Eine App, mit der Händler eigene PWAs unter https://merchant1.example.com, https://merchant2.example.com usw. erstellen können.

Durch die Verwendung unterschiedlicher Ursprünge wird die Isolation der Anwendungen sichergestellt. Das bedeutet, dass jede von ihnen verschiedene Browserfunktionen unabhängig voneinander verwalten kann, darunter:

• Installierbarkeit:Jede App hat ein eigenes Manifest und eine eigene installierbare Erfahrung.
• Speicher:Jede App hat ihre eigenen Caches, lokalen Speicher und im Grunde alle Formen des lokalen Gerätespeichers, ohne dass diese mit anderen geteilt werden.
• Service Worker:Jede Anwendung hat einen eigenen Service Worker für die registrierten Bereiche.
• Berechtigungen:Berechtigungen werden auch durch den Ursprung beschränkt. So wissen Nutzer genau, welchem Dienst sie Berechtigungen erteilen, und Funktionen wie Benachrichtigungen werden den einzelnen Apps korrekt zugeordnet.

Ein solches Maß an Isolation ist bei mehreren unabhängigen PWAs am besten geeignet, daher empfehlen wir diesen Ansatz.

Wenn Anwendungen in Subdomains untereinander lokale Daten freigeben möchten, können sie dies weiterhin über Cookies tun. Für komplexere Szenarien könnte eine Synchronisierung des Speichers über einen Server in Betracht gezogen werden.

Gleichen Ursprung verwenden

Der zweite Ansatz besteht darin, die verschiedenen PWAs aus demselben Ursprung zu erstellen. Dazu gehören die folgenden Szenarien:

Nicht überlappende Pfade

Mehrere PWAs oder konzeptionelle „Web-Apps“, die am selben Ursprung gehostet werden, mit sich nicht überschneidenden Pfaden. Beispiel:

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

Überlappende/verschachtelte Pfade

Mehrere PWAs mit demselben Ursprung, von denen eine in der anderen 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 eine der oben genannten Aktionen ausführen und dabei den Umfang auf Pfadebene festlegen. In beiden Fällen bringt die Verwendung desselben Ursprungs jedoch viele Probleme und Einschränkungen mit sich. Dies liegt daran, dass der Browser diese nicht vollständig als eigenständige „Apps“ betrachtet. Daher wird von diesem Ansatz abgeraten.

Im nächsten Abschnitt analysieren wir diese Herausforderungen genauer und erfahren, was zu tun ist, wenn die Verwendung separater Ursprünge keine Option ist.

Herausforderungen bei mehreren PWAs mit demselben Ursprung

Im Folgenden finden Sie einige praktische Probleme, die bei beiden Ansätzen mit demselben Ursprung auftreten:

• Speicher:Cookies, der lokale Speicher und alle Formen des lokalen Speichers auf dem Gerät werden von Apps gemeinsam genutzt. Wenn sich der Nutzer dazu entscheidet, lokale Daten für eine App zu löschen, werden alle Daten des Ursprungs gelöscht. Dies kann nicht für eine einzelne App durchgeführt werden. Dies kann bei Chrome und einigen anderen Browsern beim Deinstallieren einer App aktiv zum Löschen lokaler Daten aufgefordert werden. Dies wirkt sich auch auf die Daten der anderen Apps am Ursprung aus. Ein weiteres Problem ist, dass Anwendungen auch ihr Speicherkontingent teilen müssen. Wenn also eine von ihnen zu viel Speicherplatz belegt, wirkt sich dies negativ auf die andere aus.
• Berechtigungen:Berechtigungen sind an den Ursprung gebunden. Wenn der Nutzer also einer App eine Berechtigung erteilt, gilt diese gleichzeitig für alle Apps dieses Ursprungs. Das mag nach einer guten Sache klingen (d. h., Sie müssen nicht mehrmals um eine Berechtigung bitten.), aber denken Sie daran: Wenn der Nutzer die Berechtigung für eine App blockiert, werden die anderen daran gehindert, diese Berechtigung anzufordern oder diese Funktion zu verwenden.
• Nutzereinstellungen: Die Einstellungen werden auch pro Ursprung festgelegt. Wenn beispielsweise zwei Apps unterschiedliche Schriftgrößen haben und der Nutzer nur bei einer App heranzoomen möchte, um dies zu kompensieren, muss die Einstellung auch auf die anderen Apps angewendet werden.

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 beschrieben, wird von den beiden vorgestellten Optionen desselben Ursprungs die Verwendung von sich nicht überlappenden Pfaden als überlappende/verschachtelte Pfade dringend empfohlen.

Wie bereits erwähnt, sind die in diesem Abschnitt beschriebenen Herausforderungen bei beiden Ansätzen mit demselben Ursprung gleich. Im nächsten Abschnitt gehen wir näher 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 der Herangehensweise an überlappende/verschachtelte Pfade (wobei https://example.com/ die äußere Anwendung und https://example.com/app/ die innere Anwendung ist) besteht darin, dass alle URLs in der inneren Anwendung als Teil der äußeren und der inneren Anwendung betrachtet werden.

In der Praxis bringt dies folgende Probleme mit sich:

• Installation:Wenn der Nutzer die innere App aufruft (z. B. in einem Webbrowser) und die äußere App bereits auf dem Gerät des Nutzers installiert ist, zeigt der Browser keine Werbebanner zur Installation an 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 Anwendung gehört, und schlussfolgert, dass dies der Fall ist. Die Problemumgehung besteht darin, die innere App manuell zu installieren (über die Browsermenüoption "Verknüpfung erstellen") oder die innere App zuerst und vor der äußeren App zu installieren.
• Benachrichtigung und Badging API: Wenn die äußere App installiert ist, die innere App jedoch nicht, werden Benachrichtigungen und Badges, die von der inneren App stammen, fälschlicherweise der äußeren App zugeordnet, also dem nächstgelegenen einschließenden Bereich einer installierten App. Diese Funktion funktioniert ordnungsgemäß, wenn beide Apps auf dem Gerät des Nutzers installiert sind.
• Linkerfassung: Die äußere App erfasst möglicherweise URLs, die zur inneren App gehören. Das ist besonders wahrscheinlich, wenn die äußere App installiert ist, die innere jedoch nicht. Ebenso werden Links innerhalb der äußeren Anwendung, die mit der inneren Anwendung verknüpft sind, nicht mit der Erfassung mit der inneren Anwendung verknüpft, da sie als im Bereich der äußeren Anwendung gelten. 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. Selbst wenn die innere Anwendung installiert ist, bietet das Betriebssystem dem Nutzer die Möglichkeit, sie in der äußeren Anwendung zu öffnen.

Fazit

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

Zusammenfassend lässt sich sagen, dass wir dringend empfehlen, einen anderen Ursprung zu verwenden (z.B. durch die Verwendung von Subdomains), um unabhängige PWAs zu hosten. Wenn sie im selben Ursprung gehostet werden, stellt dies eine Reihe von Herausforderungen dar, vor allem deshalb, weil der Browser sie nicht vollständig als unterschiedliche Anwendungen betrachtet.

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

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

Weitere Ressourcen

• Progressive Web-Apps auf Multi-Ursprungs-Websites

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

Foto von Tim Mossholder auf Unsplash