2 min read

Hellish web…no

The browser has become the undoubtable king of the ubiquitous members of the internet and over the years has grown in how we interact with…
Hellish web…no
Photo by Markus Spiske on Unsplash

The browser has become the undoubtable king of the ubiquitous members of the internet and over the years has grown in how we interact with it. One of the greatest concerns however has been how the browser could handle being offline and still function as if it were online, giving the impression that it was still working. A couple of ideas were implemented to achieve this but they all fell short of the mark for various reasons but with the introduction of HTML5 came a whole new way to achieve this called, Service Workers and this is the bread and butter of this article.

Service Workers act as proxies between the browser and a web server, creating an interaction layer that sits in-between them. It does its bidding on something called a *worker thread* thats just geek for ‘please stay in your lane’ so that your interface does not become irresponsive when doing a load of work.

So what makes Service Workers special as opposed to its failed cousin the AppCache? Lets see some of it.

Photo by j on Unsplash
  1. It provides a cache: This is actually a ‘duh’ point. The SW has a cache where you can store assets for use when either offline or have no need to re-fetch from a server. The cache provides several endpoints for use for this.
Photo by Olliss on Unsplash

2. Life-cycle hooks: Service workers provide hooks to manage the installation, activation, fetching and other events that a developer might be interested in controlling in their applications.

Lets focus on the fetch hook for a bit because that presents some interesting importance when taking considerations for building out an application to use with Service Workers. With this hook, you can intercept network requests, transform them, modify them, update them etc before either sending them off to some server somewhere or simply just responding to the request yourself instead of allowing it continue on its way. Some really interesting use cases could be:
1. You don’t want your users to have to always download content they already have in their cache, so instead you can just intercept a request, check to see if they have what they’re requesting already cached, and then respond to it if they have it or simply send off the request to fetch it from the server if they don’t.
2. You’re building an application and have all the mock values for request responses and don’t want to build off a separate server for now. You can use your service worker to intercept requests and just send back your responses instead. Quick. Simple. Nifty. Neat.

Hope you’ve had fun. Now the web does not have to he hellish after all.

twitter: @cozzbie