Are the official docs contradictory on caching?

[magnusriga]

Summary

On this docs page, we can read:

The response from fetch is not cached by default.

Then, directly below, it says:

If you are not using any Dynamic APIs anywhere else in this route, it will be prerendered during next build to a static page.

Are not those two sentences directly contradictory?

Are routes cached in the Route Cache, and nested data in the Data Cache, i.e. the route is statically rendered, by default, or not?

Additional information

No response

Example

No response

[frantisek-heca]

comment/rant from a nextjs app router beginner:
the more i dive into the caching topic, the more i realise how confusing it is by nature, because it has so many rules in the code, it's hard to describe in the docs, even if they try hard with nice pictures, it's obvious it's hard to keep docs consistent, updated with the real code and the changes they constantly do to the caching logic (btw the real code is full of interesting comments that are sometimes helpful, or confusing, they just add me another point of view to the docs)

for me, the docs about caching are full of questions, inconsistencies (maybe with a good intenstions), naming of things is not consistent and i am quite often confused

but am i surprised? from the beginning when i have seen how many caches they use, i was shocked... how the hell can anyone, anywhere reason about this, keep working with this, are we mad? but i already know the answer for decades.. yeah, we are, we love complicated things

btw the cited sentences are not in the links you provided, this gives me a more confusion to your particular question :)

[magnusriga]

I had the same experience. The docs are seemingly full of contradictions on caching behavior and naming. Which is a bit odd, given the popularity of Next.js.

Also, it is not clear if/when the use cache directive is needed when using Partial Pre-Rendering. I wrapped all dynamic components in Suspense boundaries, but certain data fetching functions outside of those boundaries are still being re-run on every page visit. Which makes me wonder if use cache is actually needed, or if there is something else I have not understood.

PS: I fixed the link.

[markomitranic]

@magnusriga yes, the reason it is so confusing is that they are conflating multiple (traditionally separate) caching mechanisms. Data cache is different than HTTP cache, which is different than render cache, which is different than memoization, however, the next team is trying to simplify things by making it all be a single group. This, however, led to oversimplification, and a huge degree of confusion though implicit rules.

On its own, that'd be fine, but we lost a big deal of existing functionality in the process.

[magnusriga]

@markomitranic Yep, makes sense. I reached the conclusion that I would rather forgo the benefits of serverless, and instead run Next.js on a VPS, just so I can see, understand, and control exactly how caching works.

The downsides of the lost transparency and control are simply too big.

[markomitranic]

Same with me @magnusriga although I've still had some caching issues when using nextjs caching primitives such as unstable_cache or page revalidate times.

In the end, i ended up setting everything to dynamically render, and using an industry standard for backend caching https://cacheable.org/docs/ which is in use by many serious framework like Nestjs and relies on keyv as the underlying storage mechanism. I got a TON of benefits, such as stampede prevention, sub-1ms L1 LRU cache etc.

[magnusriga]

Cool @markomitranic . I haven't gotten that far yet, we have a mid-sized platform that needs to migrate. I think I'll just use valkey for caching, a caddy proxy, and some cdn, just using standard HTTP headers for cache control. Will put everything on a docker swarm cluster with 3 replicas, good enough for our size / use case.

Static rendering, ideally partial pre-rendering, is a must on our end. Thus the cdn cache, or server cache, is key.