5 Things you need to know about JavaScript Service Workers

Posted on Apr 26, 2017


5 Things you need to know about JavaScript Service Workers


Yes, javascript service workers, the “thing” developers use to run apps offline. But is that it. Does service worker’s scope is only limited to the offline experience of the user? Frankly, I have heard of service workers the only couple of months back in a workshop. And I was like, why I haven’t used this before. So, after doing some research on this, I found out some cool things which I would like to share with you all today.


Secure or Not at all

Service workers only register on pages which run over HTTPS. During development, you can use localhost but during production, there is no way out.

I mean let’s face it, service workers acts like man-in-the-middle, which can catch your request and do whatever with it. If somehow, someone gets access to your service workers, that person can defer your request to anywhere and I don’t know, do so many other things. I think Github’s pages are the best solution to work in service workers, as they are by default hosted on HTTPS.


API Analytics

Javascript service workers are mostly used as network interceptors. So, we can actually hold our API requests and do something else, right?

Yes, we can also log our requests on some other server before executing API. So, we can extract fields like

1. URL
2. Method
3. Headers
4. User-agent etc

from the request object and populate it in some database. This also removes the extra load of logging from our server.


Push and Sync APIs

Both of these are javascript APIs, which allows a simple web app to behave like a native app, i.e, Progressive Web Apps. These APIs can run in the background in service worker context and give users features like Push Notifications and Background sync. For eg., some event happens in the script but the network is down, then service worker can save it and re-execute the event when it catches network using sync API. It opens the whole new world of features which previously only native apps are supposed to have like, Geo-fencing, notifications, messaging.


Cannot manipulate DOM and Non-blocking

Service workers run in its own thread and can not access DOM (for that we have jQuery). This allows it to be non-blocking in nature, i.e, any operation taking place on service worker doesn’t affect the main thread of the application. By this, service worker has lots of freedom to tasks in the background and can easily act as a proxy between the server and actual web page. The main concept is that there should be only one main UI thread which can change the page, so service worker passes the data to the main thread, which in-turn manipulates the DOM.


Caching responses by request

Yes, that’s possible. You can cache response keyed by request. These come handy when either you have

1. weak network or,
2. no network at all

If there is no network then service worker will send the response from cache straightforward but if the network is weak and taking too much time in sending a response, then we can always send the cached response using a timeout.

Here’s some sample code I have added to show how we can cache files using service workers.

Service workers are not new in javascript and most of the browsers are supporting it, but still, for many of us, it’s a new concept. I believe if used correctly, it can improve user experience and performance of modern-web-apps exponentially.