[App Router] Fine-grained cache control for non-REST fetches

[sumiren]

Goals

1. Fine-grained cache control of App Router for non-REST fetches such as GraphQL, RPC, DB, and so on.

Background

For me at least, in a typical use case, the asynchronous requests to make from React Server Components are not REST: they are GraphQL, gRPC, direct CRUD of the database via Prisma, etc.
However, in App Router, you can only utilize the cache control feature of the fetch() function when calling simple HTTP-based endpoints (so-called REST-style)
I know cache() function, but it only supports request deduping, not ISR/SG cache control.

It would be a shame if the fine-grained cache control of the fetch() function is actually useless in most use cases.

Proposal

How about add support ISR/SG cache control feature to cache() function?

export const getUser = cache(async (id: string) => {
  const user = await db.user.findUnique({ id });
  return user;
}, { next: { revalidate: 60 } });

It might be more practical to create some module like next/cache which wraps react's cache() function.

Thanks!

[chrislicodes]

I was also wondering about that - it would be great to support something in that direction 🤔

[sandrooco]

I'm facing this issue too.
Is it possible that the docs on cache-control are actually wrong currently?

setting the revalidate prop in the page's getStaticProps function

getStaticProps doesn't exist in app router...

[kanishk-agrawal]

Hi, is there a plan to fix or get a workaround on this?

[leerob]

It's now possible to customize cache-control as of v14.2.10. Please upgrade and give it a try!

#69802

[sumiren]

Thank you for the information! It does seem like this approach would partially achieve what I'm aiming for. I'll give it a try.

However, when I think about a route where, for example, I want to cache a gRPC request for 1 minute but avoid caching a DB query altogether, it seems that we would still need more fine-grained control at the Data cache level.As far as I understand, fetch() was updated so that data cache is no longer dependent on the slowest revalidation frequency within the same route, which is great.

For what I’m trying to achieve, unstable_cache may be a closer match. I still have some concerns about its stability at this point.

Nevertheless, if there’s a separate master issue tracking unstable_cache, perhaps this issue can be closed and the conversation can be continued there.