What Is Service Worker?

What Is Service Worker?

What is a Service Worker? 🤔

Service Worker is just a fancy Web Worker. The difference is, it’s actually placed between your application and the third party services. You can consider it as a kind of middleware function that can parse all requests and do something with data.

Service Workers are a concept a lot more complicated than regular Web Workers. That’s why today we’ll focus just on understanding the base concepts and use cases. In the following posts, we’ll dive deeper into implementation details.

Difference between Service Workers and Web Workers 🧐

The major difference between Service Workers and Web Workers is that Service Workers are persistent. They don’t erase when you close tabs. They’re not even cleared up when you close your browser. When you think about it, it’s a really powerful concept that allows you to use your creativity in a completely different way.

The most important thing you have to remember is that the Service Worker is just a JavaScript application that is running on the browser. This way we have the ability to use some native browser APIs to handle different use cases in our application.

Push Notification 🔥

Thanks to Notification API, Service Worker can send messages from the browser even if the page isn’t opened. It can be super useful when we want to notify the user about some new activities on his profile, new blog posts, or maybe new discounts in our shop.

One thing we have to remember, the user has to grant the application the right to send notifications. It’s really important from the UX point of view, to not throw these request permission alerts directly when a user shows on our page. We should do this more intelligent after the user is engaged in some activities and he understands the benefits from this feature.


Offline App 🤯

Probably the most widely used use case is to create the ability to use your application without an internet connection. That sounds ridiculous (🤯) at first, but when you think about it, it totally makes sense. Using Cache API you can store necessary files from your application, for example, HTML, CSS, and JS.

We can even indicate to the user that he is in the offline mode and provide some user-friendly alerts telling that he can’t use any POST requests.

But what if the user wants to prepare POST request being offline? 🤔

Temporarily storing data 🤓

Imagine the following scenario. After writing a long post you want to publish it to the page. Unfortunately, when we clicked the submit button, it turns out we haven’t had an internet connection 😱

In most cases, you’d seen this cool but also unproductive dinosaur 🦖 mini-game or some other browser indicators when you wanted to get access to the page without the proper internet connection.

Thanks to Service Workers you can avoid this issue. Imagine this scenario in a different way: you click the button and then you see an elegant, clean message that your data has been successfully saved in a browser but, because you don’t have access to the internet right now it can’t be sent. It also informs you that as soon as you reconnect your data will be immediately sent to the server. This way sounds much cooler, right? 😎

Summary 🥺

That’s it for now 🤓. As I mentioned at the beginning, Service Workers are a much more complex concept.

Right now, we’ve just scratched the surface, soon we’ll learn the implementation details and how to turn these brilliant ideas into products 😉. Stay tuned and have a nice day! 🤙