This week’s article will be a bit different from the usual, more technical articles: I want to talk about service workers, how we added them to our products, and why you should be adding some to your projects as well.

Just what are service workers?

Service workers are a relatively new API available to web developers. The main characteristic of a service worker is that it installs itself in the browser where it is accessed, and acts like a program on its own. This brings a lot of interesting functionalities.

For instance, you can use it as a proxy for your HTTP requests, where you can decide to cache the data one way and another, to automatically serve data from the cache if it is available and recent enough.

Since they run in a different thread, service workers are also ideal to do heavy data processing without affecting the fluidity of your user experience, or to try and fetch data that you know will be asked for a lot of times.

And some other new APIs actually require the usage of a service worker to have access to them, such as the Push API, which allow your web application to receive push notifications, even when your application is not opened.

Service workers are an integral part of the Progressive Web App, the application design principles that raise your web application to a status near of that of native mobile apps. Even if progressive web apps are more a concern for the mobile platform, desktop can still benefit from installing a service worker that can send notifications to your users, or do some kind of caching to achive better felt performances.

Angular 5 supports service workers

Angular introduced an easy way to add service workers to applications with its version 5, about six months ago. Since then, we were quite interested in adding a service worker to our products, but we had more pressing issues, such as the big migration I referenced previously.

Two weeks ago, however, we wanted to add a new feature to our application where we wanted the application to stay usable even if there was no internet connection. We wanted to provide a nice experience to our users that would try to submit data during such internet outage, and we thought that adding a service worker to was the best way to achieve that goal.

And we did! The way Angular provided service workers was to add a new package, and a configuration file instead of actual service worker code. This means that adding a service worker to your application is almost just a two-step process!

In our case, we configured our service worker to cache everything from our API, but always serve data fresh. This way, if the users lose their connection, they can return back to previously visited pages seemlessly. We will eventually add some endpoints to the list of data that can be served from cache, eventually, but we wanted to quickly be able to preserve the actual behavior of our application while still having this offline feature.

Because our use case was simple, the service worker needed almost no configuration: in twelve lines of JSON, we were able to tell it to start serving our API data from its cache when the network is off or when a certain timeout is reached.

Actually, the hardest part in it all was regarding our backend configuration, to make sure we had proper rewrite rules to be able to serve the service worker itself, its manifest and the files it referenced, and that was not particularly hard, so it tells how easy it was to configure the service worker for our app.

Why you should start using service workers too

With that said, I think you can now see that it is not that hard to integrate a service worker to your application, and that it can provide really nice features. If you have a large portion of users that use your web app on mobile phones, adding a service worker can help you climb your way up to the progressive web app status, letting users interact with your application almost like if it was a native application.

You can provide your users with a richer experience, sending them push notifications.

Your application can be partially accessible offline, allowing your users to stay on your application, even when they are in the subway or just lost their connection.

And you can start doing more heavy work in your frontend code without sacrificing a fluid UI, if you make the kind of application that needs to do this kind of data processing.

I am confident even more features and API will be added in the future, so integrating a service worker now also means your application will be ready for tomorrow.

These are many reasons why you should, like us, integrate a service worker to your applications.

That’s all for this week! Thanks for coming by!