Caching 404 fetches in the data cache.

[nickjackson]

Might there be appetite to provide an option in the NextFetchRequestConfig that allows for fetches that respond with 404 to be cached?

Use cases

Dynamic Routes

Most of the sites we build have dynamically driven pages, underpinned by some content in a CMS. We use dynamic routes to pass through the slug to the CMS which will return a 200 or 404 depending if there is content at that path or not, all pretty standard. We cache the 200, but if the response we get is a 404, no matter how many times that page is hit, it will always hit the origin and be slow. I appreciate that with this pattern of dynamic routes backed by a CMS, there is always going to be the ability to enumerate pages and hit the origin, but being able to cache the common cases helps reduce wasted round trips.

Composing content

We make use of a pattern that allows our customers to build their own template overrides in their CMS, which can change the way a piece of content is rendered based on certain signals. For example, in the case of a PDP page, we would have a default template setup in our CMS such as pdp/templates/default, but the customer could override that for a particular brand, just by setting up a new piece of content at pdp/templates/nike

We then implement the above by doing two simultaneous fetches to retrieve the default template and one based on the brand of the current product. If the latter existed we would use that instead. If the override doesn't exist, then that will 404, hit the origin, and slow down the entire page.

Workarounds

CMS based solutions

It is unlikely that the CMS would be willing to stop their pages from 404'ing, but they may offer alternative ways of fetching content that doesn't 404.

unstable_cache

This is probably the only workable solution right now, but is unstable.

Possible implementation

I'm really not tied to any implementation, but here are some ideas I have to expose this option.

interface NextFetchRequestConfig {
  revalidate?: number | false
  tags?: string[]
  includeNotFound?: boolean;
}

or perhaps

interface NextFetchRequestConfig {
  revalidate?: number | false
  tags?: string[]
  includeStatuses?: number[];
}

[dealer-solutions-gene]

I'm here because I too am building a content system, where my page routes are dynamic, and its the CMS's responsibility to respond with a valid 404 where it would be highly desirable to have the front end cache this successful transaction.