Service worker cache localisation

[robinglen]

Sorry this is not really an issue but a question / problem I was having and wasn't sure where to ask.

I'm trying to implement a service worker that will sit at the root of our website however it will need to cache assets that it is unaware of. They are coming from a collection of domain specific microservices and I don't want teams to need to release SW as part of their deployment pipeline.

Todo this when each service is built it creates it's own asset manifest similar to this:

{
    application: {
        name: 'app name,
        id: 'app-id
    },
     css: [
          { filename: 'name.hash.css' }
     ],
     js: [
          { filename: 'vendor.hash.js' }
     ],
     fonts: [
          { filename: 'font.woff2' }
     ]
 }

There is then a service that collects all our services assets manifests and generates a sw cache manifest:

{
    'app-id': ['/asset/name.hash.css','/asset/vendor.hash.js', '/asset/font.woff2']
    ...
}

This is uploaded along with our assets to a bucket that is internet facing. Then our service worker loads in this json file at boot time and passes a merged array of assets to workbox.precaching.precacheAndRoute.

This means that our service worker doesn't need to have an understanding of what our separate teams are releasing, or even if we add a new service, the cache can always be up to date. However my issue does in because we also support multiple languages.

This means I want to load different assets into the cache based on the users set language, I looked at a few different options:

• Use browser language setting: https://chromium-review.googlesource.com/c/chromium/src/+/1136794 - however browser language doesn't mean its the language they are browsing the site.
• You can't access cookies in service worker: Add cookie accessor/setter methods? #707 however you could potentially read the language in the website and use post messages to send it back to service worker: https://googlechrome.github.io/samples/service-worker/post-message/ - this seems pretty gross though and I've not tried this.

So my final thought was to register a service worker dynamically based out the url:

$ curl https://www.my-site.com/en-gb/

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register(`/{en-sw.js`);
  });
}

From here then the service worker could call the sw cache manifest which could return something like:

{
    'app-id':{
        en: ['/asset/name-en.hash.css','/asset/vendor-en.hash.js', '/asset/font.woff2'],
        de: ['/asset/name-de.hash.css','/asset/vendor-de.hash.js', '/asset/font.woff2']
    }
}

Then it would know as the en-sw to use the en array.

However this would involve either generating multiple service workers (one per language) or service workers are actually generated programmatically based on the in bound request.

At this point I'm not entirely sure if I'm over thinking this and there is a much simpler way of doing it... so just wondering if this is a problem anyone else has had and how they solved it.

Thanks,
Robin

[tomayac]

Maybe some of the ideas outlined by @jeffposnick in this StackOverflow answer are applicable?

[jeffposnick]

It's also worth reading https://web.dev/google-search-sw/#problem:-experiments-and-dynamism, which describes the approach the Google Search team took when implementing a service worker: they took advantage of the control offered by dynamically generating a service worker script server-side, based on the incoming HTTP request.

There's an extra burden of maintaining the server-side code, and it's a different approach when you start thinking about using the service worker API "dynamically," but it does give you the most flexibility.

[robinglen]

I will check out this article. I was wondering if I was over complicating things by thinking about a dynamic service worker but it would give me the flexibility I need to handle some of our requirements.

@tomayac @jeffposnick thanks for getting back to me.

I will populate this issue with my findings incase anyone is interested in what we did.

[robinglen]

@jakearchibald if you are interested here is how we went around solving our issues: https://medium.com/@robinglen/how-we-built-a-service-worker-for-our-micro-frontends-881eabfbf267