Service Workers are becoming one of the most effective ways to progressively enhance web applications. Its main purpose is to enable offline experiences, allowing to provide web notifications and running background tasks even if the web page is not active. In this brief article we comment how we applied it to implement and manage resource caching in a transparent way for an existing web application.
First, let's start with the origin of the core technology that we are using in this post: Service Workers. Their development was possible thanks to the Web Workers, which are analog to jobs or background tasks in backend or mobile apps respectively. Just by creating a Worker object and providing it with javascript file, we can run code in a different environment, asynchronously from the task that is doing the user.
Service Workers are a special kind of Workers that can enhance web applications, making them run faster and be more engaging. As we commented before, in this case we will be focusing on asset and request caching as a part of a requirement for one of our applications. First of all, in order to use service workers we need to create our service worker file. This file should be served from the same domain as our webpage and from the root path to provide a wider scope. The first thing we have to do is to check if the service worker API is available and proceed to register it.
Having our Service Worker already set up, we start implementing the caching piece. In this case, all the caching will occur in our Service Worker file, being this process completely independent from the web page. The most basic Service Worker consists of listening on the two main lifecycle events of it, install and activate.
The install event occurs only once per Service Worker and, if it has happened already, it won’t be triggered in the next page load. Every time we change the code in the Service Worker, the browser is going to detect as a new one and install it again. This is a good place to cache our assets.
In a Service Worker environment, as well in the browser the, caches object provides a mechanism for caching Request and Response objects. Here we will open the current cache and add all the files we want to cache. To do so, we will create a key representing the request and with the value of the response. In the activate event, in this case we make sure that cleaning all other caches and leaving the one that is of our interest.
Once the Service Worker is active, we can start listening to thefetch event and snoop all requests that go through our domain, and then we can choose to continue with the request or respond with things that are in our cache. After this, the webpage will work offline without any further effort or invasive code to be added.
Service Workers are quite powerful, from here it is possible to start creating more complex things like using a stale-while-revalidate approach where we serve things from cache first, and update everything as soon as we get a response from our servers. This is an approach we used at caches in several layers of our apps, even in our backend, and having it in a web fronted is now doable in a transparent way using Service Workers too.
Finally, there is a tool from Google that can help creating powerful service workers, it is called Workbox, more information at https://developers.google.com/web/tools/workbox.
If you are interested in this topic, here is more articles that you may want to look at:
