We have no knowledge of what happens
We have no knowledge of what happens when Next.js builds your application, so I don't think it would really be possible for us to do that
4 Replies
Right, so my mental model wasn't quite right regarding that..
I expected that when setting things up so that KV handles the next.js automatic cache of data, it would be also used at build time.
This comment by vercel's VP of developer experience made me think that build and server rendering would both have access to the cache.
Do you know if that is a limitation /difference of Cloudflare's implementation of that caching behaviour? Or rather simply a misunderstanding on my part?
Reddit
lrobinson2011's comment on "Next.js Data Cache vs Vercel Data Cache"
Explore this conversation and more from the nextjs community
So our implementation is of their fetch cache, so it's an implementation of what happens when you make a fetch request and what they would do with that request. Our implementation is only present when it's running in the worker we've built for your app. Also a slight aside, but it wouldn't really be possible for us to access your KV at build time, and if we sent the data to runtime and got it cache it on the first run of a new deployment, well, it would be almost impossible for us to track that
Right. The cache he's referring to is indeed what happens when fetch requests are made, but if at build time the worker is not yet available that makes sense it won't work the same in CF.
"it wouldn't really be possible for us to access your KV at build time", does that mean that we have no way to use data stored in KV to build static pages? Or were you specifically talking about the KV that is used for the Suspense cache?
I get the bindings to KV, D1, R2 and etc are primarily for use with workers, but not being able to access data we'd store in one of them to build some of our static pages breaks a lot of use cases I thought were possible 🤔
Both. The build happens by Next.js in a Nodejs environment, not workers where you would be running the worker when you have access to the bindings. It's probably not helped by the fact that routes running in the Nodejs runtime and routes running in the edge runtime both do different things for the fetch cache. ours works by intercepting fetch requests that happen at runtime for the fetch cache in the edge runtime. in nodejs they don't use fetch requests to interact with the fetch cache