Why create a new Client on the fly for every request in getServerSideProps

[gszliu]

This is probably a very silly question. I'm very new to both the React and Next.js worlds. I'm building out an application with Next.js and querying a GraphQL endpoint for data, for now only on the server side (client-side in the future). I intend to make use of getServerSideProps to fetch data at the page level and compose or prop-drill as necessary to any children that need data.

In the next-urql documentation, the suggestion for getServerSideProps is to use initUrqlClient to create a client on the fly - done once per request. In the code comments:

Create a new Client for every server-side rendered request.
This ensures we reset the state for each rendered page.

Why is this necessary? Is there no value in re-using a previously created Client? If every time a Client is created on the fly, is there any value in adding in exchanges like ssrExchange, or dedupExchange? For the latter, if I understand correctly, a newly created Client would not be aware of previous GraphQL requests made by the server, and not able to dedupe.

If the above is true, is it ideal to keep the server-side Client creation in getServerSideProps as simple as possible without adding exchanges, if they don't add value?

Edit: As a follow on question, there's also this example of utilizing ssrCache and ssrCache.extractData with getServerSideProps. What is the advantage of this method over the other suggested method of creating on-the-fly Clients per request? When should I do this ssrCache.extraData methodology over the other?

Thanks in advance!

[JoviDeCroock]

The phrasing might be a bit off but we create a separate client just for the initial server-side render. This makes it so that we can do a bunch of requests on that client and it will only live in the closure of that initial data request. We should always utilize the ssrCache.extractData() method. This PR will shed more light on the different methods as next-urql has two ways of using it #1502

[gszliu]

Could answer the other, dumber questions I had regarding rendering? If possible! Noob-friendlier, the better

[JoviDeCroock]

This is what extractData does, it looks at all requests made with the cilent you used on the server-side and makes sure they're hydrated on the client. You can double check this by checking the dom-node with id="NEXT_DATA.

Basically if you fetch data on the server it's sent to that dom-node in question and the client-side cache will be hydrated with it, this means if you have a subsequent client-side transition that asks for that same data, it will not need to hit the server. Imagine it like a pipeline.

Our exchanges have dedupe --> cache --> ssr --> fetch, when we initially send this html to the client, the ssrExchange on the client will pick up the __NEXT_DATA__ dom-node and hydrate its cache and send it to the actual cacheExchange when requests come in. When the ssrExchange doesn't have the data we need it'll send it to the fetchExchange to ask for it to the appropriate server.

[gszliu]

I see, so the data hydration is useful when adding client side navigation.

Lastly, if on the server side the Clients are created on the fly per request, do they properly take advantage of the cacheExchange? e.g. for the standard document cache which I assume is all in memory. Does a freshly created client with cacheExchange get access to another previous request’s cached data on the server side?

[JoviDeCroock]

A fresh client resets its cache but there can only be one getServerSideProps for a page so it being scoped to that one ssr-iteration is all you need. i.e. Caching cross-ssr-requests and having the cache be present would risk data-leaking across users.

[gszliu]

Thanks for the explanations! It makes more sense now.