Request memoization (deduping) not working properly

[ciza99]

Does anyone else have issues with this? I have created a reproduction repo: https://github.com/ciza99/nextjs-dedup-cache

1. Clone the repo
2. npm run build
3. npm run start
4. navigate to /products
5. see the console for the amount of requests made, just click around

In my case, I saw up to 4x the amount of a fetch that should be deduped though a single route render pass. With the combination of link preloading, this makes a lot of requests pretty quick. It looks like the issue happens only in a production build.

This is a big issue for me because the CMS I use has a request limit. A site that is rarely visited is racking up requests like crazy. What am I doing wrong? I am passing the Next.js patched fetch function to the graphql-request client and the revalidation timing seems to be working otherwise.

[steve-marmalade]

Have you tried wrapping your data fetching functions in cache, per https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#fetching-data-on-the-server-with-third-party-libraries ?

[steve-marmalade]

A couple of things to consider:

• The Next.js patched fetch only memoizes GET requests (per the Good to Know section of the memoization docs), so I do think that cache is necessary, given that you are using GraphQL
  • This is confusing because the fetch POST responses will be stored in the Data Cache.
• One gotcha with cache that I have personally experienced with graphql requests is that React uses shallow equality to determine if there was a cache it, whereas I was initially passing a single variables object like {var1: val1, var2: val2}.
• Finally, this is not directly related to your question, but I noticed in your repo you are making a request to Route Handler inside your RSC, which is not advised https://nextjs-faq.com/fetch-api-in-rsc

[ciza99]

@steve-marmalade
First of all, thanks for the help <3

• I did not know that the memoization only applies to GET requests, so thanks for pointing that out (I think this is the information I was missing that made this behavior confusing to me).
• I have noticed that the react cache uses shallow equality when I was testing this. That is a pain point for me because I guess I can't wrap the whole fetch in cache like this:

export const client = new GraphQLClient("http://localhost:3000/api/graphql", {
  fetch: cache(async (input: URL | string | Request, init?: RequestInit) =>
    fetch(input, {
      ...init,
      next: {
        revalidate: 5,
      },
    }),
  ),
  headers: {
    Authorization: "Bearer ...",
  },
});

And then use it like this:

const { product } = await client.request<{ product: Product }>(ProductQuery, {
  slug,
});

Because this library expects variables in an object, and I can't guarantee shallow equality for the props being passed to the fetch function anyway. Not even considering this across layouts / pages or even in the page function itself or the generateMetadata function, where I am passing a new variables object every time.

Is there an example of usage with GraphQL? Or how did you solve this?

My initial thought is to create wrapper functions like so:

const getProduct = cache((slug: string) =>
  client.request<{ product: Product }>(ProductQuery, {
    slug,
  }),
);

But my use case is a bit more complex and I don't like the idea of wrapping everything like this and also, sometimes I really do need to pass a whole object to the queries anyway.

Another thought is to create my own abstraction for the fetch function, but I am using graphql codgen and I am not sure how complicated that would be to make all things work...

• yes the repo is making a request to Next.js route handlers only to simulate a scenario, where you are calling a backend with GraphQL and to create a reproduction. I am not doing this normally.

[pepew-le-boss]

@ciza99 I have the same problem as you. Have you found a solution ?

[ciza99]

@pepew-le-boss Basically the options I know of are the ones I have written above

[pepew-le-boss]

@ciza99 I think I'll go for the wrapper function but that's very annoying to have to change all the requests of my app