-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Problem with custom type policy for query caching #11968
Comments
I also added custom
which now utilizes unique id instead of duplicating one: now I get the following entries and references in read function:
but the issue is still in place :( |
Hi @IgorNovikov10 👋 I have some suspicions about what is going on here, but in order to properly assess I'd need to see the whole application. Could you please share a runnable reproduction? |
@alessbell The problem can be reproduced only on a deployed instance by opening two pages with the same URL but on different domains (for example: https://dev-v2.focusnordic.se/ambassadorer and https://dev-v2.focusnordic.dk/ambassadorer) at the same time and trying to switch between pages in menu and returning back to the original page. This is the only way to see how the content of one site sometimes displays on another (it's a bit tricky to reproduce it locally by running Please let me know if you still need the source code or any other snippets of the code |
What I also noticed is that sometimes according to the logs on server I don't end up in the read function when opening/switching between navigation links fast and it looks like when I don't hit this function the content of the page resolved incorrectly and randomly shows either .se or .dk version on https://dev-v2.focusnordic.dk/ambassadorer
|
Could it be that you are creating a long-living Apollo Client instance on the server? We explicitly advise against that in the docs: You risk mixing data from different users (or in your case, even sites) that should not be mixed. On the server, you should always create a new instance of |
@phryneas Hi, yep, currently I put ApolloProvider into pages/_app.tsx meaning it wraps the entire application
If I got you right, instead of this maybe worth trying to put it into [[...page]].tsx which is kind-of catch-all-routes component where I have getServerSideProps with apollo graphql queries
|
No, the problem is that you probably have a file with export apolloClient = new ApolloClient(....) That means that if your server runs for a long time, this You need a setup that creates a new Unfortunately, Vercel has already deleted all Page router examples on their end, but we still have one around that you can look up on how to do that correctly: Here is the "core" of the setup: https://github.com/apollographql/next-apollo-example/blob/main/pages/_app.js And the important part is that here, in SSR the client instance is never saved to a global variable: This page shows how to use it in |
@phryneas thanks! I can share my setup: _app.tsx
@/lib/apolloClient
And getLayoutServerSideProps function from [[...page]].tsx
|
This is your problem. You seem to deliberately sharing a cache between requests. The |
@phryneas Sure! First of all I want to cache the response for GetMenuDocument, GetMenuPrimaryDocument and GetTranslationsDocument (header and footer data basically, thate are static blocks) so as not to fetch this data every time the page changes (then the getServerSideProps function is launched and all queries executed again) and I also want to cache the page data based on page path (resolvedUrl)
which is also inside if I move the Byt at the same time I want the cache not to persist between different sites, that's why I tried to create unique cache keys based on xSite variable that I pass to query and uniquePageId for the page reference that is different for the same routes on different locales like http://site.com/test-page and http://site.se/test-page |
Yes. This is our recommendation. During SSR, every time you render, you should make all requests again. Everything else leaks private data between different visitors of your site, can cause spikes in memory consumption, will server potentially outdated data etc. etc. Apollo Client is made to exist for a long time in a browser window, not on a server. If you want to deduplicate requests on a server, you can use mechanisms provided by your SSR framework. I know that Next.js provides a fetch cache in the App router, unfortunately I cannot tell you if they provide a fetch cache for the Pages router.
If you really want to go that route (again, against our recommendation and on your own risk!), I would suggest that you create one cache instance per site instead of cramming data for all sites into one cache. |
@phryneas Maybe there is a small misunderstanding here When refreshing the page (during the first render) I of course perform queries to get data, I meant that when I navigate between the pages in the browse using next/link, I want to see the cached result when I return to the page I was already on. For this I use fetchPolicy cache-first. But when I moved the initialization of new InMemoryCache inside createApolloClient function
this cache inside the browser does not work, since once I navigated to a new page using next/link the getLayoutServerSideProps function is called again which re-initializes apolloClient
and accordingly creates a new cache instance. How can this be fixed so that the cache only works during the client session? |
Moving this into Keep in mind that there is no such thing as a "server session" in Next.js. You can have a long session in the Client, but never on the browser. It's always a new request from an unknown anonymous user. |
@phryneas yes, I think the problem is that Next js triggers the |
@phryneas |
Yes, that's how the SSR rendering in the Next.js pages router works.
No, from the moment a user opens your page in the browser until they navigate to another website or close the tab. You might see these user-side requests, but the ApolloClient instance in the browser should keep existing independently of that in your setup. You have one long-running session on the browser, enhanced over time by many short-lived sessions on the server. |
@phryneas Thanks. Do you have an idea on how to persist Apollo cache between page visits on client-side in NextJS and not to load data for the pages that have been visited before? I tried to test this example https://github.com/apollographql/next-apollo-example and it looks like during the long-running session on the browser, when navigating between pages, it still performs Apollo queries in getServerSideProps, createApolloClient and new InMemoryCache get called every time |
That is the Next.js behaviour when you use This is a feature of your framework. Next.js is geared towards SSR. |
@phryneas Thanks a lot for your help and opinion! |
Issue Description
I have a NextJS application that can have the same routes for different domains/locales for example
http://site.com/test-page and http://site.se/test-page. We send a request to the current route to get the page data in this form
In addition, we send a xSite header in the request so that the content system determines for which locale what data needs to be ssent. The problem is that if there is a page that exists on 2 domains with the same route , for example, http://site.com/test-page and http://site.se/test-page then sometimes the data that is in the cache is mixed and it happens that on one site http://site.com I see data from another http://site.se/test-page and vice versa
Also I tried to setup custom caching for the field that this query returns like this:
Can this be caused by the fact that even for different xSite the pages have the same id property in the response?
Link to Reproduction
/
Reproduction Steps
No response
@apollo/client
version3.10.4
The text was updated successfully, but these errors were encountered: