4

Context: I have a production application (here if you want to look) that is currently using static asset revisioning using the gulp-rev-all package which is like gulp-rev except that it also handles dependencies when generating content hashes. It generates a new set of files that have static names (eg goals.js becomes goals.6a5aa614.js) and that reference each other using those static names. Then I serve those files up with the Fastly CDN on production, so my NodeJS server isn't being actively used for static assets. This has been working great.

Now I'm in the process of making the site work offline with service-workers. Since I'd done a lot of work on the syncing logic last year, the dynamic part of the site has been pretty easy to overhaul. But I'm a bit at a loss for what to do with my static assets.

I figured I'd use workbox, and that seems to work okay. But the workbox precache uses queries for busting the cache rather than changing filenames, and it seems dumb to do both. But if I stop using the versioned names, then how do I bust the cache on browsers that don't support service worker?

(I have another related question, which is does it make sense to keep using Fastly given that Fastly's responses will be opaque to the SW and therefore not necessarily a good option for precaching? Although without Fastly the app would become a lot slower for anyone who isn't using service workers, which sounds antithetical to the PWA approach. Should I add an nginx cache or something? (I have little idea what this is but I've heard it mentioned a few times))

It seems to me like there's got to be an elegant solution for this, but my understanding of gulp is sufficiently limited that it's hard for me to know what is possible, and my understanding of ServiceWorkers & caching is sufficiently limited that it's hard for me to know exactly what I want.

I'm therefore having trouble getting any traction on this question:

How can I adapt my gulp static asset revisioning to work with ServiceWorkers?

One thing that would be helpful is just a link to examples of how other production applications handle this.

MalcolmOcean
  • 2,807
  • 2
  • 29
  • 38

2 Answers2

4

Service worker works best on top of good regular caching strategy. You should continue to revision your static file names then cache them in the service worker. Avoid libraries that alter the URL via a query string, you don't need that feature as you're already revisioning the URL.

If your assets are served from another origin (I guess this is what you mean when you're talking about Fastly), then allow them to be requested via CORS (via Access-Control-Allow-Origin: *), that means they won't be opaque.

JaffaTheCake
  • 13,895
  • 4
  • 51
  • 54
2

You should keep the file-revisioned assets. For a complete example using gulp and precaching take a look here.

You basically want to use a cache-first, then network pattern. You can match for requests to /goals.*.js/ => and then, depending on your application, you could decide to use the cached goals.js even if the [hash] doesn't match, and then download the new goals.[hash].js in the background.

Or, if the hash doesn't match, you may want to go with a network first, fallback to fuzy-matching cache of goals.js.

As for Nginx. It is often suggested to use a reverse proxy for the static asset serving. Node.js is not great for this task. Here is a good working example. If you go with this setup your flow for the static assets would look like this:

CDN => <= Nginx => Node.js Origin.

If you use AWS. Then a typical setup with Cloudfront CDN would involve setting your Nginx reverse proxy node.js EC2 box as the origin. Then you'd setup a behavior for "/" route and your "/assets" route.

The "/" behavior would likely have a short TTL, while the "/assets/" behavior (route in Cloudfront) would have your long-term (max-age=3153600) caching strategy.

In this scenario almost all static assets will be served from the CDN (Cloudfront). It will only have to go back to your origin when you deploy new code with a new set of file-revisioned assets.

You then use the service worker to make all repeat visits extremely quick, potentially even using an outdated asset (matching name, different hash) on initial repeat visit, by going cache first, then network. Thus all repeat users with the service worker will have a fast as possible initial page load.

Those without it will still get all the benefits of file revisioned, long-term browser cached assets with CDN edge serving.

adamrights
  • 1,701
  • 1
  • 11
  • 27