The entire cache is automatically cleared when you deploy to an environment?! The whole thing? Every deploy?
Is there any way to prevent this?
Yes, the whole cache is cleared on every deploy. There is currently no way to prevent this. Trying to do so would be pretty risky as it’s difficult to know precisely what doesn’t need to be cleared in many cases when code changes, so it’s not an option we’ve made available.
Given that Moovweb offers the ability to purge the cache with specificity via moovweb.app as mentioned Here : https://developer.moovweb.com/guides/caching#section_clearing_the_cache,
It would be great if cache clear on deploy could be disabled.
We would be super interested in configuring this.
We deploy our app 10x a day and purging the cache on every deployment is a bit of an overkill
Could we disable the cache purge on deployments and just use stale-while-reevaluate for all of our routes.
We could then manually purge that cache through the cli if it is absolutely needed.
The problem with not clearing the cache on every deployment is: how can you be sure it’s not needed? In theory, one line of JavaScript can change the response to every request. In my experience most developers won’t get this right, and will wind up breaking their app in subtle ways. I think a better approach is to rebuild the cache automatically after a clear. We are working on that now as an enhancement to the new static preloading feature.
@mark.brocato I’m not really sure I understand your concerns.
If I’m developing a feature that can rollout slowly and is not essential for all users to get it immediately we can rollout it as the cache updates. An example is a page that is hidden to the public and only internal employees have access to. That page could still live in the same application and therefore cause a cache purge for all live pages when it doesn’t need to.
Another example is that I could be updating a feature on the about-us us page which is a single page but that would mean all our article pages are no longer cached.
A key here is obviously to have all assets using unique hashes and available at all times so that “old” pages will still function properly.
If this is an opt in feature then it would be the team responsibility to make this decision. I don’t think it is your responsibility to prevent “developers from not getting right”.
Regarding the rebuild feature, we have a similar setup for that right now. However, we have an issue were we experiencing a heavy load when trying to rebuild 100.000+ pages. How would you handle that and how long will it take to rebuild 100.000+ pages?
The time to build a page mostly depends on the time it takes to fetch its data. Actual rendering time is normally between 200-400ms. Right now we limit concurrency to 200 pages at a time but that could be raised in the near future.
Thank you for explaining your use cases, that helps me understand the context. I agree that it’s not our responsibility to prevent developers from not getting it right. We’ll just make sure the default behavior is the one most likely to lead to a properly working site.
I’ll discuss this further with the team. I could see us adding an option to xdn deploy to not clear the cache like:
xdn deploy --preserve-cache
That seems like a reasonable solution. Please keep us informed if/when this gets added.
Thanks for the update Mark.
2 other concerns we have with clearing the cache automatically on every deployment are:
- When you clear the cache multiple times per day, all static assets are no longer available to the people already browsing the application. This can make customers unable to complete their purchase or find the product they need because a preload asset returns a 404 error.
- On a big website that is frequently being accessed, all expensive data fetches are executed multiple times per day, requiring the backend application developers to implement other caching mechanisms just to prevent overload.
We would love it if we can prevent cache purges this month.
Otherwise we don’t get any benefit in the caching solution provided through the XDN and we’ll be forced to create a different caching solution, which makes no sense to us at all.
Problem 1 that I highlighted affects all of your customers - as soon as you clear the cache through a deployment, you’re dooming all current visitors that are browsing the affected website.
@siggy Problem 1 shouldn’t happen if you precache all of the static js files for your app with the service worker. Also, doesn’t Next.js automatically reload the app if a lazy-loaded chunk fails to load during client-side navigation?
Regardless, we plan to implement a --preserve-cache flag for deployments in the next few weeks.
I haven’t experienced any refresh when the nextjs app fails to load dynamic chunks so far. The app just crashes in my experience.
Maybe it should work, but I haven’t seen it work.
And generally, we don’t want the service worker to force the client to download all the JS application chunks - that would be a waste of resources and bandwidth for the client and the server.
I’m eager to see the preserve cache functionality in action. 
Keep us posted