-
Notifications
You must be signed in to change notification settings - Fork 36
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
When do race conditions actually occur? #28
Comments
Doing SSR in the App directory means essentially that your browser already starts executing your application while it is still running SSR. So imagine the following scenario: SSR: a part of your application (C1) finishes rendering. That part contained an Apollo Client instance. It will be created on the server. Now we have two Apollo Clients existing in parallel on the server (SsrAC) and in the browser (BrowserAC). Now we have a child component in a suspense boundary further down in the tree - that component contains a form to udpate the current user's first name. (C2) That data is also fetched using SSR: C2 renders We also have another component in another suspense boundary (C3). That component uses the SSR: C3 renders. It suspends for 5 seconds because this is a very slow query Of course, this is not an everyday scenario. It requires that the server renders an extremely slow query, and that the client does a request for overlapping & updated data in the meantime (probably triggered by a user interaction). But at the same time, this is a possible scenario, and we have to warn about it. |
Oh, I get it now. Thank you for such a detailed explanation, @phryneas! Have we explored the possibility to use web sockets to sync the browser instance and the SSR instance of Apollo Client? Is this even possible with Next.js, React, and RSC? If it were, we would be able to have a synced cache between them. |
Unfortunately, that's not an option - we don't have a lot of control over Next.js here. The only thing we can do is push more data into the stream, and that is also only synced to the browser whenever a suspense boundary "flushes" to the client - there is a React feature request for a |
It sounds like keeping a last updated timestamp would solve this. This issue and associated PR in the main repo might be relevant? apollographql/apollo-client#9502 |
@GeKorm Yes, having a typestamp could solve this, but it won't be as easy as the issue/PR you linked - as Apollo Client is a normalized cache, we would have to keep that timestamp metadata for every single field in the store independently, as an incoming response might be 50% "newer" than existing data, and 50% "older" at the same time. It is something we do consider, but implementing it would get close to a full rewrite of Apollo Client. |
Based on the information provided in the README:
When would such a scenario with race conditions happen exactly? Only when using
@defer
? Also, what do you mean if we're not using suspense? What will happen if I decide to wrap a component using a suspense boundary<Suspense>
or by using theloading.tsx
provided by the new Next.js app directory?What problems might occur?
The text was updated successfully, but these errors were encountered: