4 ms·
Curious what's the strategy you use to invalidate browser cache for non-SPA? When deploying new changes.
by paraditedc 8y ago
Curious what's the strategy you use to invalidate browser cache for non-SPA? When deploying new changes.
- adamcw 8y agoSPA's tend to come with build systems, but that is just a side effect of their complexity. You can have a front-end build system independent of SPA/MPA architecture. In fact, you should, at least for minification and whatnot. That system can add a content hash or some other strategy to force invalidation at build time for deployed artifacts. Barring that, whatever is serving the asset should handle it's caching/TTL stuff correctly, but config of that can be hard (in complexity or domain knowledge.) Build hashes have been the most resilient approach that I've found so far. Mostly because it is easily automated in artifact generation.
- pritambaral 8y agoVersioned URLs of everything except index.html should work just fine.
- gondo 8y agoversioned url
- paraditedc 8y agoSorry if it is not clear, I was referring to html files returned by servers when user visits old-fashioned server-rendered web pages (non-SPA pages) like `/page1` or `/page2`. How do you version urls like those? Something like `/page1?t=201811292359`? That seems ugly to the users.
- gondo 8y agorules i use: - content under certain url should never change - if it has to change then use ESI or/and smaller cache expiration times - if it has to change very often/realtime, then use static html as skeleton and load only required information via javascript. f.e.: info about currently signed in user, eshop basket
- astockwell 8y agoAs others have mentioned: app.min.js?$hash-or-date-or-releasever$