What's a service worker?

The architecture of a traditional web application has two distinct layers: the server side, and the client side. Essentially the client fetches data and business logic from the server via requests. This has been the standard for years, and you could illustrate it like this:

The service worker, is the third layer. A service worker is a type of web worker, which controls and manipulates all the data that’s sent between the client and server. So now you have the same relationship between server and client as before, but with the service worker sitting in the middle of it:

What's a web worker?

A web worker is a script that runs on the background of the device of the user. Because they run in the background they don’t hurt the client side performance of your application. A web worker does not have access to the DOM, so it can not change the appearance of a web-application.

This might seem more complicated than what you’re used to, but hear me out, this setup can be pretty powerful. For example, the service worker embedded into a PWA is what enables the application to function offline. Think of it as a virtual proxy of sorts. If you want to know more about PWAs in general, check out this other article I wrote.

‍

What makes service workers so powerful?

Data caching

When the client requests data, the service worker can determine where he'll be getting the data from. On a traditional website, the data will always be fetched from the server. But the service worker can actually store the responses from the server. If the same data is requested a second time, the service worker can return the data it has stored.

A powerful caching strategy that’s often used is the “stale-while-revalidate” strategy. If the data is cached, it will return the cached data. But it won’t stop there. It will execute the request to the server and update the cache. This strategy has the advantage of having a fast response time and responses that are up-to-date.

Caching makes the application faster and less dependent on the network connection. According to research conducted by Google, 53% of users leave a website if it is not loaded within 3 seconds. Service workers can, therefore, help to increase the number of users on your website. (Google & Awwwards, Brainfood-mobile-performance). The two mechanisms used to make data available offline are indexedDB and the cache API. (Osmani & Cohen, Storage for the web) (MDN, Using Service Workers)

‍

Offline functionality

When a PWA is loaded for the first time on a device, pages a user has visited while connected to the internet, will remain available even if the user goes offline. This is done by locally saving the HTML, CSS, and JavaScript files needed to create those pages. Applications that don’t use network requests to load data will therefore remain fully functional offline.

‍

Push notifications

Broadly speaking, there are two types of notifications: local notifications and push notifications. Local notifications are activated from the user’s application, there are no external triggers to activate this notification.

Within local notifications, we can still distinguish between persistent and non-persistent notifications. Non-persistent notifications are notifications that can only be displayed when the application is active. This type of notification does not require a service worker. Persistent notifications are notifications that are still activated from the code on the device, but the application no longer needs to be active. A service worker is required.

An example of these persistent notifications is you clock app, it’s triggered because something on your own device triggered the notification. Push notifications are not activated within the application but are activated by a server. To use push notifications, two web APIs must be used: the notifications API and the Push API.

A classic example of push notifications is when you receive a message on a social media platform. This notification is triggered because something happened on the server. It's the Push API that's used by the service worker. If the server sends a notification, it’s received by the Push API. This API will then use the notifications API to display a notification on the user’s device. If you're wondering which browsers support the Push API, look here:

Unfortunately there's still no support for Safari and its iOS counterpart. Apple tries to keep native mobile features locked away so that only iOS apps can easily leverage them. That's business, baby.

‍

Background synchronization

A PWA can use the background sync API to enable background synchronization. Background synchronization can be applied when there is a slow or no network connection. It is the process where a network request, executed when there was no or too weak internet connection, is stored in the service worker and is executed when there is a stable internet connection.

A type of application that can make use of these are chat platforms. If the message is sent while the user is offline, no error will be displayed but this message will be sent the moment there is an internet connection. Even if the user closed the app on his device. While really powerful, there's even less support for this type of functionality across browsers.

As you can tell, support is mostly limited to browsers based on a Chromium. Because of this, background synchronization is a perfect example of progressive enhancement.

‍

Conclusion

At first sight, service workers add an extra layer of complexity to your application. However it does add a lot of value to your web-based application:

• 👉 Engagement can be improved using push notifications.
  
• 👉 Retention and responsiveness can be improved using caching
  
• 👉 User experience can be improved by using background synchronization.
  
• 👉 Web applications can be uniquely used offline.