Was sind Service Worker?
Service Worker sind ereignisgesteuerte Programme und fungieren im Wesentlichen als Proxy-Server, die zwischen Webanwendungen, dem Browser und dem Netzwerk (sofern verfügbar) stehen.
Service-Worker – Maximale Usability für WebApps & Web-Anwendungen
Welche Funktion hat ein Service Worker?
Service Worker sollen webbasierten Anwendungen – wie reaktiven WebApps – unter anderem die Erstellung effektiver Offline-Erlebnisse ermöglichen, Netzwerkanfragen abfangen und je nach Verfügbarkeit des Netzwerks entsprechende Maßnahmen ergreifen sowie auf dem Server befindliche Assets aktualisieren. Außerdem ermöglichen sie den Zugriff auf Push-Benachrichtigungen und APIs für die Hintergrundsynchronisation.
Konzepte und Verwendung von Service Workern
Ein Service Worker ist ein ereignisgesteuerter Worker, der für einen Ursprung und einen Pfad registriert ist. Er hat die Form einer JavaScript-Datei, die die Webseite, mit der er verknüpft ist, kontrollieren kann, indem sie Navigations- und Ressourcenanfragen abfängt und modifiziert und Ressourcen in einer sehr granularen Weise zwischenspeichert. Damit stellt ein Service Worker Softwareentwickler*innen ein sehr nützliches Konzept zur Verfügung um diesen die vollständige Kontrolle darüber zu geben, wie sich ihre Anwendung in bestimmten Situationen verhält. Gerade für Situationen in denen das Netzwerk nicht verfügbar ist, bietet dies einen großen Nutzerkomfort und verbessert die Usability einer Webanwendung enorm.
Worker-Kontext und Thread-Modell
Ein Service-Worker wird in einem Worker-Kontext ausgeführt: Der Worker hat also keinen DOM-Zugriff und läuft in einem anderen Thread als das Haupt-JavaScript, das eine Anwendung betreibt, so dass er nicht blockiert.
Asynchrones Service Worker Konzept
Service Worker nutzen eine asynchrone Kommunikation. Sie sind also auf vollständige Asynchronität ausgelegt; daher können APIs wie synchrone XHR und Web Storage nicht innerhalb eines Service Workers verwendet werden.
Service Worker laufen aus Sicherheitsgründen nur über HTTPS. Vor allem HTTP-Verbindungen sind anfällig für die Einschleusung von bösartigem Code durch Man-in-the-Middle-Angriffe, und solche Angriffe könnten noch schlimmer sein, wenn man ihnen Zugang zu diesen leistungsstarken APIs gewährt. In einem Browser wie Firefox sind die Service-Worker-APIs ebenfalls verborgen und können nicht verwendet werden, wenn sich der Benutzer im privaten Browser-Modus befindet.
Registration eines Service Workers
Ein Service Worker wird zunächst mit der Methode
ServiceWorkerContainer.register()
registriert.
Bei Erfolg wird der Service Worker auf den Client heruntergeladen und versucht, die URLs zu installieren/aktivieren, auf die der Client-Benutzer innerhalb des gesamten Ursprungs – hierbei bietet die SameOrigin-Policy dem Benutzer entsprechende IT-Sicherheit – oder innerhalb einer definierten Teilmenge zugreift. Weitere Details findest Du hier.
Service-Worker-Lifecycle: Herunterladen, installieren und aktivieren
Zu diesem Zeitpunkt durchläuft ein Service Worker immer den folgenden Lebenszyklus:
- Herunterladen
- Installieren
- Aktivieren
Der Service Worker wird sofort heruntergeladen, sobald ein Benutzer zum ersten Mal auf eine vom Service Worker kontrollierte Webseite zugreift.
Danach wird er aktualisiert, wenn:
- Eine Navigation zu einer Seite im definierten und somit gültigen Geltungsbereich erfolgt.
- Ein Ereignis für den Service Worker ausgelöst wird und er in den letzten 24 Stunden nicht heruntergeladen wurde.
Die Installation wird versucht, wenn die heruntergeladene Datei als neu erkannt wird. Dabei unterscheidet sie sich entweder von einem vorhandenen Service Worker (byteweise verglichen) oder sie ist der erste Service Worker, der für diese Webseite gefunden wird.
Wird ein Service-Worker zum ersten Mal zur Verfügung gestellt, wird die Installation versucht und nach erfolgreicher Installation wird er aktiviert.
Service-Status im Background: Worker in Wait
Ist bereits ein Service-Worker vorhanden, wird die neue Version im Hintergrund installiert, aber noch nicht aktiviert – in diesem Fall wird sie als Worker in Wait bezeichnet. Er wird erst aktiviert, wenn keine Seiten mehr geladen sind, die noch den alten Service Worker verwenden. Sobald keine Seiten mehr geladen werden, wird der neue Service Worker aktiviert (er wird der aktive Worker).
Die Aktivierung kann mit
ServiceWorkerGlobalScope.skipWaiting()
früher erfolgen und bestehende Seiten können mit
Clients.claim()
vom aktiven Worker beansprucht werden.
So definierst Du das Worker-Verhalten für den Offline-Modus einer Web-Anwendung
Bei der Anwendungsentwicklung kannst entscheiden, wie sich der Worker verhalten soll. Dabei kannst Du zunächst auf das install-Ereignis warten. Es ist gute Programmierpraxis und eine Standardaktion, wenn du deinen Service Worker für die Verwendung vorbereitest, sobald dieses Ereignis ausgelöst wird. Das kannst Du zum Beispiel tun, indem Du einen Cache einer eingebauten Speicher-API erstellst und darin Assets ablegst, die Du für die Offline-Ausführung Deiner Anwendung benötigst.
Aktivierungs-Ereignisse für Worker nutzen
Es gibt auch ein Aktivierungsereignis. Der Zeitpunkt, an dem dieses Ereignis ausgelöst wird, ist im Allgemeinen ein guter Zeitpunkt den Cach zu bereinigen. So kannst Du dafür sorgen, alte Caches und nicht mehr benötigte Daten zu bereinigen, die mit der vorherigen Version deines Service Workers verbunden sind.
Dein Worker kann auf Anfragen mit dem FetchEvent-Ereignis reagieren. Du kannst die Antwort auf diese Anfragen mit der Methode
FetchEvent.respondWith()
beliebig verändern.
Weitere Ideen für Anwendungsfälle
Service-Worker sollen auch für folgende Zwecke eingesetzt werden:
- Datensynchronisation im Hintergrund.
- Beantwortung von Ressourcenanfragen aus anderen Quellen.
- Empfang von zentralisierten Aktualisierungen von teuer zu berechnenden Daten wie Geolocation oder Gyroskop, so dass mehrere Seiten einen Datensatz nutzen können.
- Client-seitige Kompilierung und Verwaltung von Abhängigkeiten von CoffeeScript, Less, CJS/AMD-Modulen usw. für Entwicklungszwecke.
- Hooks für Hintergrunddienste.
- Benutzerdefiniertes Templating basierend auf bestimmten URL-Mustern.
- Leistungsverbesserungen, z. B. das Vorabholen von Ressourcen, die der Benutzer wahrscheinlich in naher Zukunft benötigt, wie z. B. die nächsten Bilder in einem Fotoalbum.
In Zukunft sind in Services eingebettete Worker in der Lage, eine Reihe weiterer nützlicher Dinge für eine Webplattform zu tun. Damit wird die Realisierbarkeit nativer Anwendungen fortlaufend verbessert.
Nutzungsszenarien für Worker
Die Spezifikationen für weitere Nutzungsszenarien von Web-Workern werden fortlaufend erweitert:
- Hintergrundsynchronisation: Starten eines Service Workers auch dann, wenn keine Benutzer auf der Website sind, so dass Caches aktualisiert werden können, usw.
- Reagieren auf Push-Nachrichten: Starten eines Service Workers, um den Benutzern eine Nachricht zu senden, dass neue Inhalte verfügbar sind.
- Reagieren auf eine bestimmte Zeit und ein bestimmtes Datum.
- Betreten eines Geo-Zauns.
Interfaces
Cache
Stellt den Speicher für Request/Response-Objektpaare dar, die als Teil des ServiceWorker-Lebenszyklus zwischengespeichert werden.
CacheStorage
Stellt den Speicher für Cache-Objekte dar. Es bietet ein Hauptverzeichnis aller benannten Caches, auf die ein ServiceWorker zugreifen kann, und verwaltet eine Zuordnung von Stringnamen zu entsprechenden Cache-Objekten.
Client
Stellt den Bereich eines ServiceWorker-Clients dar. Ein ServiceWorker-Client ist entweder ein Dokument in einem Browserkontext oder ein SharedWorker, der von einem aktiven Worker gesteuert wird.
Clients
Stellt einen Container für eine Liste von Client-Objekten dar; die Hauptmethode für den Zugriff auf die aktiven Service-Worker-Clients im aktuellen Ursprung.
ExtendableEvent
Verlängert die Lebensdauer der Installations- und Aktivierungsereignisse, die auf dem ServiceWorkerGlobalScope als Teil des Lebenszyklus des Service Workers ausgelöst werden. Dadurch wird sichergestellt, dass alle funktionalen Ereignisse (wie FetchEvent) nicht an den ServiceWorker weitergeleitet werden, bis dieser die Datenbankschemata aktualisiert und veraltete Cache-Einträge gelöscht hat usw.
ExtendableMessageEvent
Das Ereignisobjekt eines Nachrichtenereignisses, das auf einem ServiceWorker ausgelöst wird (wenn eine Kanalnachricht aus einem anderen Kontext auf dem ServiceWorkerGlobalScope empfangen wird) – verlängert die Lebensdauer solcher Ereignisse.
FetchEvent
Der Parameter, der an den onfetch-Handler übergeben wird, FetchEvent stellt eine Fetch-Aktion dar, die auf dem ServiceWorkerGlobalScope eines ServiceWorkers ausgelöst wird. Er enthält Informationen über die Anfrage und die daraus resultierende Antwort und stellt die Methode FetchEvent.respondWith() zur Verfügung, die es uns ermöglicht, eine beliebige Antwort an die kontrollierte Seite zurückzuschicken.
InstallEvent
Als Parameter, der an den oninstall-Handler übergeben wird, stellt die Schnittstelle InstallEvent eine Installationsaktion dar, die auf dem ServiceWorkerGlobalScope eines ServiceWorkers ausgelöst wird. Als untergeordnetes Element von ExtendableEvent stellt es sicher, dass funktionale Ereignisse wie FetchEvent während der Installation nicht ausgelöst werden.
NavigationPreloadManager
Stellt Methoden für die Verwaltung des Vorladens von Ressourcen mit einem ServiceWorker bereit.
Navigator.serviceWorker
Gibt ein ServiceWorkerContainer-Objekt zurück, das Zugriff auf die Registrierung, Entfernung, Aktualisierung und Kommunikation mit den ServiceWorker-Objekten für das zugehörige Dokument bietet.
NotificationEvent
Der Parameter, der an den onnotificationclick-Handler übergeben wird. Die Schnittstelle NotificationEvent stellt ein Benachrichtigungsklick-Ereignis dar, das auf dem ServiceWorkerGlobalScope eines ServiceWorkers ausgelöst wird.
ServiceWorker
- Experimentell
Stellt einen ServiceWorker dar. Mehrere Browsing-Kontexte (z. B. Seiten, Worker usw.) können mit demselben ServiceWorker-Objekt verknüpft werden.
ServiceWorkerContainer
- Experimentell
Stellt ein Objekt zur Verfügung, das den Service-Worker als Gesamteinheit im Netzwerk-Ökosystem repräsentiert, einschließlich Möglichkeiten zur Registrierung, Deregistrierung und Aktualisierung von Workern sowie zum Zugriff auf den Status von Services und deren Registrierungen.
ServiceWorkerGlobalScope
Repräsentiert den globalen Ausführungskontext eines Service Workers.
MessageEvent
Stellt eine Nachricht dar, die an einen ServiceWorkerGlobalScope gesendet wird.
ServiceWorkerRegistration
- Experimentell
Stellt eine Worker-Registrierung dar.
SyncEvent
- Nicht-Standard
Die Schnittstelle SyncEvent repräsentiert eine Sync-Aktion, diese wird an den ServiceWorkerGlobalScope eines ServiceWorkers gesendet.
SyncManager
- Nicht-Standard
Stellt eine Schnittstelle für die Registrierung und Auflistung von Sync-Registrierungen zur Verfügung.
WindowClient
- Experimentell
Stellt den Bereich eines ServiceWorker-Clients dar, der ein Dokument in einem Browserkontext ist, das von einem aktiven Worker gesteuert wird. Dies ist ein spezieller Typ von Client-Objekt, der über einige zusätzliche Methoden und Eigenschaften verfügt. Übersetzt mit www.DeepL.com/Translator (kostenlose Version)
