3 ms·

Continuous Deployment implies at least a few releases per day. Especially for bundled JavaScript (which is most setups) this means you’re invalidating the cache

Continuous Deployment implies at least a few releases per day. Especially for bundled JavaScript (which is most setups) this means you’re invalidating the cache of the entire app at every payload. Imagine having to download an app update every time someone merged to master. That’s most SPAs.

arkanciscan 7y ago
In Webpack the chunks whose content don't change don't get new file names and so the cache needn't be invalidated for them. Vendor code which is often the largest part, can stay cached over many deployments so long as the versions are locked. Of course, your host could still send no-cache headers and invalidate everything, but that's a problem with the host/cdn.
- mhd 7y ago
  Sure, I really do hope that engineers do their best to fix things, but in the sad world of contemporary web frontends, I'm a bit pessimistic (then again, if one has to err on the side of build system over-engineering, you're rarey disappointed). Still, if the deployment system involves frequent node module updates, the vendor files get "dirty" quickly, too.
  - arkanciscan 7y ago
    Sad!? You must not be old enough to remember when we used the global namespace for modules, and there was no console.log(). You wanna talk about sad, try debugging with alert().
Hermitian909 7y ago
This can be the case, but if any of the engineers on staff spend a day reading docs it should generally be fixable. A 30mb it should be chunked by the build process in such a way that small updates usually cause cache invalidation for only a few kb worth of files. If the library you use to build your SPA (React, Vue, etc.) is relatively up to date you should also probably not be sending the whole app over the wire at once to anyone. Routes and components can be set to only load when the user actually attempts to access them inside the SPA, reducing egress significantly.

arkanciscan 7y ago

In Webpack the chunks whose content don't change don't get new file names and so the cache needn't be invalidated for them. Vendor code which is often the largest part, can stay cached over many deployments so long as the versions are locked. Of course, your host could still send no-cache headers and invalidate everything, but that's a problem with the host/cdn.

mhd 7y ago
Sure, I really do hope that engineers do their best to fix things, but in the sad world of contemporary web frontends, I'm a bit pessimistic (then again, if one has to err on the side of build system over-engineering, you're rarey disappointed). Still, if the deployment system involves frequent node module updates, the vendor files get "dirty" quickly, too.
- arkanciscan 7y ago
  Sad!? You must not be old enough to remember when we used the global namespace for modules, and there was no console.log(). You wanna talk about sad, try debugging with alert().

Hermitian909 7y ago

This can be the case, but if any of the engineers on staff spend a day reading docs it should generally be fixable. A 30mb it should be chunked by the build process in such a way that small updates usually cause cache invalidation for only a few kb worth of files. If the library you use to build your SPA (React, Vue, etc.) is relatively up to date you should also probably not be sending the whole app over the wire at once to anyone. Routes and components can be set to only load when the user actually attempts to access them inside the SPA, reducing egress significantly.