Don’t space walk without a tether, get a worker

I sit here on Oscar night, wearing my “science the shit out of this” Martian t-shirt, reflecting on how often we enjoy a tense moment in a space movie where we hope that an actor doesn’t get shifted off into space.

You can’t help but gasp a little for air as you think about the awful thought of slowly moving in the wrong direction in space, without a thrust ability to change momentum and get you going anywhere but slowly to your doom.

You see it coming. “REMEMBER THE TETHER!” you cry at the screen, or you look for something that will harm said flimsy chord.

I have had a similar feeling when shipping production changes that effected cache headers. You have tested and tested, but you fear a bug that sets a cache header too far into the future, a bug that has your client without a tether. The client doesn’t think it has to phone home to see if there is a new version of the content, and you have no way to fix this after the fact. ET can’t phone home.

Service Workers give you a tether

One of the great features of service workers is how it gives you power over the full installation experience and running of the web applications in your domains. You get to aggressively cache the pieces of content that can be cached, yet you also have the browser talking back to you outside of the tab to nicely swap in new versions of the service worker that controls the lifecycle, and the cache itself. The platform gives you rich programmatic power, and tools are popping up to help make common cases simpler (e.g. sw-toolbox is battle tested in production by folks such as Flipkart).

One of the important implementation details of service workers is the lifecycle and how often the browser will look to see if a new one is available (all it takes is One Byte).

The service worker is precious. When you update it you want your users to get that update in relatively short order. But blimey, what if you somehow messed up and set a far future header on this puppy? No worries, the tether is firmly in place.

As you can read in the spec you can set a cache header if browsers are hammering you for an updated worker all the time (no need to prematurely optimize of course, this is all done out of band):

“The user agent obeys Cache-Control header’s max-age value in the network layer to determine if it should bypass the browser cache”

But, the max-age can never be more than a day (or as our APIs think of it, as 86400ms:

“If the time difference in seconds calculated by the current time minus registration’s last update check time is greater than 86400”

You get some rope, but it isn’t there to hang you, it is there to make sure your update never goes beyond a day.

Can I fix more?

This is all very empowering, and in typical fashion when you give someone an inch they want a mile. Being able to programmatically dink around with the cache directly makes me with that I could do the same for the entire browser cache.

With a service worker you have a way for the user agent to talk to some of your code that can control a particular scope, outside of the typical page loading life-cycle.

What if I could have some code that would be able to fix any other mistakes that I have made. Let me clean up some of those old cookies I forgot about, or add a tether after the fact and let me say “hey if you have /path/to/foo.html please change the caching expiration. I messed up a year ago, and it feels so good that I have a way to now fix my mistake”.

Having that special bit of code is pretty special. Being able to create a true offline first application that makes everything run as fast as possible feels very progressive, but I also can’t help feel like we have only just begun to build a model that gives me amazing control over the relationship between myself and my users agent.

Hippocratic Service Worker

You want to be careful with new tethers, so how about getting the hippocratic service worker out there on your site so you can start experimenting? Get something trivial that lets you see what is happening, lets you play with updating the service worker and your kill switch system. Then you can take ownership of the dinosaur as you get on the fast path to delivering your users a fast path.