Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adopt Caching and on-demand revalidation strategies #16

Open
asgorobets opened this issue Feb 22, 2024 · 2 comments
Open

Adopt Caching and on-demand revalidation strategies #16

asgorobets opened this issue Feb 22, 2024 · 2 comments
Labels

Comments

@asgorobets
Copy link
Collaborator

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.

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/

@asgorobets
Copy link
Collaborator Author

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.

Also, there are 64 tags maximum as of writing that can be attached to a request:
https://nextjs.org/docs/app/api-reference/functions/fetch#optionsnexttags

There are some discussions to explore here: https://www.reddit.com/r/nextjs/comments/16smmz6/optimizing_cache_invalidation_in_nextjs13_seeking/

@asgorobets
Copy link
Collaborator Author

Glad we waited, we'll have to use Next 15 for anything caching =)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant