BWhy are you using pages instead of the app router?
AHaha. Overloaded terms. I'm using cloudflare pages and nextjs app router
AI'm not using nextjs pages directory
BOhhhh hahahah, I think it should work
Bwhen or why do you need to revalidate every day?
ASo I'm pulling content from a CMS (directus). For some reason right now it's not pulling new content even if I rebuild on cloudflare... That's the biggest issue.
BHave you looked at a binding?
AI can replicate this problem locally and fix it by deleting my .nextjs directory
AA binding?
BDo you build staticly?
ANo. I use cloudflare-on-pages. Some of the site isnt static
B
BThis is what I meant its a deploy hook instead of binding lol
AOh. Yes.. I can do that. But it's not refreshing my content somehow.
Aif i do a run fetch with no-cache, the content is updated..
BAh then you should do edge routing I think
AThink I just need to understand how server side caching of (fetch) works in nextjs on cloudflare pages.
JYou can use
{ next: { revalidate: ... } }It should work
Anot familiar.. investigating
Awhere does that go?
Aoh as part of the fetch call..
JYeah like in the docs you linked
AWhen you opt for a route to be revalidated on an interval (export const revalidate = 10;), looks like you can just set it for the page.. thats interesting
JYeah. Tbh I've never tried the page level one before
Ai wish i understood the wizardry cloudflare is doing to make this work.. like how is it caching this info without keeping it running like in node
JRegarding fetch request caching in next-on-pages, we store the response in the workers cache API (this is configurable) when nextjs asks us to, and retrieve data from the cache API when nextjs asks us to. Obviously there's more going on under the hood, but that's the very simple explanation
Aoh, maybe this doesnt work..
AYeah you can't use revalidate with next on pages
JAh I guess they might not forward a page level revalidate to fetch requests.
Aask me how i know - 3 days wasted on it 
JThe fetch request revalidate option works though
AI'll need to figure out how to wire that in.. (I'm using a GQL wrapper lib over fetch)..
Ais there an easy way for me to get at the workers cache? to flush it or similar?
Ait seems.. hidden with CF pages..
Ai seem to have some data surviving between builds..
JYou can use revalidatePath / revalidateTag to trigger a revalidation for the fetch requests or all fetch requests under a route. That will be the on-demand revalidation section in the docs
Aoh. but nothing in the cloudflare console i can use to peek or destroy
JYou could add an API endpoint that you call that triggers the revalidation and is authenticated with a secret. Maybe a way to set it up to be automatically called on a successful deploy. Not sure.
Aooh this might work better than the rebuild thing i'm doing..
JI would also assume clearing your zones cache would clear the cache API but I may be wrong
JMy personal opinion would be to have your data fetched from the CMS and have the fetch request set to revalidate on an interval, then when the CMS makes a change, trigger a revalidate for that route. Ideally your CMS would let you do something like a webhook or http call on a publish to trigger an endpoint that can clear the relevant route.
JBut I don't know how things would specifically work with your cms
JOr your use case with the cms
Ayea i'll have to peek and see.. i wonder if this triggers a re-run of
generateStaticParams as wellJNah, that's just a build time thing
Aso that's really just a way to create some pages buildtime?
A(this is the thing thats actually breaking on me currently) tho your ideas are pretty solid
JYes generateStaticParams is supposed to be used for SSGing routes at build time