next revalidate vs fetch no cache
Answered
NuclearMonkey posted this in #help-forum
When do I use one over the other? Is there a difference?
Answered by ᴉuɐpɹɐɐ
next revalidate if you want to use the dynamically fetched fucntion to persist over time
38 Replies
next revalidate if you want to use the dynamically fetched fucntion to persist over time
Answer
no cache means that everytime the function or fetch is called, it will return fresh data
even if the data doesn't change that much
@ᴉuɐpɹɐɐ next revalidate if you want to use the dynamically fetched fucntion to persist over time
what if next revalidate is 0
as seen in the docs, its the same as no-cache
which one should I use if I want to the data to always be updated. since they are technically the same if next revalidate is 0
since they're both the same its up to you
theres no difference
I personally like
no-cache since its more readablei was reading the docs, can't seem to find it, where it says its the same if revalidate is 0
thanks, one last question when using next revalidate. For example you put 5 seconds as the value. Then even 5 seconds has elapsed, you get the stale data, then after a new request you get a new data right?
yep
you got that right the first time
what if the data has updated right now. then no user has access that route for days. the server won't regenerate the ISG, only then it will regenerate if someone has access that route
what is your scenario?
haven't thought of a scenario, i was just making it solidify in my brain how it really, works. Because what i learned was that ISG gives you the stale value even if the next revalidate value has elapsed only then it regenerate after a new request then you will have the newest data on the newest request
for example this kind of scenario
I have a blog site, I have 3 blog posts the next revalidate is set to 1 hour, I updated the first blog post in the database. Making the value of the blog post outdated until next revalidates it, but only then it will regenerate if the time has elapsed and someone has accessed that route@NuclearMonkey haven't thought of a scenario, i was just making it solidify in my brain how it really, works. Because what i learned was that ISG gives you the stale value even if the next revalidate value has elapsed only then it regenerate after a new request then you will have the newest data on the newest request
You can always have on demand revalidations that rerenders ISG routes on next request
you can set it up so that for every data change (from your data source), you fire a /on-demand-revalidation to your Next.js App to invalidate the cache so that it will be rebuilt on next request
but if no one access that route for example for a long time
it wont renegerate right
yeah, thats why its only for slighly stale, auto-updating data. Not for blogposts.
For blogposts you can always fire on demand revalidation after you update your blog posts.
For blogposts you can always fire on demand revalidation after you update your blog posts.
this is a more common pattern used by CMS like contentful, and etc
how can is this implemented?
For blogposts you can always fire on demand revalidation after you update your blog posts.so when is ISG really a good use-case
i never said ISG is bad for blogposts
oh
i clarify
background revalidation is not really suitable for blogpost on which you own the data store
for that you can just use "on-demand revalidation" since you can just trigger re-render of the ISG sites directly without any "second" request -- right after updating the data
is this the right one?
yep
so basically you reserve one protected endpoint (route.js or server action or page.js, idk) and have it call revalidatePath('...')
revalidatePath(
revalidateTag(
path) -> it will revalidate any cached data inside one path pathrevalidateTag(
tag) -> it will revalidate only datas that are tagged with tag. This is more granular since you can revalidate only one piece of data, but this will still trigger rerender of any ISG route that the data is currently inthanks for the help @ᴉuɐpɹɐɐ , ill study more about the revalidationPath and Tag
No problem