search

cloudflare / Stout

A reliable static website deploy tool
MIT License
752 stars 29 forks source link

CloudFront Invalidation #4

Closed csu closed 9 years ago

csu commented 9 years ago

Could we also get CloudFront Invalidation for changed files?

zackbloom commented 9 years ago

In general its unnecessary. Most files Stout uploads have version information in the path name. For example, lib.js becomes f3a4c9a123/lib.js. When the contents of lib.js are changed, that hash changes, making the file instantly invalidate.

This is, unfortunately, impossible with html files, as your site needs them to be in the correct spot to work. For html files we upload them with a 60 second cache timeout. This means any change you make will be live within 60 seconds. Since CloudFront cache invalidations can take up to 20 minutes, there's not much point in bothering.

levithomason commented 7 years ago

Would you reconsider this decision? Setting a TTL 60s somewhat defeats the purpose of caching. It means we're losing out on the performance benefits of caching. Per the CloudFront docs:

Increasing the duration means your users get better performance because your objects are more likely to be served directly from the edge cache. A longer duration also reduces the load on your origin.

Although you cannot hash the index files, you can use long TTLs for performance and invalidate both the root object / and /index.html object of changed directories on deploys. This is common in Gulp builds (node.js) with plugins such as gulp-cloudfront-invalidate-aws-publish.

zackbloom commented 7 years ago

I'm not against invalidation. It's a little more expensive and slow with Cloudfront than some other CDNs, but that's not necessarily a problem as you don't deploy all that often (although might mean your changes aren't live for ~20 min or so).

The bigger issue here is that the browser will be caching your files for your TTL, and there's no way (outside of HTTP/2) of invalidating those files. So you have to expect that your files will be around for the full TTL you specify.

That said, we could specify a longer s-maxage (which only applies to the CDN), and then invalidate to clear that. I question though if the occasional request speed up (as now there will be a slow-ish request every 60s) is worth the 20 min deploy time.

levithomason commented 7 years ago

This is fair as well. If I have a more concrete proposal for moving this forward, I'll open up a new issue at that time. Thanks for the response and thoughts.