© Studio_G/Shutterstock.com
Teil 1: Service Worker: der Turbo für die eigene Webanwendung

Offline, was nun?


Wer kennt ihn nicht, den kleinen Dinosaurier, der erscheint, wenn eine Webseite nicht erreichbar ist. Er soll einem die Zeit vertreiben, bis die Verbindung zum Netzwerk wiederhergestellt werden kann. Doch ist dies heute wirklich noch nötig? Die Antwort auf diese Frage ist ein klares Nein. In diesem ersten Teil der Miniserie zur Offlinefähigkeit von Webanwendungen werden wir sehen, wie man mittels des Service Workers Anfragen an das Netzwerk cachen und somit seine Anwendung offline halten kann.

Seit geraumer Zeit steht mit dem Service Worker ein API [1] zur Verfügung, das die Möglichkeit bietet, seine Webanwendung durch Cachen von Netzwerkanfragen und deren Antworten offline verfügbar zu machen. Die Anforderung nach Offlinefähigkeit ist jedoch nicht neu, erlebt aber durch das Interesse an Progressive Web Apps (siehe Artikel im PHP Magazin 4.17) derzeit einen Aufschwung.

Der Service Worker ist eine JavaScript-Anwendung, die im Hintergrund parallel zur eigentlichen Webanwendung läuft. Hierfür bedient sie sich eines eigenen Threads, um bei aufwendigen Operationen die Hauptanwendung nicht zu blockieren. Der Code des Service Workers liegt in einer bzw. mehreren eigenen Dateien. Damit der Service Worker arbeiten kann, muss er installiert werden. Hierfür ist notwendig, dass die Anwendung über HTTPS erreichbar ist. Einzige Ausnahme ist hier die Entwicklung unter localhost. Um einen Service Worker zu installieren, muss in der Webanwendung die JavaScript-Datei des Service Workers registriert werden:

window.navigator.serviceWorker.register('serviceWorker.js');

Durch den Aufruf von register() wird dem Browser mitgeteilt, dass unter dem angegebenen URL ein Service Worker zur Verfügung steht. Der Service Worker selbst arbeitet eventbasiert. Das bedeutet, dass man sich innerhalb dieses Service Workers auf verschiedene Events registriert und auf diese reagiert.

Circle of Life

Jeder Service Worker durchläuft ab der Installation einen Lebenszyklus, der verschiedene Zustände bereithält (Abb. 1):

  • Parsed: Die JavaScript-Dateien des Service Workers wurden geparst und sind fehlerfrei.
  • Installing: Der Service Worker wird gerade installiert.
  • Error: Dieser Zustand tritt auf, wenn der Service Worker nicht installiert werden kann, oder wenn während der Installation ein Fehler auftritt.
  • Activated: Die Installation des Service Workers ist abgeschlossen.
  • Idle: Keines der registrierten Events wird aufgerufen und der Service Worker wartet auf neue Events.
  • Fetch: Der Service Worker agiert als Proxy zwischen Anwendung und Netzwerk und überwacht Anfragen an das Netzwerk.
  • Terminated: Der Service Worker wird nicht weiter benötigt und wurde beendet.
image

Abb. 1: Service-Worker-Lebenszyklus

Der Service Worker kann sich auch auf die Events seines eigenen Lebenszyklus – beispielsweise install oder activate – registrieren. Das ist z. B. dann notwendig, wenn bei der Installation des Service Workers Dateien im Cache abgelegt werden sollen. Hierzu aber später mehr.

Caching mit dem Service Worker

Um Netzwerkanfragen mit dem Service Worker zu cachen, werden zwei APIs miteinander kombiniert:

  • Fetch-API [2]: Promise-basiertes API, das es dem Service Worker erlaubt, als Proxy zwischen Anwendung und Netzwerk zu agieren und die Anfragen und Antworten an das Netzwerk zu überwachen und zu manipulieren.
  • Cache-API [3]: API, um Netzwerkanfragen und deren Antworten zu cachen.

Registriert sich der Service Worker auf das fetch-Event, agiert er als Proxy zwischen Webanwendung und Netzwerk und überwacht jede Anfrage, die an das Netzwerk gestellt wird (Abb. 2).

image

Abb. 2: Service Worker als Proxy

Um sich auf ein Event zu registrieren, ruft man die Methode addEventListener() auf dem Objekt self innerhalb der Service-Worker-Datei auf. Ein Callback definiert, was beim Auslösen des Events geschehen soll:

self.addEventListener('fetch', event => {
console.log('Fetched request: ', event.request.url);
event.respondWith(self.fetc...

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