Good practise for migration to cache components

[brunorzn]

The cache components feature was long awaited for me, as it enables some very good use cases.

Unfortunately, migrating to it is quite painful. I find it hard to understand the clear production-ready good practices from the documentation.

My main use case is building mostly static sites, with potential dynamic segments, that get a lot of traffic and are based on a rate-limited CMS.

With the previous Next version and generateStaticParams, everything was very simple and worked very, very well.

Reading the documentation, using “use cache” felt very natural and promising, as I was used to use unstable_cache() when necessary. That was until I read about the “use cache: remote” directive, explained much, much lower down in the docs...

It is hard to understand how to achieve the exact same behavior as before, and what the best way to do so is. We should we put “use cache: remote” ? At the page or layout level? This feels very unnatural.

Another example, the generate static params documentation mentions a cache component example that displays a “use cache” directive within a route, and presents it as “optimal caching”. However, since “use cache” is in memory, deploying this to a serverless environment like Vercel means the fetch call will be made many times, hitting our rate limits and increasing our bills. Sounds far from optimal caching to me.

Even when using “use cache: remote”, I still see a lot of calls to that rate-limited API being made, even though I have set the following in the Next config:

cacheLife: {
    default: {
      stale: 300, // 5 minutes
      revalidate: 604800, // 1 week
      expire: 2592000, // 1 month
    },
  }

How can I guarantee that my fetch calls won't be made twice, unless I manually call something like revalidateTag ?

Thanks

[icyJoseph]

Mmm I see, take a look at: https://nextjs.org/docs/app/api-reference/file-conventions/dynamic-routes#with-cache-components

Looks like I'll need to move a few things around. This section, https://nextjs.org/docs/app/api-reference/functions/generate-static-params#with-cache-components points you to:

• See the dynamic routes section for detailed walkthroughs.

And the rest under is about Route Handlers, and Route Handlers with Cache Components

[icyJoseph]

However, since “use cache” is in memory, deploying this to a serverless environment like Vercel means the fetch call will be made many times, hitting our rate limits and increasing our bills. Sounds far from optimal caching to me.

That depends. In that case it is a Route Handler. If the data call doesn't depend on runtime data, the result of the Route Handler can be cached, so it'll HIT, for example if you see the response headers here: https://nextjs.org/docs/app/getting-started/project-structure.md

It is true that if you do depend on runtime data, or rather, do runtime caching, that doesn't save to a GET route handler response, or the static shell, in a serverless deploy you likely will hit upstream a lot. Surprised remote is still making more calls?

[brunorzn]

Yes, I forgot to mention that the data doesn't depend on runtime data. Everything that depends on runtime data will be behind Suspense boundaries

[brunorzn]

Let's have a simple example with:

layout.tsx, page.tsx, and expensiveFetches.ts

page.tsx exports a getStaticParams() function.

My first approach was to simply put "use cache" at the top of layout/page.tsx, but I realized many calls where made in expensiveFetches.ts. Is that the expected behaviour, or did I do something wrong ?

I will write a simple example for this. Maybe something else was triggering the fetches, like the default cache life being incorrectly set.

[icyJoseph]

Right, but you should be able to then use cache on the functions fetching this data to include it in the static shell. And with generateStaticParams, you return some paths you wanna prerender at build time.

I need to sign off, but if you have a repository, or could share some code I can try to answer later.

[brunorzn]

Thanks a lot :)
I'll work on a basic example repository