Just reading that fills me with dread
How to Inspect React Server Component Activity with Next.js and OpenTelemetry
11–20 of 52 posts
Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry
#12Earlier quoted context omitted.
how else would one reproduce a bug? in production? or is it best practice to patch with logs only without reproduction
There are often additional hints to go by, e.g., the executed network requests, the user path taken or "breadcrumbs", i.e., custom events captured. Of course that requires a certain operational maturity.
In my head that feels like triaging but idk people really be patching bugs without reproducing? That sounds crazy to me idk why
I've never worked at a place that had local dev used to think computers hated me but wondering if this is better dev practice in general
Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry
#13Earlier quoted context omitted.
Not quite sure what the big challenge is here. If the work is shifting to the server, you debug on the server! Read the logs. Attach a debugger. Instrument the code if you must! All that usual stuff. This is how web-development has been since the days of CGI. What am I missing?
And these days, you use the same browser debug tools to attach to nodejs.
For local development, yes. But I see that almost never done in production settings, especially with containerized workloads. Is there a neat way to do it in Kubernetes?
Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry
#14Excuse my ignorance but why does it look so complicated and unnecessary? What exactly does it improve over lets say PHP or Rails or whatever?
Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry
#15Earlier quoted context omitted.
There are often additional hints to go by, e.g., the executed network requests, the user path taken or "breadcrumbs", i.e., custom events captured. Of course that requires a certain operational maturity.
In my head that feels like triaging but idk people really be patching bugs without reproducing? That sounds crazy to me idk why I've never worked at a place that had local dev used to think computers hated me but wondering if this is better dev practice in general
Who said anything about not reproducing?
It just takes a lot less time to reproduce if you have some logging in production... and some people seem to believe that's not needed.
And if you have logs, you may not need to reproduce it because said logs give you all the info you need.
Disclaimer: circumstances may vary. A bug is a bug is a bug and you may solve it by reading one log line, or you may spend a week with a debugger in your development environment and it will still crash in production when you deploy the fix.
Happy now?
Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry
#16I'm really not a fan of the "what colour is your component" situation introduced by RSC. RSC is a cool feature, but I'm still not convinced that the added churn of thinking about "colours" when building components and structuring the component tree is worth it for the benefits it gives.
It’s awful and I’m pretty sad that it seems the entire nodejs community has adopted next.js as standard. All projects I’ve been involved with use it and none of them use any SSR at all.
Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry
#17I'm really not a fan of the "what colour is your component" situation introduced by RSC. RSC is a cool feature, but I'm still not convinced that the added churn of thinking about "colours" when building components and structuring the component tree is worth it for the benefits it gives.
It is a solution when all your developers are bootcamped on react for 6 months and don't know how to run a proper back-end. Managers like it because their front-end react dev can add a back-end feature NOW and in 1 hour.
Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry
#18This reminds me why I added server timing to the chrome dev tools.
The basic thing I instrumented in my projects was a count of calls to APIs and their total time. Same for DB access. Then push these out as server timings via http headers and see them in chrome.
Quick and dirty way to see what the server call was generally doing.
In addition to adding that to chrome dev tools, I had an extension that would consolidate all network requests for a given page and summarize them. Nice to show various teams how many darn db queries they were doing just to load a page.
Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry
#19Earlier quoted context omitted.
And these days, you use the same browser debug tools to attach to nodejs.
For local development, yes. But I see that almost never done in production settings, especially with containerized workloads. Is there a neat way to do it in Kubernetes?
Well, I suggest never enabling the debugger in production.
But if you meant a local or dev server where you start node with --inspect then the port to forward is 9229 by default.
Re: How to Inspect React Server Component Activity with Next.js and OpenTelemetry
#20Earlier quoted context omitted.
> Read the logs. I've noted a tendency to not log stuff in some js-first devs i know ... they all say 'i'll reproduce it locally'...
how else would one reproduce a bug? in production? or is it best practice to patch with logs only without reproduction
> how else would one reproduce a bug? in production?
I don't think they meant "either" "or". I think they meant that you should not solely rely on reproducing issues locally. If you have good logging, many times, the logs would make it apparent where the issue is. When that fails, then you resort to reproducing the issue locally.
But if an app developer never adds any logs, they would be forced to reproducing the issue locally every single time which is counter productive.
So it isn't either logs or reproduce locally. It is add logs and read logs. But also reproduce locally when you really have to.