Separating web apps — Service Workers
So as a bit of a followup to my PWA article I wrote a while back, I thought I’d do a bit of a write-up on the main part that separates a regular web page from a progressive web app — service workers.
A service worker essentially is a proxy between the network and your web page. What do you do with this? Lots of things. The obvious is just caching assets for offline access. But we can go way beyond that. We could have a default image for if one isn’t found on the server (rather than just the normal broken image icon), we can replace images on the fly depending on the browser (eg. using WebP when supported, and falling back to PNG when not).
Service Workers also support push notifications. Traditionally one of the main reasons to go to a native or hybrid app over a web page.
So what are the limitations?
- Service workers only support async style calls (think Promises) rather than synchronous ones (like XHR and LocalStorage).
- The service worker is only initially downloaded after the first page is loaded, so if you’re intercepting calls, you will miss the first ones.
So some other things to consider are that the service worker will be downloaded every 24 hours, or sooner depending on situations. Service workers only work on https connections or via localhost (which is great for development)
Enough writing, let’s get into some examples.
When we initially load your app, we need to make a basic call to register the service worker.
So what are we doing here? For starters we make sure that service workers are available. After that, we’re calling register, which as parameters takes a filename, and options. In this case, we’re only specifying the scope to be at the root level. So what this lets us do is have multiple service workers on a site depending on your path.
Ok, now let’s get into the meat of this. We’ll start with a very basic example of pre-caching your assets.
A little more complex here, but easily explained. We’re handling two events. “install” and “fetch”.
Install occurs when the service worker is downloaded from the server and installed into the browser. This is called every time the service worker is updated (ie. every 24 hours or sooner).
In the install handler, we define a local onInstall async method, open a named cache (or create if it doesn’t exist) and add an array of filenames to grab from the server. This is the main part of your pre-caching.
The fetch handler is just as simple. Fetch occurs whenever a call to the server is made. This is your main proxy function.
Let’s have a bit of fun now.
So any time we request Cat.jpg, we’re returning Dog.jpg (because Dogs are clearly better than Cats) which we have already pre-cached.
The downside to doing this in the service worker is that the first time you load the page, it will download Cat.jpg as the service worker won’t have been installed yet.
Ok, something more practical, how about displaying your own custom image missing logo for any broken images?
Quite a bit more to this one, but very similar to the previous example.
We define our fallback image, in this case we embed an SVG into our service worker.
Our install function is still exactly the same, and the cache here could be removed if we want.
Next we have modified our fetch function. We look at the network first, so we have the most up to date info, then the cache if it isn’t found on the network (we may be offline), then failing that, we throw an error and return our embedded SVG.
This only scratches the surface of what we can do with service workers, there’s lots of resources online to go further with this, one of my favourites being https://serviceworke.rs which has some nice pre-written recipes to use.
If you would like to learn more come and have a chat with the Momenton crew.