You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is likely less of a priority if we have mostly static content, and ISR (5 minutes for examples) are pretty effective ways to achieve revalidation, but there are cases when we do need to evict cache for something long term. Especially in App Router scenarios.
A few scenarios:
Layout does it's own data fetching and we cache the response in NextJS Data Cache (fetch cache). We could probably do 5 min ISR here as well, but arguments could be made for Layout relivadation to be longer
With more ability to do data fetching from React, there will be more usage, and this can bring serverless function calls to a new level. If we wanted to minimize serverless calls, we would have to rely on things to be cached for longer
On demand revalidation requires ability to set "next" property on Fetch, or wrap a response in https://nextjs.org/docs/app/api-reference/functions/unstable_cache. For this reason, we're dependent on the decision in #13. If it's a library with no support for fetch props, then it's unstable_cache.
Few considerations:
On demand revalidation is not straight forward, as object dependencies are not properly tracked in contentful. If a menu item webhook was triggered, there is no easy way to know what it affects in the UI, hence the tagging and invalidation falls on the shoulders of the frontend
Tags invalidation is cool, but ideally the invalidation should be hierarchical, where we can invalidate all menu calls at once. Sometimes this means we have to assign many tags, like menu menu:main menu:footer and sometimes they get collected by a single layout showing many tags. It would be great to have a way to merge and derive dependent tags via standard library. Think Drupal's cache tags system where each entry has cache tags, but when we render the entry, all cache tags of this and dependent (rendered) entries are collected.
Addition of tags to fetch requests is now possible with #35, but we should still explore granular cache tags and longer cache lifetimes with webhooks-style invalidation in this ticket. My inclination is that managing it with webhooks or even App Framework App Events is going to be very custom and not worth the effort for majority scenarios, but it will be good for certain one-off scenarios like menu or some specific feature tied to specific content types.
This is likely less of a priority if we have mostly static content, and ISR (5 minutes for examples) are pretty effective ways to achieve revalidation, but there are cases when we do need to evict cache for something long term. Especially in App Router scenarios.
A few scenarios:
On demand revalidation requires ability to set "next" property on Fetch, or wrap a response in https://nextjs.org/docs/app/api-reference/functions/unstable_cache. For this reason, we're dependent on the decision in #13. If it's a library with no support for fetch props, then it's unstable_cache.
Few considerations:
menu
calls at once. Sometimes this means we have to assign many tags, likemenu menu:main menu:footer
and sometimes they get collected by a single layout showing many tags. It would be great to have a way to merge and derive dependent tags via standard library. Think Drupal's cache tags system where each entry has cache tags, but when we render the entry, all cache tags of this and dependent (rendered) entries are collected.NextJS docs to reference: https://nextjs.org/docs/app/building-your-application/caching#fetch-optionsnexttags-and-revalidatetag
Contentful article for reference: https://www.contentful.com/blog/integrate-contentful-next-js-app-router/
The text was updated successfully, but these errors were encountered: