When we think of a website, (by "we" I mean web developers or just developers in general, so sorry if I offend you by not including in this category haha) we tend to think of plain dynamic web pages where they may have immense intricate features but their only purpose networking wise is to send an HTTP(s) request to the server, download the necessary files, and execute them. For older generations, this statement would have been true and we could have stopped right there. However, modern websites and browsers have a very exciting feature or service (foreshadow) which allows you to do more than that. It is this very feature or service that is responsible for managing push notifications, background sync, caching, and a fruitful offline experience - service worker.
When I first came across the concept of a service worker, I was SO confused. I was setting up a react application using npx create-react-app
, and in the boilerplate of the application, there was a service-worker.js file and some few lines of code installing the service worker in index.js. Naturally, this prompted me to completely abandon my project (don't worry I got back to it later haha) and spend all my time learning about service workers. What my point is that if you are confused, like REALLY confused, do not be afraid because I was where you are right now, so trust me when I say that even though it seems overwhelming at first, it really is not that difficult and you will be relieved with tears of joy knowing how easy it is. You got this!
~ Some motivational words from yours truly because why not
A service worker is a script that your browser runs in the background, separate from a web page, opening the door to features that don't need a web page or user interaction. Today, they already include features like push notifications and background sync. In the future, service workers might support other things like periodic sync or geofencing. The core feature discussed in this tutorial is the ability to intercept and handle network requests, including programmatically managing a cache of responses. (Google developers)
In essence, a service worker is a separate javascript code or file which runs not on the server but in your browser, completely separate from your page's root javascript thread. This means that the code of the service worker will not interfere with the webpage at any time causing it to halt or "hang". Your buttons, drop downs, carousels, and every other function which requires javascript will work just fine. This also means that this javascript code has no access to the DOM API so it will not be able to manipulate the DOM at any time. However, it has a postMessage()
event which, when fired, will trigger an onMessage()
event on the webpage which can then be used to manipulate the DOM or the whole application for that matter.
The service worker can manage proxy network connections, hijack, fabricate and filter responses. All of which are very powerful kinds of stuff. Now YOU, an innocent developer might be perfectly responsible with these features, however, an unwanted man in the middle may not. Thus, due to the level of what we are dealing with, you must always use an HTTPS connection for using a service worker.
Since the service worker script runs on a separate javascript thread, it also follows a separate life cycle.
The above image demonstrates the lifecycle of a service worker.
First, the service worker must be registered. This is done in the page's javascript code through the navigator API.
After that, the service worker is installed. Typically, during this phase, it caches a list of static files set by the developer.
Then comes the activation phase. After installation, when all previous instances of service workers are closed or "killed", this event is triggered. Typically, this is where you will want to update your caches.
Finally, the service worker just idles in the background managing proxy networks and any other events it receives.
To conclude, even though additional features are currently being planned, service workers are designed to be an extensible platform. It truly is a "game changer" because of how much more control it gives to the developer, which can then allow the developer to deliver a more rich, native experience to the end user. While it can be tough to understand and be prone to some securities, it can also change the whole web app architecture for the better.