search

jacquescrocker / jammit-s3

Extensions so you can use jammit with s3/cloudfront for your Rails app
http://documentcloud.github.com/jammit/
MIT License
125 stars 31 forks source link

CloudFront invalidation #3

Closed fbjork closed 13 years ago

fbjork commented 14 years ago

Would it be possible to add CloudFront invalidation support?

jacquescrocker commented 14 years ago

got any docs on this? I'm sorta a newbie with s3/cloudfront at the moment but I'm happy to dig into this and try to get something implemented

fbjork commented 14 years ago

http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/index.html?Invalidation.html

thanks for looking into this!

fbjork commented 14 years ago

Also checkout http://github.com/geemus/fog for inspiration if you haven't already

kmamykin commented 13 years ago

I implemented asset versioning on my fork kmamykin/jammit-s3 and submitted the pull request. Until it is merged back by railsjedi, you can use it with gem 'jammit-s3', :git => "git://github.com/kmamykin/jammit-s3.git", :branch=>'master' And check the README!

dedene commented 13 years ago

You could also have a look at my fork: git://github.com/dedene/jammit-s3.git

I implemented Cloudfront invalidations in combination with only uploading new files to S3. Basically it collects all file names that changed and sends an invalidation request to AWS. It's maybe not the cleanest code, but it works very well!

kmamykin commented 13 years ago

dedene, Question: how does Cloudfront invalidation work for files with very long cache-control values? Wouldn't browsers cache the assets on the client without even checking with the server if a newer version of the asset exists? What values are you using for cache-control and expire headers?

dedene commented 13 years ago

The cache-control header is used by both the Cloudfront edge locations to check for new versions and by your browsers to cache locally. The first is in fact the only thing being affected by the invalidation requests: meaning, although you have a very very long expiration date set, you can force a renewal of the files at the edge locations at any given time. However, indeed, once it's locally cached by a browser, a user will need to do a force refresh to reload a file before the cache header expires...

I'm currently using 24hours as a value and the invalidation requests to ensure that new visitors to my sites have at least the right assets directly. I agree that asset versioning, meaning complete different asset name for each version is better, but for me my implementation is a good trade-of between uploading all (also the onces that did not change) assets again after each release and having control on caching the assets.

kmamykin commented 13 years ago

I merged forks from dedene, gauravgupta123, simonoff. Someone needs to kick the tires here, if you have a few spare cycles. You can use a small test app I created for this purpose: https://github.com/kmamykin/jammit-s3-testapp