Hacker News Reader

Comment by rakoo | Hacker News Reader

Then you should do what Facebook does (https://code.facebook.com/posts/557147474482256/this-browser...): content-addressed resources. Have a resource be available not at /resources/something.js, but at /resources/<sha1(something.js)>; whenever there is a new version of something.js, the sha1 changes and is put in your root document, and the browser will never again try to reach the older version, which you know is invalid now.

View on HN

This is also the default in Rails with the asset pipeline since 4.0.

It's even older than that. Sprockets always have been content addressed, but in early versions it used to leave non digested aliases (by mistake actually), and some people relied on it.

But ever since 3.1 (Aug 2011) Rails defaulted to content addressed assets.

Content addressing of data is one of my favorite ideas in the field.

And what if the resource in question is a dynamically generated minified thing? Do I have to dynamically generate it within the main html page to be able to figure out the sha?

These are big complex workarounds for a problem that is easily solved at another layer.

Typically these are shared resources and can be generated once and saved so your HTML page would simply be checking file metadata generated at the time the app was built.

If it was truly custom, you could either do cached on-demand generation or find some other portion of the cache key which reliably changes on updates – e.g. I've seen people use things like Git commit ID + feature flags.

But what happens when you need to cache the actual page not just static resources? That's what the content-addressed resources trick doesn't address.

You cache the actual page with a much shorter cache timeout.

Then just cache the actual page. The cached version refers to some possibly old versions of the static resources, so your server needs to be able to serve old versions for a period of time.

Reply on news.ycombinator.com