3 ms·

The article says: > there is a slight chance that someone will get new static content with an old hash (if they hit a CDN miss for a piece of content that actu

by ngrilly 11y ago

The article says: > there is a slight chance that someone will get new static content with an old hash (if they hit a CDN miss for a piece of content that actually changed this build) Anyone has a solution to this problem?

dpark 11y ago
Without poking at their site to see how they behave, I assume they just append a cache breaking param onto the URL for a static entity. Assuming that assumption is correct, the fix is to make the hash meaningful to the process serving the static entities. This adds complexity as now your static site needs to serve requests based on the hash. This isn't conceptually complex but it means you must deploy at least two versions of your static resource (one for each hash in the wild). And you still have to do two phase deployment in this model (static resources first, then the "real" site). Or you can build redirect or proxying support from v2 to v1 and vice versa, which is a much uglier problem to solve, but eliminates the need for two phase deployment. Since they have short deployments, their solution is pretty elegant. If you have long deployments, the hash aware server becomes sensible. If you're a masochist, the two way proxying becomes attractive.
windowsworkstoo 11y ago
Nope, we solve it the same way, it's a pain. I did a presentation once for devs where I unraveled the up-to-9 different layers of caching between an end user and our website (when you take into account the browser and any tiered CDN caching) It's a pest of a problem but pre-deploying static assets is the best answer.
mfontani 11y ago
Push new static content first to all servers/cdn, _then_ bust the CDN cache / push a cache bust
- dpark 11y ago
  This doesn't resolve the issue. The fundamental issue here is that two versions are running in parallel. * If you push static content and web pages together, you get V1 and V2 of both static and web, and you end up with incorrect static resources served in both directions. This approach is only reasonable if your deployment strategy is to take a service outage to upgrade all machines together. * If you push web first, you get the ugly scenario described in the article where V1 resources get served with V2 hashes and cached for 7 days. * If you push static content first, you still have V2 static content being served for V1 web pages. The "cache bust" doesn't matter. Somewhere a cache will expire and someone will get V2 static resources for a V1 page. You have to deal with the two versions somehow if you want to resolve the issue fully.

by ngrilly 11y ago

dpark 11y ago

Without poking at their site to see how they behave, I assume they just append a cache breaking param onto the URL for a static entity. Assuming that assumption is correct, the fix is to make the hash meaningful to the process serving the static entities. This adds complexity as now your static site needs to serve requests based on the hash. This isn't conceptually complex but it means you must deploy at least two versions of your static resource (one for each hash in the wild). And you still have to do two phase deployment in this model (static resources first, then the "real" site). Or you can build redirect or proxying support from v2 to v1 and vice versa, which is a much uglier problem to solve, but eliminates the need for two phase deployment. Since they have short deployments, their solution is pretty elegant. If you have long deployments, the hash aware server becomes sensible. If you're a masochist, the two way proxying becomes attractive.

windowsworkstoo 11y ago

Nope, we solve it the same way, it's a pain. I did a presentation once for devs where I unraveled the up-to-9 different layers of caching between an end user and our website (when you take into account the browser and any tiered CDN caching) It's a pest of a problem but pre-deploying static assets is the best answer.

mfontani 11y ago

Push new static content first to all servers/cdn, _then_ bust the CDN cache / push a cache bust

dpark 11y ago
This doesn't resolve the issue. The fundamental issue here is that two versions are running in parallel. * If you push static content and web pages together, you get V1 and V2 of both static and web, and you end up with incorrect static resources served in both directions. This approach is only reasonable if your deployment strategy is to take a service outage to upgrade all machines together. * If you push web first, you get the ugly scenario described in the article where V1 resources get served with V2 hashes and cached for 7 days. * If you push static content first, you still have V2 static content being served for V1 web pages. The "cache bust" doesn't matter. Somewhere a cache will expire and someone will get V2 static resources for a V1 page. You have to deal with the two versions somehow if you want to resolve the issue fully.