Module 4: Geavanceerde webtechnologieën

4.2.3 Inleiding over service workers

Progressive Web Apps moeten snel en installeerbaar zijn. Dit betekent dat ze online, offline en via een instabiele, trage verbinding werken. Om een app-shell op elk moment snel en probleemloos beschikbaar te maken, moeten we hem in het cachegeheugen opslaan met behulp van een service worker

Wat is een service worker?

Een service worker is een script dat uw browser op de achtergrond uitvoert, los van webpagina's. Zo kunt u elementen integreren die geen webpagina of gebruikersinteracties nodig hebben. Momenteel zijn op deze manier al elementen zoals pushmeldingen en achtergrondsynchronisatie mogelijk. In de toekomst zullen service workers ook andere mogelijkheden ondersteunen, zoals periodieke synchronisatie en geo-fencing. De kernfunctie die we in deze training bespreken, is de mogelijkheid om netwerkverzoeken te onderscheppen en te behandelen, bijvoorbeeld om antwoorden in een cache programmatisch te beheren.

Wat maakt deze API zo interessant? Doordat hij offline kan werken, geeft u ontwikkelaars de volledige controle over de ervaring.

Voordat er service workers waren, was er een andere API waarmee gebruikers offline op het internet konden werken: AppCache. De grote struikelblokken van AppCache zijn het aantal onbekende factoren en het feit dat het uitstekend werkt voor single page-webapps, maar minder goed voor websites met meerdere pagina's. Met service workers kunt u deze bekende pijnpunten vermijden.

Wat moet u weten over service workers?

  • Het is JavaScript Worker die dus geen rechtstreekse toegang tot het DOM heeft. In plaats daarvan kan een service worker communiceren met de pagina's die hij controleert door berichten die verstuurd werden via de postMessage-interface, te beantwoorden. Indien nodig kunnen die pagina's het DOM manipuleren.
  • Een service worker is een programmeerbare netwerkproxy waarmee u kunt controleren hoe de netwerkverzoeken van uw pagina worden afgehandeld.
  • Hij stopt wanneer hij niet wordt gebruikt en hij start opnieuw wanneer hij weer nodig is. U kunt dus niet vertrouwen op de algemene status van de onfetch en onmessage handlers in de service worker. Als u informatie moet bijhouden om op latere tijdstippen opnieuw te gebruiken, hebben service workers wel toegang tot de IndexedDB API.
  • Service workers maken veel gebruik van promises. Bent u hier nog niet zo bekend mee? Lees dan eerst het Engelstalige artikel Promises, an introduction (Een inleiding tot promises).

De levenscyclus van een service worker

De levenscyclus van service workers staat volledig los van uw webpagina.

Om een service worker te installeren op uw website, moet u hem registreren in het JavaScript van uw webpagina. Als u een service worker registreert, zal de browser de installatie van de service worker op de achtergrond starten.

Tijdens de installatiestap worden de statische items meestal in het cachegeheugen opgeslagen. Als alle bestanden succesvol in het cachegeheugen zijn opgeslagen, is de service worker volledig geïnstalleerd. Als u een of meerdere bestanden niet kunt downloaden en in het cachegeheugen kunt opslaan, mislukt ook de installatiestap en wordt de service worker niet geactiveerd (en dus niet geïnstalleerd). Is dit bij u gebeurd? Maak u geen zorgen: volgende keer probeert het systeem het opnieuw. Als het wel lukt, weet u dus dat uw statische items in het cachegeheugen opgeslagen zijn.

Na de installatie volgt de activatiestap. Dit is uw kans om het beheer van oude caches af te handelen; hierover zullen we het hebben in het gedeelte over service worker-updates.

Na de activatiestap controleert de service worker alle pagina's in zijn bereik. Alleen de pagina waarmee de service worker voor het eerst werd geregistreerd, wordt nog niet gecontroleerd; dit gebeurt pas wanneer hij opnieuw wordt geladen. Zodra een service worker de controle heeft, bevindt hij zich steeds in een van twee staten: ofwel staat hij uit om geheugen te sparen, ofwel behandelt hij fetch- en message-gebeurtenissen die voorkomen wanneer er een netwerkaanvraag of message wordt aangemaakt op uw pagina.

Hieronder ziet u een vereenvoudigde versie van de levenscyclus van een service worker bij zijn eerste installatie.

Moeten we door service workers de structuur van onze apps opnieuw uitvinden?

Voor service workers zijn er een paar kleine aanpassingen in de app-architectuur nodig. In plaats van alles in een HTML-string te duwen, is het misschien beter om AJAX te gebruiken. In dit geval hebt u een shell (die altijd in de cache opgeslagen is en steeds zonder netwerk kan starten) en content die regelmatig wordt vernieuwd en apart wordt beheerd.

De gevolgen van deze splitsing zijn niet mis. Bij het eerste bezoek kunt u content op de server weergeven en de service worker op de client installeren. Bij de volgende bezoeken moet u enkel nog gegevens opvragen.

Was dit nuttig?
Hoe kunnen we dit verbeteren?