How to Inspect React Server Component Activity with Next.js and OpenTelemetry
dash0.comExcuse my ignorance but why does it look so complicated and unnecessary? What exactly does it improve over lets say PHP or Rails or whatever?
Truthfully, this was never necessary. It was sold to the industry by the merchants of complexity.
You can just have a HTML file with an SPA that calls API. This is fine.
Indeed. "Oh but SPAs are so complex!" Folks are completely and utterly brainwashed by Vercel's marketing.
Pondering an SSR rendered SPA with a wildcard route that calls `React.renderToPipeableStream` (or even simpler, uses `react-streaming`) and some `import()` statements sprinkled about, dropped into a tiny vite config: OMG! a handful of lines of code. Such complexity! Such slow performance! and massive bundle sizes!
Capture the market, complexify everything, then overcharge for hosting. Thanks Vercel. Love your docs!
> What exactly does it improve over lets say PHP or Rails
Uses the same code to render on server and in browser, enables moving render logic from browser to server and vice versa without doing a complete rewrite.
Not very DRY.
Arguably more.
Why? lol
So that the page is already rendered upon the initial contact from the server, decreasing page load latency.
That is greatly compensated by the low quality of the generated code. Vercel's landing page for example takes 12 seconds and 1.4mb of files to load just a bunch of text.
Difficult question to answer because it's difficult to know what you're asking. What is "it" here? Next.js? OpenTelemetry? This specific implementation?
PHP is a programming language, Rails is a framework. They're quite different propositions. What you're seeing here is equivalent to poking around in the guts of Rails, which assuredly has plenty of complexity hidden inside it. I personally have a negative reaction to this amount of stuff in a project but I feel similarly about Rails.
Next’s big “thing” is one codebase that runs both on the server and client. That introduces complexity where you might not expect it. But a Rails app and a totally disconnected JS front end will also introduce complexity, just a kind you’re more familiar with.
on next.js first page loads are almost instant for very complex sites with very little work on the optimization side.
it's an incredibly polished server and it does a lot of complex stuff to be so fast, but it's also well documented.
It's far too much magic for my taste. I'm really looking forward to the first non-beta release of Tanstack Start. It offers many of the same advantages without the overkill.
I don’t think this answers the parent question. Database queries still needs to be made and a view still needs to be rendered. What complexity does next.js solve?
Shamelessly stollen from another comment here:
> Uses the same code to render on server and in browser, enables moving render logic from browser to server and vice versa without doing a complete rewrite.
However, the next question is, does it solve these without adding needless additional complexity of it's own?
I can't help but feel, while I'm using it, that surely it shouldn't feel this overengineered and unintuitive. I mean, I like React, and I understand it well, footguns and all.
I feel like there might be better solutions out there - even using React - and if it wasn't being heavily promoted by a large corporation then something else would be in it's place.
Also, how much of the functionality of Next.js (Image component processing, for example) is designed to funnel you into using Vercel rather than being genuinely the best solution?
> What complexity does next.js solve?
in our case it solves performance, it actively keeps cache warmed up preventing it from ever serving a stale page or serving a non cached hit, preloads content for fast navigation, optimizes images, it's lightweight, scales horizontally, it's stable.
it has all the bells and whistles the big boys have, for free, you almost don't need to think about it, just follow some guidance.
while people say it's too much magic (there are 4 cache layers), you are always free to pop up the hood and read the documentation, which is excellent.
Because that's the only way a VC-backed cloud company can make shitload money
I'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.
My experience is that even seasoned frontend devs get confused about what happens where and for what reason.
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.
That's mostly because `create-react-app` was abandoned. There is no default project template for React SPA, so everyone just uses Next, even if they don't need SSR.
But this works fine, I use it for all my side projects: https://vite.dev/guide/#scaffolding-your-first-vite-project
Add in tailwind and a router of choice (I love wouter) and you've got 90% of what you need to build most applications. Vite is so much simpler than webpack and the rest that came before, it's a tiny amount of work to do this.
I didn't know create-react-app was abandoned. What was wrong with it?
Nothing, it just required resources to maintain, which Facebook doesn't want to dedicate.
That's the naive answer. I don't think the promotion of Vercel in React docs and the discontinuation of create-react-app are unrelated.
vite exists? what are you even talking about
A lot of things exist. But to become a go-to standard a good timing is required. Next.js was getting popular right at the time Facebook abandoned 'create-react-app' template, and many people adopted Next.js even if they didn't need SSR. Vite didn't exist back then.
It adds notable complexity, and I sense that the whole server/client side component reality is wildly ill-understood.
Great write up. We’ve migrated to NextJs App Router where I work. While RSCs introduce a certain level of complexity, we’ve appreciated their benefits. The telemetry on the backend is something we’ve been looking to improve, and there doesn’t seem to be a lot of info out there, so this helps.
Glad you find it useful! :)
Just reading that fills me with dread
This 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.
I hate RSC so much. Most hated technology of them all. And this very helpful / necessary blog post is infuriating, given that not so long ago the entirety of the react stack was capable of being held in one's head. It took very little expertise to make something that worked perfectly fine for most users.
Those days are gone. Scale your Next.js RSC app to anything larger than a toy or marketing site and get f'ing burned.
Just got handed a next app that is currently just beyond toy stage. In what way am I about to get burned? Genuinely curious for opinions
Well, to start with, you'll need to study this dreadful blog post on inspecting RSC activity. And then read this: https://www.comfydeploy.com/blog/you-dont-need-nextjs
Are you using the pages router or the app router? If you're using the pages router you'll probably be fine.
I’m not sure if it’s still the case, but I remember people being incensed at next.js’s overly-aggressive caching. Might want to google for those GitHub issues and see if it’s still relevant.
Yeah I have to agree. It’s funny Next.js is so convincingly sold to beginner devs as an easier solution than SPA + any backend.
When it works, it really is easy. But when it doesn’t work, it is absolutely infuriating. Too much magic going on, I guess.
A couple months ago, I was still under the impression that next.js is the easiest way to scaffold a simple site. I even tried hosting it on vercel for ultra-easy mode.
I got some inscrutable build errors that had like the thumbs-ups on an unresolved GitHub issue. So I tried running it from a VPS I already had, and it worked fine!
I would absolutely not use it again though. Vite is great, and if I need SSR at any point I’ll just hope that the tanstack SSR solution is 1.0 by then lol
Web browser developer tools are incredible, but what do you do when more of your work is shifting to the server? These tools are no longer available or only provide minimal insights. Bye-bye network tab and source tab! That's a challenge for developers adopting React Server Components (RSCs).
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?
> 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'...
Ok genuine question, since I feel like I’m using logs wrong:
How much stuff do you log in the server? I’ve only ever seen devs log basic high-level stuff. But to actually debug something, you need way more information.
I’ve tried sticking debug-level logs that log all sorts of business logic. Pretty much recreating what you would do with console.log when trying to isolate an issue locally.
But then you have your code permanently littered with debug log lines! It makes things… ugly!!
If you NEED detailed logging, do you just deal with the uglified code? Or is there a better solution? Decorators that logs parameters and such automatically??
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.
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?
What's missing are the summaries that web developers are commonly used to. For example, the network tab in the developer tools. It is arguably very handy for development – and often more actionable than having to step through individual requests.
But you are of course also right that you can just attach a debugger. That's also called out in the article.
And these days, you use the same browser debug tools to attach to nodejs.
Yes, but it's missing the network tab, see https://github.com/nodejs/diagnostics/issues/75
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.