4 ms·

I understand the general note about caches not lasting forever, no longer referenced files, etc. This response skipped over the most important question "And if

I understand the general note about caches not lasting forever, no longer referenced files, etc. This response skipped over the most important question "And if I make a change daily (or more frequently w/ CD), have 365 of those versions (i.e. maybe versioned as date or hash)?". Simply asked, is every generated JS file a static asset? Must the (indefinite) cache headers be present for every static asset be returned? So if I deploy a new static asset every hour via continuous deployment let's say, I must give it a new unique path? These questions apply to SPAs.

Twisol 8y ago
If I were to build an application 100% in the style of the article, my answer to all three questions would be "yes". But I'd probably opt to version at the level of a whole deployment, rather than at the level of each file. There's a case for versioning non-build static assets separately, but I'd rather version all of the output of a build process together.
pixl97 8y ago
>So if I deploy a new static asset every hour via continuous deployment let's say, I must give it a new unique path? I would answer yes to that. More specifically, if an old cached component could reference the new file and break, then the old component should never know about the new content.
marcosdumay 8y ago
> And if I make a change daily (or more frequently w/ CD), have 365 of those versions (i.e. maybe versioned as date or hash)? It's a good practice for any web application. You place huge caching times for your assets, and make their URLs unique. At the backend, you either have a compilation step that adds the unique marker (a hash is more common) to your links or you have the backend add it at runtime.