Web Assets

Assets compatibility

The database isn’t the only place where versions matter. If our application includes any kind of user interface, then we have other assets to worry about: images, style sheets, and JavaScript files. In today’s applications, front-end asset versions are very tightly coupled to back-end application changes. It’s vital to ensure that users receive assets that are compatible with the back-end instance they will interact with. We must address three major concerns:

• Cache-busting
• Versioning
• Session affinity

Static assets

Static assets should always have far-future cache expiration headers. Ten years is a reasonable number. This helps the user, by allowing the user’s browser to cache as much as possible. It helps our system by reducing redundant requests. But when the time comes to deploy an application change, we actually do need the browser to fetch a new version of the script.

Cache busting

Cache busting refers to any number of techniques to convince the browser, and all the intermediate proxies and cache servers, to fetch the new hotness. Some cache busting libraries work by adding a query string to the URL, just enough to show a new version. The server-side application emits HTML that updates the URL from this: