Offline with service workers and an implementation plan

[CaptainN]

I've been looking at offline support for a while now (and contributed to appcache as much as I can), and wanted to put into a more formal plan the results of what I've found, and what I think would be necessary to match the capabilities of something like webpack's offline plugin.

There are a few things that need to happen to get a more robust and modern offline cache system in place.

1. Meteor's appcache needs a new mode for detecting when it should activate. Currently this is all figured out on the server based on a static list of browsers, but we probably want to move that to the client, and only utilize appcache if service workers are not supported. Webpack offline-plugin does this by conditionally outputting an iframe with a link to an html document which contains the link to the cache manifest (app.manifest). This seems to work well.

2. We need a new API. I suggest implementing something directly modeled on offline-plugin - or even port that lib directly and reuse as much of it as we can. A service worker can do more fine grained and varied control for assets than cache manifest can do, so the API to configure that should be more robust than appcache currently allows. I'd say the relationship should probably be something like offline uses appcache - appcache would become a legacy implementation detail (or appcache is deprecated, and most of it is absorbed into offline).

3. We need a way to create service worker end points (build targets). For a shorter term (hopefully) workaround, we can use a customized main entry point (/client/main.js), and use dynamic-imports to split between client code and service worker code (and as many web-workers as we want). All we need is a way to get the generated (hashed) file URL for the main bundle (does this currently exist?), and use that to register the service worker in the client side of the split.

I can do most of this now, without any support or changes in core - except the change listed in #1 above (even there, I suppose I could fork appcache), and #3. But I wanted to discuss this to see if there is anything important I'm not seeing.

[benjamn]

So does offline-plugin stick to a subset of functionality that can be implemented by both/either AppCache or Service Workers?

[CaptainN]

offline-plugin uses the old appcache as a sub-setted fallback. It's API allows for a few levels of caching - main, additional - loaded after app starts, and optional - only cached when loaded during runtime.

Only "main" acts like the old app cache. If we wanted to do full backward compat, we'd also have to either load all the "additional" assets (causing longer load time for older browsers?*), or load those "additional" assets into localstorage, and have some alternative way to load them (fine for meteor's dynamic modules - we do that now actually - less fine for images, etc.). There wouldn't be a fallback/legacy system for "optional", it would just have to rely on the browser cache.

Here's the docs for offline-plugin. And some other more advanced stuff.

• Actually, I'm not certain what the old appcache behavior is - does it load everything in the manifest before starting up, or does it just load things as they are requested?