Understanding cache persistance

[joecritch]

Hi folks,

I'm exploring an AWS ECS (Docker) + Redis + next-shared-cache stack (as an alternative to OpenNext). It's a Pages Router-only app, using mostly ISR.

But I have two questions:

1. Is there any way to have a persistent fetch cache between deploys? I don't want to have to hit my API thousands of times during deployment.
2. Also, what are the best connect to the Redis service while building a Docker image? Is that a good idea at all?

Thank you!

[garthus]

Hey @joecritch

So we have a similar setup but we have Varnish in front of the app as well which then persists the html and json between builds - and what you see is a more graceful switch over between deploys.

Redis will persist but i would expect you will use the build_id as the cache key so in effect you will be invalidating the cache with each build.

One thing I am exploring and will look to do in the near future - when we can upgrade to Next 15 I think is to pre-populate the cache

https://caching-tools.github.io/next-shared-cache/usage/populating-cache-on-start

So that essentially you will build your cache through the pipeline, then use that to warm the cache.

Something else with this

persistent fetch cache between deploys?

Im guessing your use case is different, but you API - would that have independant cache on it? In our situation for this, we have a set of Varnish for our API cache which will continue to be valid for each deployment - for example, the Shared Nav on our site will be cached - so each build will be getting the same results - despite the rest of the build being different