JavaScript

I am enjoying a new pattern emerge as we do more work with service workers, and that is wrapping a libraries usage, or some functionality, with a service worker that improves a particular concern: e.g. reliability. This reminds me of a past life in which I enjoyed aspect oriented programming techniques to keep the core business logic clean, but add other concerns separate from that codebase.

Let’s take a look at two examples of this technique that popped up in the last couple of days.

Case One: Offline Google Analytics

As soon as you start considering how your app will work offline, you think about many side effects. How will I track the offline usage is one. You may naturally take an analytics library and start flushing out the cases for checking for network access and doing the right thing. The problem though is now you may have a lot of logic that is dealing with offline usage tied into business logic, and you also may be looking at how to funnel all usage through this library.

Instead, you can add this functionality through a service worker that is able to intercept access to particular URLs, which is exactly what sw-offline-google-analytics does:

“sw-offline-google-analytics sets up a new fetch event handler in your service worker, which responds to requests made to the Google Analytics domain. (The library ignores non-Google Analytics requests, giving your service worker’s other fetch event handlers a chance to implement appropriate strategies for those resources.) It will first attempt to fulfill the request against the network. If the user is offline, that will proceed as normal.

If the network request fails, the library will automatically store information about the request to IndexedDB, along with a timestamp indicating when the request was initially made. Each time your service worker starts up, the library will check for queued requests and attempt to resend them, along with some additional Google Analytics parameters”

---

Case Two: Keeping Users Logged In

“Why does my app never ask me to re-login, but the website seems to force me to every now and then?”

There is no reason to not offer safe long sessions on the web, and we can piggy back on the age old two-token pattern to refresh tokens at appropriate times.

The example code shows a service worker that does the refresh work based on the expiration date, by wrapping calls to the backend.

---

Helpful Workers

Service workers are powerful and as such there are many things that you can do. It is interesting to see people come up with patterns to make common uses simpler. We are pushing on this with our own sw-helpers and I am curious to see what others come up with.

We need to remember to scope the work that is done there appropriately, because you obviously can’t rely on the user having a service worker, but there are so many cases where you can drop in useful functionality in a progressive way.

I appreciate what the browser does for me caching what it can, but man that black box feels… well too black boxy. It has a complex algorithm that attempts to work out what it should keep and what it can safely purge, but I know it isn’t optimal for me and my needs as an end user and a developer trying to serve users.

I think that with recent advancements we are getting closer to being able to really own the cache to better serve everyone:

Pre-fill the cache

Just as a teacher needs to be one class ahead of the student, if you can fill up the cache ahead of time the experience will feel fantastic. You can tell the browser to do just that with the various resource hints (prefetch, prerender etc), and with service workers you can make more fine-grained control with programatic access to a cache. It is a common pattern to go ahead and cache as many static assets as possible on the install of a service worker. You want to make sure the service worker JavaScript file itself isn’t cached too far in advance, but everything else that you can should be far future expired with a unique URL.

Cross Domain Caching

Your service worker can intercept URLs outside of your scope, which allows you to cache beyond your domain. But if both of us have a service worker, we are both getting and caching those Google Fonts. We can go one better with the new foreign fetch API. This allows Google to have a service worker that caches the fonts once, and everyone benefits from it. This should offer huge leverage for the common assets that we use on the Web, especially the bulky ones like fonts.

Back in the day I worked with the team to create the Hosted Libraries as a CDN for common JavaScript libraries. The thinking was, if we could get a lot of people using the same URL for jQuery version x.y.z, then there would be a higher likelihood that it would be in the cache, and thus available immediately.

We also talked a lot about the idea of not relying on the URL. What if we could put a hash into the script tag, thus allowing any URL that had the same file to reuse what was going on? Hmm, well, how do you know if the file is right without downloading it (kinda defeating the point).

But it turns out that the hash is useful in another way, and thus we now have Subresource Integrity, where we can at least make sure that the downloaded file is the one that you wanted to download and execute.

Oops

Have you ever made a mistake and set a far future header on the wrong resource by mistake? It is quite scary that a bad header can mean that a file is lost to some browser caches for good. Whenever making important changes to headers I feel like I am on a mission in space where one wrong move and the tether to my ship will my users will drift off into space with no way for me to fix them.

I would love a way for my service worker to be able to be that tether, so I could tell the browser “hey, if you have a file that matches this URL, can you reset the cache header because I messed up? er, kthankssorry!”

In general I love the trend of empowering developers to do what makes sense for them, by getting more and more access to the browser, but only when needed.