A way to invalidate the cache of the cloudfront distribution

[mohalsherif]

Context

We deploy our NextJS app on each push. We currently face a a problem where already existing files are not updated fast enough. We currently invalidate the cache on each push to have the up to date files on our DEV environment.

Question

Is there a plan to support ttl values (min,default,max) for the default_cache_behavior in the aws_cloudfront_distribution terraform resource via input variables?

Other Approaches

We would like to avoid creating the default_cache_behavior on our own, but to have a way to invalidate the cache so the up to date app is accessible. Is there a different way this can be solved?

[ofhouse]

Hi, thanks for reaching out!

Invalidations in CloudFront are unfortunately pretty limited since we can only invalidate by pathname.

Our algorithm currently checks the pregenerated static routes and calculates the paths that should be invalidated from it.
We currently have a bug identified related to the topic where static routes are not invalidated that contain a dynamic part in the route, e.g. pages/test/[id].js: #140

Any chance that the wrong invalidation behavior relates to this problem?
For server-side rendered routes we are currently not able to generate invalidations since we are not able to guess the paths correctly (Same thing for rewrites).

---

ttl is currently set at different points in the app (S3, Lambda for SSR pages and CloudFront as fallback), so adding a ttl option only for CloudFront would be confusing for most users.

Would propose 2 solutions for the problem here:

Solution 1

Creating a custom CloudFront distribution and adding a custom cache behavior following the existing CloudFront example.
The custom cache behavior is pretty basic and could be copied from here.
Then all ttl (min_ttl, default_ttl, max_ttl) values should be set to 0 to disable caching completely.

The good thing about this is, that this works today without any changes to the module.

Solution 2

We could introduce a new option to invalidate the whole cache of the CloudFront distribution on every update (push).
This would also help users that use server-side rendering (SSR).

[mohalsherif]

It is definitely related to the bug. Now it makes sense. It only invalidates the paths with dynamic slug. I saw the bug in the issues, but did not understand what was meant by it. Wasnt aware that ttl is used on those 3 resources. Thanks for the hint.

We are using solution 2 now with the following command aws cloudfront create-invalidation --distribution-id ".." --paths "/*" . This works for now. However we do some intermediary steps to get the distribution_id from the output cloudfront_domain_name .

We would stay however with our solution for now, until the bug gets fixed. Thanks for your fast reply.

[ofhouse]

We have now released a fix in v0.10.1 which should correctly invalidate paths with dynamic parts in it.

Closing this issue for now, but but feel free to post here if this fix isn't working for you.