Approximating browser "Network tab" request-debugging experience with Server Components

[nervestaple]

I'm enjoying the experience of RSC so far, but from the POV of the rest of my team (non-FE developers), their experience has been negatively affected. Previously they could inspect and debug API calls, even in production, using the Network tab of their browser debugging tools. Now, many those requests are being made in server components, making them completely invisible from the client side, leading to frustrating experiences.

We use Render.com for deployment, and there is some logging i've added on each network request, but in production, especially with many simultaneous users, all the requests become interleaved and picking out individual ones becomes tricky.

Does anyone have any recommendations for tooling or process changes that would make debugging easier for them? Ideally it would approximate the experience of using the Network tab.

Is there a way to get Sentry to do something like this? I have the default Sentry logging setup but it seems focused on errors.
Another idea I had was pushing fetch results & errors to client components using props, and logging them there -- but that's a lot of annoying manual work for each request.

[elie222]

Create a function to make the network requests and whenever there's an error in a request send it to Sentry.

Something like:

function apiCall(url) {
  try {
    await fetch(url);
  } catch {
    if (error) Sentry.captureException(error);
  }
}

// And then call this where you need it:
apiCall(url);

I wrote this on the fly so use it more as pseudocode than a working example.

[icyJoseph]

For cases, where you cannot use the React Dev Tool Browser extension, the React Dev Tools has a package you can install, and then in your app you put a script pointing to a given port.

• https://www.npmjs.com/package/react-devtools

When your app runs you can see your app in the React Dev Tools, not in the browser, but in a system application window.

Why do I bring this up?

Well, what if we use a MSW like stack, which intercepts requests, and loads a GUI, where we can see the network traffic?

And of course this would run on dev mode only, and be plucked out of the production bundle.

[elie222]

maybe the answer is "change those expectations -- it's not possible any more" but one must admit it's a bit frustrating! my team (who are mainly non-FE devs) only knows their experience when debugging has been degraded and they don't understand why we're using RSC now.

If the performance benefits are not helpful and you prefer the better debugging experience, then keep your code as it was. No one forcing your team to server side render.

[nervestaple]

maybe the answer is "change those expectations -- it's not possible any more" but one must admit it's a bit frustrating! my team (who are mainly non-FE devs) only knows their experience when debugging has been degraded and they don't understand why we're using RSC now.

If the performance benefits are not helpful and you prefer the better debugging experience, then keep your code as it was. No one forcing your team to server side render.

I agree, this is the current trade off. our code in question was never client fetched, so there's nothing to return to "as it was" (we would just need to move all the calls to the client and adopt a data fetching library, rework all our loading states from app router, etc -- a lot of work!)

I'm just saying the expectations of many developers that have worked on teams developing web apps involve the "network tab" as an integral part of their workflow.

it doesn't seem unreasonable to ask if people have figured out (or are figuring out) ways to have both the traceability of client fetching while still continuing to use RSC.

there are benefits to developing with RSC that aren't immediately apparent to "outsiders" that aren't just performance, as well! "don't use it" is an answer, but I wonder if we can do better than that?

[nervestaple]

For cases, where you cannot use the React Dev Tool Browser extension, the React Dev Tools has a package you can install, and then in your app you put a script pointing to a given port.

• https://www.npmjs.com/package/react-devtools

When your app runs you can see your app in the React Dev Tools, not in the browser, but in a system application window.

Why do I bring this up?

Well, what if we use a MSW like stack, which intercepts requests, and loads a GUI, where we can see the network traffic?

And of course this would run on dev mode only, and be plucked out of the production bundle.

I'd love something like this! I know next also has a way to attach the chrome debugger, I wonder if we could do something similar for debugging network requests that occur on the server.

[icyJoseph]

Yeah, the thing is that debugger has been on and off:

• Fix NODE_OPTIONS='--inspect' not running expected #51467
• [NEXT-1179] Chrome dev tools debugging #48767

I think that a simple, GUI that you bring up on dev mode, to see network traffic might be best.

I also don't like that the console logs this for my requests:

-  ┌ GET / 200 in 24ms
   │
   ├──── POST https://api.github.com/graphql 200 in 1ms (cache: HIT)
   │
   ├── 1 level ── GET https://api.fitbit.com/1/user/-/profile.json 200 in 0ms (cache: HIT)
   │
   ├── 1 level ── GET https://api.fitbit.com/1/user/-/activities/hea.. 200 in 0ms (cache: HIT)
   │
   └── 1 level ── GET https://api.fitbit.com/1/user/-/activities/lis..?beforeDate=2023.. 200 in 0ms (cache: HIT)

That /activities/hea.. is not very useful, same with /activities/lis..?beforeDate=2023.. 200

[joeshub]

following

[matthova]

It looks like theres a product that solves this but +1 I'd love to see this tooling baked into the developer experience