How to use `export const revalidate = (a number)` with Route Handler that uses `searchParams`?
Unanswered
Rufous-winged Sparrow posted this in #help-forum
Rufous-winged SparrowOP
Hi there!
I want to cache fetch requests that are using
By default it will not cache (even with revalidate). If I add
My goal is to have a server-side cache that is short-lived (e.g. 1 hour) for such requests.
Example repo: https://github.com/rgembalik/next-js-revalidate-route-handler
The repo contains basic project with three route handlers and a short readme on how the issue can be reproduced.
Because in the final project I cannot do fetch directly (as it's wrapped in an API client library), it's highly preferred not do do it without fetch options.
I want to cache fetch requests that are using
searchParams on server-side within a route handler. By default it will not cache (even with revalidate). If I add
export const fetchCache = 'force-cache'; the cache will work, but will generate with revalidate set to one year instead of provided value. My goal is to have a server-side cache that is short-lived (e.g. 1 hour) for such requests.
Example repo: https://github.com/rgembalik/next-js-revalidate-route-handler
The repo contains basic project with three route handlers and a short readme on how the issue can be reproduced.
Because in the final project I cannot do fetch directly (as it's wrapped in an API client library), it's highly preferred not do do it without fetch options.
5 Replies
@Rufous-winged Sparrow Hi there!
I want to cache fetch requests that are using `searchParams` on server-side within a route handler.
By default it will not cache (even with revalidate). If I add `export const fetchCache = 'force-cache';` the cache will work, but will generate with `revalidate` set to one year instead of provided value.
My goal is to have a server-side cache that is short-lived (e.g. 1 hour) for such requests.
Example repo: https://github.com/rgembalik/next-js-revalidate-route-handler
The repo contains basic project with three route handlers and a short readme on how the issue can be reproduced.
Because in the final project I cannot do fetch directly (as it's wrapped in an API client library), it's highly preferred not do do it without fetch options.
route handlers using searchParams are dependent on the request they receive, hence cannot be cached
if you want to cache the return value based on the searchParams value, you probably should use fetch() or unstable_cache() with suitable tags and keys
or implement your own caching solution
Rufous-winged SparrowOP
@joulev
route handlers using searchParams are dependent on the request they receive, hence cannot be cachedThat's semi-true. Responses should not be cached statically. But I don't see a reason not to cache a fetch response in such a route, especially short-term, when we know the source of the data cannot take too much of the load and is slow. The library I am using in the final project does use fetch, so e.g.
fetchCache = 'force-cache' works. It's just not getting revalidation value as I set it in the export for the route. It's just not exposing fetch options enough for me to inject the next: {revalidate: 3600} into it.@Rufous-winged Sparrow <@484037068239142956>
> route handlers using searchParams are dependent on the request they receive, hence cannot be cached
That's semi-true. Responses should not be cached statically. But I don't see a reason not to cache a fetch response in such a route, especially short-term, when we know the source of the data cannot take too much of the load and is slow. The library I am using in the final project does use fetch, so e.g. `fetchCache = 'force-cache'` works. It's just not getting revalidation value as I set it in the export for the route. It's just not exposing fetch options enough for me to inject the `next: {revalidate: 3600}` into it.
Responses should not be cached staticallyyou have a misunderstanding here. the cache is not just the response but the entire function itself, including all fetch logic inside that function.
you use
searchParams => the function must be dynamic => export const revalidate is not available at allthe
force-cache works because it explicitly opts that particular fetch out of the dynamic rendering mechanism, but it doesn't take note of the route segment config which in the first place is for the entire route cache only and not applied to individual fetches that have had dynamicality overriden like yours. next: { revalidate: 3600 } is the only way here, and you may have to patch the library so that it allows you to add this option