© DrHitch/Shutterstock.com
Progressive Web-Apps

1 Progressive Web-Apps mit Angular 2 und Service Worker


Progressive Web-Apps bieten den Komfort nativer Anwendungen, indem sie auf moderne Browser-APIs wie Service Worker setzen. Sie sind installierbar sowie offlinefähig und nutzen Hintergrundprozesse für Datensynchronisation und Push Notifications. Falls der Browser der Wahl die genutzten APIs noch nicht unterstützt, stellen sie zumindest den Kern ihrer Funktionalität zur Verfügung.

Die Möglichkeiten moderner Browseranwendungen sind geradezu verlockend: Sie sind plattformunabhängig, bieten eine stressfreie Bereitstellung und auch in puncto Benutzerfreundlichkeit lassen sie dank reichhaltiger JavaScript-Komponenten sowie Responsive Design keine Wünsche offen. Ein kurzer Blick auf Produkte wie Office 365 beweist: Im Browser ist mittlerweile so gut wie alles möglich.

Allerdings gibt es auch Bereiche, bei denen Webanwendungen nicht mit ihren nativen Gegenstücken mithalten können: Ladezeit, Offlinefähigkeit, Push Notifications und Datensynchronisation im Hintergrund sind ein paar Beispiele dafür. Lösungen hierfür versprechen progressive Web-Apps, die die nächste Stufe moderner Webanwendungen darstellen. Dieses Kapitel geht darauf ein und zeigt anhand eines Beispiels, wie sie zu offlinefähigen Browseranwendungen beitragen.

Bei diesem Beispiel geht es um eine Web-App, die gebuchte Flüge präsentiert (Abb. 1.1). Der Quellcode dieses Beispiels steht in zwei Varianten unter [1] sowie [2] zur Verfügung.

image

Abbildung 1.1: Beispielanwendung für eine progressive Web-App

Progressive Web-Apps

Das Schlagwort progressive Web-Apps steht für moderne Webanwendungen, die prinzipiell in jedem gängigen Browser laufen und beim Betrieb in moderneren Modellen zusätzlichen Komfort bieten. Sie sind beispielsweise responsive, fühlen sich wie Apps an und stehen auf Wunsch über ein Icon am Startbildschirm zur Verfügung. Auf diese Weise gestartete Apps können sogar die Adresszeile des Browsers ausblenden, sodass der Benutzer auf den ersten Blick keinen Unterschied zu einer nativen App bemerkt. Das Verhalten dieser „installierten“ Weblösungen steuert ein so genanntes Web-App-Manifest. Browser, die dieses Konzept noch nicht unterstützen, nehmen Einstellungen dieser Art in der Regel über Metatags entgegen.

Sofern im Browser der Wahl vorhanden, setzen progressive Web-Apps auf Service Worker. Dabei handelt es sich um Hintergrundprozesse, die losgelöst von der eigentlichen App ablaufen, und Offlineszenarien, Datensynchronisation sowie Push Notifications unterstützen. Als der vorliegende Text verfasst wurde, unterstützten Chrome, Firefox und Opera dieses aufstrebende Konzept. Seitens der Teams hinter Safari und Edge gab es Interessensbekundungen.

Zur Unterstützung der Offlinefähigkeit und zur Beschleunigung des Anwendungsstarts nutzen progressive Web-Apps das Muster App Shell. Es hält die unmittelbar nach dem Start benötigten Anwendungsteile im Cache vor. Das bezieht sich sowohl auf den Rahmen der Anwendung als auch auf ausgewählte Daten. Auf diese Weise kann die Anwendung dem Nutzer recht schnell zur Verfügung stehen. Weitere Daten und Seiten kann die Shell bei Bedarf nachladen.

Offline mit Service Worker

Schon seit längerer Zeit unterstützen alle gängigen Browser Offlineszenarien. Beispielsweise können Webanwendungen über ein so genanntes Cachemanifest alle für den Offlinebetrieb benötigten Dateien angeben. Der Browser lädt diese beim ersten Besuch der Anwendung herunter und hinterlegt sie im so genannten App-Cache.

Leider hat die Anwendung selbst nur wenig Kontrolle über die Nutzung des Caches. Beispielsweise lädt der Browser Dateien bevorzugt aus diesem Cache, auch wenn online neuere Versionen davon zur Verfügung stehen. Daneben aktualisiert er den App-Cache nur, wenn er eine Änderung am Cachemanifest entdeckt. Ein gezieltes Aktualisieren einzelner Cacheeinträge ist hingegen nicht möglich.

Service Worker bieten hierfür eine bessere Lösung: Sie haben feingranularen Zugriff auf mehrere frei definierbare Cacheregionen und können Dateien nach eigenem Gutdünken darin verwalten. Darüber hinaus können sie HTTP-Anfragen abfangen und dynamisch entscheiden, ob sie über einen Netzwerkzugriff oder aus dem Cache zu beantworten sind. Das unterstützt Nutzer nicht nur bei der Implementierung von App Shells, sondern macht den situativen Einsatz verschiedener Caching-Strategien möglich. Das von Google bereitgestellte Offline Cookbook [3] listet einige solche Strategien auf. Tabelle 1.1 fasst eine Auswahl davon zusammen.

Strategie

Beschreibung

Cache-only

Ressourcen werden ausschließlich aus dem Cache geladen.

Network-only

Ressourcen werden ausschließlich über das Netzwerk geladen.

Cache, falling back to Network

Cache wird bevorzugt. Falls die gewünschte Ressource dort nicht zu finden ist, wird über das Netzwerk geladen.

Cache and Network Race

Ressource wird parallel aus dem Cache und übers Netzwerk angefordert. Die zuerst erhaltene Antwort kommt zum Einsatz.

Network falling back to Cache

Netzwerk wird bevorzugt. Falls die gewünschte Ressource nicht übers Netzwerk geladen werden kann, kommt der Cache zum Einsatz.

Cache then Network

Ressource wird aus dem Cache geladen und verwendet. Parallel dazu wird eine Netzwerkanfrage gestartet. Sobald die darauffolgende Antwort vorliegt, kommt diese zum Einsatz. Darüber hinaus wird damit der Cache aktualisiert.

Generic Fallback

Wenn die gewünschte Ressource nicht im Cache und/oder nicht übers Netzwerk gefunden wurde, kommt eine generische Antwort zum Einsatz. Dabei kann es sich um eine benutzerfreundliche Fehlermeldung handeln.

Tabelle 1.1: Ausgewählte Caching-Szenarien

Da Angreifer das Abfangen von HTTP-Anfragen für ihre Zwecke nutzen können, aktivieren Browser Service Worker nur bei Nutzung von HTTPS. Eine Ausnahme machen sie in der Regel beim Einsatz von http://localhost:xy, zumal es sich hierbei häufig um einen Testbetrieb im Rahmen der Entwicklung handelt.

Service Worker

Ein Service Worker ist zunächst lediglich ein Skript, das der Browser im Hintergrund ausführt und das sich für bestimmte Events registriert. Sein Wirkungsbereich erstreckt sich über den Ordner, in dem sich die Skriptdatei befindet, und bezieht auch sämtliche ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang