React Server Components at Scale with Aurora Scharff

🎧 New Señors @ Scale Episode

This week, I spoke with Aurora Scharff, a Senior Consultant at Creon Consulting, Microsoft MVP in Web Technologies, and the React Certifications Lead at certificates.dev.

Aurora studied Robotics and Intelligent Systems at the University of Oslo — attracted by the mix of math and software — but always gravitated toward the code over the physical systems. That pull toward frontend, driven by the immediate visual feedback of seeing something appear on screen, eventually landed her in the world of React and server components. Along the way she built a UI for Boston Dynamics' Spot robot dog, rebuilt legacy systems for the Norwegian government, and became one of the more thoughtful voices in the React ecosystem on the server/client boundary.

In this episode, we dig into how Aurora learned Angular's change detection before she even knew what preventDefault was, the specific mental model shift that makes React Server Components click, the most common mistake developers make with server-side async/await, and what the React Foundation announcement means for the ecosystem.

⚙️ Main Takeaways

1. Robotics → frontend: visual feedback wins

Aurora chose Robotics and Intelligent Systems at the University of Oslo for the math and software combination — but the physical building side never hooked her the way code did.

• The draw: The visual feedback of frontend development — "you can see something on the screen" — kept pulling her toward it even in a program that was mostly about hardware and intelligent systems.
• The path: Robotics gave her strong fundamentals, but the moment code produced something visible, the direction became clear.
• The lesson: What keeps you in a field long-term is often not the field you studied for, but the part of it that gives you the most immediate, tangible feedback.

2. Learning Angular before learning JavaScript

Her first job had her deep in Angular's change detection — specifically OnPush — before she understood basic browser APIs.

• The setup: She was writing complex Angular applications, handling component update strategies, and reasoning about the rendering cycle before she knew what preventDefault was.
• The pattern: This is more common than developers admit. Frameworks abstract the web so effectively that you can be productive — even advanced — before you understand what's underneath.
• The lesson: "I learned OnPush change detection before I even knew what preventDefault was." Eventually understanding the platform beneath the framework makes you significantly more effective — but many developers never go back to fill that gap.

3. React and the Spot robot dog controller

One of Aurora's first real React projects was building a controller UI for Boston Dynamics' Spot — the robot dog — on an experimental branch.

• The first impression: "I remember being amazed at how easy it is to just put things into the code and it just works and it just appears." The declarative model felt like a fundamentally different way of building UI.
• The reality check: She also had 15 useEffect calls in a single file on day one. The initial experience of React's ease and the eventual debugging of its pitfalls arrived at the same time.
• The context: This was an experimental branch — not shipping to production — which gave her the freedom to explore without the pressure of getting it right immediately.

4. The core value proposition of React Server Components

The main thing RSC gives you is co-location of data fetching and the components that use that data — with no separate bridging layer between server and client.

• The old pattern: Data fetching lived in a separate layer (API routes, loaders, getServerSideProps) that had to be connected back to components through props, context, or state.
• The RSC model: The component itself can be async. It fetches exactly the data it needs, uses it directly, and sends only the result to the client. Dan Abramov compares it to GraphQL — you get the exact shape for your component.
• The mental model: Think of each server component as having its own scoped data query that runs on the server. The result is a component that is always in sync with its data without any wiring code.

5. The most common RSC mistake: not understanding how blocking async/await works

Developers used to client-side patterns reach for async/await on the server without thinking about what it does to the render path — and the result is often a slower app than they had before.

• The problem: Fetching data with await in a server component blocks that component's render until the fetch resolves. Chain several of these without thought and you've created a waterfall where each component waits on the previous one.
• The fix: Understand where parallelism is possible and use Promise.all where multiple fetches don't depend on each other. Start data fetching as early as possible in the tree.
• The irony: Developers switch to RSC for performance improvements and end up with slower pages because the mental model from synchronous client-side rendering doesn't translate directly.

6. The server vs. client component decision

The right default is server-only data fetching. Break out to a client component only when you need interactivity. But it's not always that simple.

• The default: Start with server components. Most of your data-fetching, read-only rendering, and heavy dependencies should stay on the server.
• The escape hatch: When you need user interaction — click handlers, local state, browser APIs — you pull that part into a client component. The boundary should be as low in the tree as possible.
• The nuance: React Query in a Next.js app is still a valid choice depending on the feature. RSC doesn't replace every client-side data fetching pattern. Context, the feature requirements, and team familiarity all matter.

7. The mental model shift: "what even is a server, where is it"

Developers who came up entirely through client-side React never had to think about where code runs. RSC requires that background knowledge.

• The gap: SSR, request lifecycle, environment variables that should never reach the browser, data that should never be sent to the client — these are concepts that simply weren't required when building SPAs.
• The challenge: Aurora frames it as: "What even is a server, where is it." That question sounds basic, but for a generation of developers who built apps that ran entirely in the browser, it's genuinely new territory.
• The path forward: Understanding the distinction between server and client execution environments is the prerequisite for making good RSC architecture decisions. It's worth investing in that background before diving into the API.

8. The ecosystem is stabilizing — and that's the exciting part

The React community has been in a period of churn with Server Components, new patterns, and ecosystem fragmentation. That's changing.

• React Conf as the signal: React Conf in October showed all the pieces of the new React programming model coming together — not just RSCs in isolation, but how they connect to Suspense, transitions, the compiler, and the new APIs.
• The shift: "It feels like it's stabilizing, I would say. That's what's very exciting." When an ecosystem stabilizes, investment in understanding it pays longer dividends.
• The implication: This is a good time to go deep on RSC because the patterns you learn now are likely to be durable rather than provisional.

9. Microsoft MVP: recognition, community, and the process

The MVP title is primarily a recognition award for community contributions — not a technical certification and not a role at Microsoft.

• The process: 24 community contributions (talks, repos, workshops, blog posts) plus a recommendation from an existing MVP. The bar is about consistent community engagement, not a single achievement.
• The reality: It's a recognition title. Most of the value is in the community — other MVPs, the network, and the visibility the award creates.
• The Summit: There's an annual MVP Summit in the US. She hasn't gone. The day-to-day impact of the title is mostly external visibility rather than internal access.

10. On conference speaking nerves

Getting on stage is hard for everyone at the start — it just doesn't look that way from the outside.

• The observation: Experienced speakers look comfortable. That makes first-timers assume they're the only ones who are nervous, or that the nerves mean they're not cut out for it.
• The reality: "It's always hard for everyone starting out. It just doesn't look like it, right?" The nerves don't disappear — what changes is your relationship with them.
• The advice: "If you get through it, you will come out the other side better and it will be easier next time." The first talk is the hardest one. You don't have to wait until you feel ready — you get through it and then you're ready.

🧠 What I Learned

• Visual feedback is what drew Aurora from Robotics to frontend — a small detail that explains a lot about why people end up where they do in tech.
• Learning a framework before learning the platform underneath it is more common than developers admit — and going back to fill those gaps pays dividends.
• React Server Components' core value is co-locating data fetching with components, eliminating the bridging layer between server and client.
• The most common RSC mistake is treating server-side async/await like client-side code and accidentally creating fetch waterfalls.
• The server vs. client decision should default to server, with client components extracted as low in the tree as possible and only when interactivity is needed.
• React Query in a Next.js app is still valid. RSC doesn't replace all client-side data fetching patterns.
• The mental model prerequisite for RSC is understanding what a server is, where code runs, and what the request lifecycle looks like — background many SPA developers never needed.
• The React ecosystem is finally stabilizing around the new programming model, making now a good time to go deep.
• The Microsoft MVP title is a recognition award requiring 24 community contributions and a recommendation from an existing MVP.
• Conference speaking nerves don't go away, but your relationship with them changes. Getting through the first talk is the entire goal.

💬 Favorite Quotes

"I learned OnPush change detection before I even knew what preventDefault was."

"I remember being amazed at how easy it is to just put things into the code and it just works and it just appears."

"What even is a server, where is it."

"It feels like it's stabilizing, I would say. That's what's very exciting."

"It's always hard for everyone starting out. It just doesn't look like it, right?"

"If you get through it, you will come out the other side better and it will be easier next time."

🎯 Also in this Episode

• Rebuilding legacy systems for the Norwegian government
• .NET + Angular: the classic enterprise architecture Aurora encountered early in her career
• Building the Boston Dynamics Spot controller UI in React on an experimental branch
• Her path into consulting after the startup phase
• Being the React certifications lead at certificates.dev and what the certification actually covers
• The React Foundation (Meta + Vercel and others) — her honest "I don't know enough to judge yet" take
• Working in the Norwegian open source community
• Why she won't reveal what she's working on next ("follow me and you'll see")
• Sci-fi movie recommendations: Dune Part Two, Avatar

Resources

More from Aurora:

• Aurora on Twitter/X
• Aurora's blog
• certificates.dev React certification

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 52 minutes on React Server Components, the server vs. client mental model shift, conference speaking, and the path from Robotics to frontend.

If you're a React developer trying to wrap your head around Server Components, or a senior engineer wondering whether the RSC ecosystem is finally ready to invest in, Aurora's perspective — grounded in real production work and the React certification track — is exactly the kind of signal worth paying attention to.

Happy building,
Dan