> You can have Cloudflare cache your assets, but it doesn't seem to respect expires headers.
Why do you expire assets at all? If it's because you are deploying new versions of the app, would it not be better to solve this by using revision-stamped URLs? When you deploy a new version of your app, just change the stamp and let the old assets expire.
This has the secondary benefit of ensuring that all application-served pages use the assets the page was designed for, ie. avoiding the race condition when a user gets served a page from app version 1, but gets the asset for app version 2. (If app version 2 has changed an internal API used by the JavaScript, for example, this will result in actual app errors, not just a page that looks a bit weird due to mismatched CSS rules.)
Invalidation is a challenge with any kind of caching system. Invalidating passively by changing the cache key means that the cache has to keep more old cruft around until it expires naturally, but it's easier to implement and works around the race condition problem.
Why do you expire assets at all? If it's because you are deploying new versions of the app, would it not be better to solve this by using revision-stamped URLs? When you deploy a new version of your app, just change the stamp and let the old assets expire.
This has the secondary benefit of ensuring that all application-served pages use the assets the page was designed for, ie. avoiding the race condition when a user gets served a page from app version 1, but gets the asset for app version 2. (If app version 2 has changed an internal API used by the JavaScript, for example, this will result in actual app errors, not just a page that looks a bit weird due to mismatched CSS rules.)
Invalidation is a challenge with any kind of caching system. Invalidating passively by changing the cache key means that the cache has to keep more old cruft around until it expires naturally, but it's easier to implement and works around the race condition problem.