Separating Concerns through Service Worker Helpers
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.
