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.
Yes, we can also log our requests on some other server before executing API. So, we can extract fields like
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
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.