Expose whether fetch cache was HIT, MISS, etc. when using App Router
#55968
Replies: 4 comments 3 replies
-
|
Should be useful |
Beta Was this translation helpful? Give feedback.
-
|
In next.config you can set |
Beta Was this translation helpful? Give feedback.
-
|
This isn't what the proposal is about, and the idea acknowledges there is already a way to see the logs of what is a cache hit or miss. |
Beta Was this translation helpful? Give feedback.
-
|
According to the Next documentation this only happens in development (https://nextjs.org/docs/app/api-reference/next-config-js/logging). We would also like to see it in production |
Beta Was this translation helpful? Give feedback.
-
|
You can already see cache hits or misses in production as logs right now. If you can't then you need to figure out how to do this with your host provider. It already works by default with Vercel. This feature request is not about the ability to see logs. It is about the ability to dynamically react to a cache hit or miss in code. |
Beta Was this translation helpful? Give feedback.
-
|
Another use case for this kind of functionality: Let's say I have a route endpoint that returns soccer game data for a league. I pay for this data from a provider, so being able to effectively cache my usage of this data is extremely important to keep my costs down. Most of the time there are no games happening at all, and I would like to have a very long cache time on this particular endpoint. However, during games, I might want to have the cache for this endpoint only be 60 seconds or less. Ideally I could set the invalidation to be dynamic where it was either Right now, I might potentially be able to do something like this with three different endpoints... one control endpoint that has no cache and would pull from either a infinite cache endpoint or low cache endpoint. If the call to the control endpoint calls the infinite cache endpoint and determines that the start time for the game has come, it would then call the low-cache endpoint and return data from there, and continue to call from there until the low cache endpoint indicated that the game has concluded, at which point the control endpoint would do a revalidate call to the infinite cache endpoint and shut things off. Ultimately, the code between the two underlying endpoints would be EXACTLY the same other than their cache settings. It would make more sense to be able to set the invalidation or cache strategy dynamically from one endpoint. |
Beta Was this translation helpful? Give feedback.
-
Goals
fetchcall was cached or not via "Fetching Data on the Server with fetch". Currently there's no way to know if the response provided was a cached value or not.Non-Goals
Background
On first update to
13.4.xand playing around with the App Router, I found the logging output for server fetch requests that said "HIT" or "MISS" for the cache to be very helpful, however as far as I can tell there's no way to actually pull that information into the code (via headers, etc.). Not only is there no way to do that (that I know of), after13.4.12the logging has also been removed, so now there's no way to see if a request is using cached data or not. It seems like this should data should be exposed in some way, and it'd be very helpful if it was!Proposal
Return the caching state with the
resobject returned viafetch, perhaps as a new property or new header, as well as allow logging of cache state to be shown again if desired.Beta Was this translation helpful? Give feedback.
All reactions