Observing network requests in RSC client?

[devdumpling]

Not sure if anyone has a best way of handling this yet.

I'm trying to figure out:

1. How can I monitor actual network traffic sent from the RSC apollo client on my Next server?
2. How I can see what requests were cached (deduped?) and did not fire off network requests?

So far the closest I've gotten is tying in a link that gives me the operation.getContext() on the request and response, but I'm having some trouble parsing that. Is there a preferred method for handling this?

I'm trying to do some analysis of my pages to figure out what is actually being sent out to our graph by the Next app. Let me know if that makes sense.

[phryneas]

The problem is that even if you monitored this on an AC level, there is still the Next.js fetch cache, which on a RSC level does actually most of the caching work - in SSR, an Apollo Client/Apollo Cache instance can only ever exist for a single incoming request.

So, it might be better to monitor that Next fetch cache first and then come back to AC if additional monitoring there is even necessary?

[devdumpling]

Ah right, I should have specified that I actually disable the fetch cache completely currently (all requests are passed the no-store fetch option down from our RSC apollo client instance. In other words, we let the RSC apollo client instance handle deduping in a request, but don't actually cache requests beyond that (we're looking to, however).

We don't deploy to Vercel, and have tried to be a bit more intentional with our caching strategies than the Next defaults.

That's a helpful callout though, that once we implement our own request caching layer, it may make the most sense to simply monitor that.

It would still be helpful for debugging purposes to be able to see what is a cache hit within a request by the RSC apollo client. Not sure how feasible that is.

[phryneas]

It would still be helpful for debugging purposes to be able to see what is a cache hit within a request by the RSC apollo client. Not sure how feasible that is.

Currently we don't have monitoring like that - the best I could think of right now would be a "monitoring" link that you add to your link chain that allows you to see outgoing queries - and then you'll see which of your queries can't be served from the cache.

But generally, keep in mind: every request has a unique cache instance, and those should under no circumstances share any data with each other (to prevent leaks of user-private data), so you will only be able to deduplicate overlapping requests within the same "tree render".

[github-actions[bot]]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better.