Add ttl for cache behaviour

[superandrew213]

Can we add ttls?

Something like this:

ttl:
  min: 0
  max: 31536000
  default: 84600

Happy to make PR.

[superandrew213]

This is the problem I am trying to solve.

I am caching all static assets except index.html. After a new version of the app is deployed, user will load latest index.html which will reference the new static assets. This works quite well.

However there is an issue with this approach. What if user loads the page while the upload of the new files is in progress? If index.html has been updated, then it will be referencing the new files. The problem is that these files might not have been uploaded yet.

By setting MinTTL, CloudFront will cache index.html but still pass the Cache-Control: no-cache, no-store header to the browser. Now user will get latest index.html only after cache has been invalidated or CloudFront serves latest index.html.

However this approach still has issues. CloudFront can invalidate index.html when ever it wants. Tested this and have seen a few X-Cache: Miss from cloudfront responses.

Possible solutions:

1. Don't delete files in s3 bucket and upload index.html last.

2. Upload new app to a different bucket, then set CloudFront origin to new bucket. Delete old bucket. Needs to be tested.

3. Upload new app version to a temp bucket, then copy it over to main bucket. This would be faster than uploading directly to main bucket.

@andrewphahn what do you think? Do you use a different way to solve this issue?

[andrewphahn]

Something I hadn't thought of. I cache everything so haven't been hit by it... yet.

Option 3 is maybe the best way to address it, but because of s3 replication you might still get the behavior you are trying to avoid, and I don't think the copy is atomic (don't really know).

Option 2 might give the best results, but it will take 20 or so minutes for the CloudFront distro to update. Not really what you want to have every time you deploy.

Option 1 is no guarantee, you can still be bitten by s3 replication and you will get stale files in the bucket when you remove a file.

I think setting the ttl values is a legitimate feature to include. They are set in the CacheBehaviors for the API origin, don't see why setting something similar for the s3 origin wouldn't be a good idea. Not sure if they belong in DefaultCacheBehavior or not. Maybe the generalized behavior would be to allow defining CacheBehaviors in the config that get added to the list in the manifest.

cacheBehaviors:
   - MinTTL: '0'
      DefaultTTL: '0'
...

Thoughts?

[superandrew213]

We can add both DefaultCacheBehavior and CacheBehaviors.

See PR

[superandrew213]

What do you think about Option 4?

We leave the Origin Domain Name alone but update OriginPath.

Same s3 bucket but upload new app versions to different versioned dirs.

Eg.

bucket
  /v1
  /v2    <= current active version
  /v3    <= latest version just uploaded

Then we can update OriginPath to v3.

We could also provide a method to revert back to older app version.

[kelchm]

I like the suggestion of versioning using directories. The really nice thing with this is that it provides a clear path to cleaning up old versions after some period of time has passed.