I think something like “an integrator’s guide to RSC” that basically described how a Next.js-like framework would have integrated it would have been great. Less-so React internals documentation and more so the seemingly private APIs that only exist for Next.js.

Pushed only in the sense that the first recommendation by the React docs is to use RSC with App Router.

And +1 I don’t think it made sense for documenting internals before. With the increased surface area what’s internal to React has grown, and it might be time to revisit that idea.

Maybe my issue is with my perceived maturity of RSC compared to how much it’s being pushed? I’m just having a hard time taking a foundational bet on undocumented and mostly-impenetrable architectures.

No disagreement there’s a place for experimentation and fast iteration. The point where I thought technical documentation into the protocol was warranted was once it became the default recommendation of React. React’s first recommendation is the Next.js App Router, which necessarily uses RSC.

Something like this was bound to happen eventually when so few people understand how the protocol and technology actually work. Not enough public eyes on it to point out potential bugs. With the expanding scope of React I don’t think black box development that worked at FB is feasible anymore.

In general, I think not having clear on docs on the protocol or how RSC works under the hood has been a huge miss for the React team. It’s hard to advocate for something or dive deep when even the most technical people know your product team can only explain it as “bundler magic”.

Enterprise Engineering at Meta is a lot closer to internal IT than product development. And it’s not exactly like an SRE either, that role exists as a Production Engineer.

Relay is like React for data, with GraphQL being its JSX. It’s such a brilliant idea, but historically has been difficult to integrate, and requires GraphQL buy-in. But the payoff is huge, and is one of the few ways to build an app at scale.

So what does Relay give us if we accept its programming model?

A consistent, denormalized, and cache-aware data store that powers every view in the app. No more stale views, SWR-style caching by default, and integrated state management.

This is similarly achievable with server component apps by wrapping your client components with simple server components that just fetch data, but by being flexible we lose the performance and caching guarantees that Relay gives us.

It’s the technical backing that makes data composable like React components in a performant way. Relay components specify data in the abstract, allowing their parent components to either compose that into their own fragment, or fetch it themselves.

GraphQL on the other hand is a language that encodes data requirements outside of the context of your application, and makes it statically analyzable. The key is that in a GraphQL app you can discover what data you need before you even start rendering.

As your rendering server components you can find lots of awaits, uses, etc. that are somehow fetching and transforming data, with many definitions of what data is. Notably you _must_ render to discover these data requirements, making your root component the “data specification”.

Come talk to us in the EDHTop16 discord and we can help you out! discord.gg/fJ8dnrUf

Isomorphic SSR, intentionally avoiding RSC.

For cases where we don’t want to compute the HTML in the React code, we’ve just been adding it to our GraphQL responses and it’s worked out fine. It’s been years and I’ve still never seen a good case for RSC compared to proper API design.