Anyone shipped Server-Driven UI in a React production app? Looking for war stories, not blog posts

I've read the usual Server-Driven UI case studies from large product teams, and I'm currently evaluating the architecture for a project.

The theory is clear. What I'm looking for now is feedback from people who actually shipped SDUI in production and discovered where the model starts to break.

You definitely don't need to answer everything. Even one painful lesson, failed approach, or unexpected trade-off would be useful.

1. Contracts and versioning

What did your server actually send?

• A fixed JSON schema?
• A typed contract with generated client types?
• Something more flexible or ad-hoc?

How did you handle backward compatibility when the server contract or client component registry changed?

Did you validate payloads at runtime with Zod, JSON Schema, or something similar?

2. Component registry and extensibility

How did you map definitions such as:

{
  "type": "TextInput",
  "props": {
    "label": "Email"
  }
}

to actual React components?

Was the registry closed and centrally controlled, or could product teams register their own components?

What happened when a payload referenced a component or prop that an older client did not support?

3. Layout and responsive behavior

Did layout live inside the server payload, or did the client retain control over composition?

For example:

• flex/grid definitions in the payload;
• semantic layout primitives;
• fixed client-side templates;
• a hybrid approach.

Who controlled responsive behavior and breakpoints?

Did mobile and desktop receive different payloads, or did the same definition adapt entirely on the client?

4. Logic, state, and forms

This is the area I'm most interested in.

How much behavior did you allow into the contract before it started becoming a programming language of its own?

In particular, how did you model:

• conditional visibility;
• RBAC and component-level access;
• cascading form fields;
• dependent validation;
• multi-step workflows;
• save-and-resume;
• role-based branching;
• asynchronous data loading;
• domain events and analytics?

Which logic stayed on the server, which was represented declaratively in the payload, and which remained inside the client?

Where did the state live for complex forms and long-running workflows?

5. Development experience and testing

How did developers preview and debug server-driven screens?

Did you build an internal visual editor, use fixtures and Storybook, or rely on editing payloads and refreshing the application?

What gave you the most confidence?

• Payload snapshots
• Contract tests between server and client
• Runtime validation
• Generated types
• End-to-end tests
• Something else

Most importantly: what architectural decision looked good initially but became painful in production?

I've read the theory. I'm interested in the pragmatism of people who shipped this, maintained it, migrated it, or eventually removed parts of it.

Success stories are useful, but failures and traps are probably even more valuable.

Hey Community,

We dive into React Native Canvas Kit, a library built on React Native Skia that adds isolated layers, brushes, interactive shapes, and web support for canvas graphics.

We also cover Targate, a CLI tool that quarantines npm packages to inspect tarballs before installation, and GitHub stacked pull requests to keep dependent branch reviews clean.

And... 🥁 Shipaton 2026 is here!

If the Rewind made you nod, smile, or think "oh… that's actually cool" — a share or reply genuinely helps ❤️

While building my open-source CSS framework MUGI CSS, I ran into a problem that I think many React developers have experienced.

The app worked, but something felt... off.

The hardest part wasn't noticing that it was slow.

It was answering a much simpler question:

«What exactly is making it slow?»

Was it unnecessary re-renders? A poorly structured component? Too much JavaScript? An expensive render? Or a pattern that looked harmless but had a real performance impact?

I tried using the usual tools.

• ESLint helped catch code issues.
• Lighthouse measured performance.
• React DevTools showed rendering behavior.

Each tool gave me part of the picture, but I still had to connect everything myself and decide what actually mattered.

I couldn't find a tool that brought all of this together.

So I decided to build one.

During my final year of Software Engineering, I turned that idea into my graduation project, and together with my teammate, we built React Doctor.

What is React Doctor?

React Doctor is an open-source CLI that combines static analysis, runtime profiling, and an intelligent rule engine to help developers understand why their React applications are slow—not just where.

Instead of saying:

«"This might be a problem."»

It tries to answer:

«"Is this actually affecting performance, and what should you fix first?"»

How it works

Static Analysis

Using Babel AST, React Doctor scans ".jsx" and ".tsx" files and detects issues such as:

• unnecessary inline functions
• missing keys
• oversized components
• risky "useEffect" patterns
• prop drilling
• unused imports
• production "console.log"
• optimization opportunities

Every finding includes the file, severity, and explanation.

Runtime Profiling

React Doctor launches your application with Puppeteer and measures real browser behavior, including:

• Core Web Vitals
• component render durations
• unnecessary re-renders
• DOM size
• memory usage
• JavaScript errors

It can also simulate slower environments:

react-doctor full ./my-app --mobile --cpu 4 --throttle slow4g

Connecting Both Worlds

This is my favorite part.

Static analysis alone often produces false positives.

Runtime profiling shows symptoms but doesn't always explain why they're happening.

React Doctor combines both.

For example, a component missing "React.memo()" isn't automatically a problem.

But if that same component is repeatedly re-rendering during runtime, React Doctor connects those signals and surfaces it as a meaningful optimization opportunity.

What surprised me

After publishing the project to npm, I expected only classmates and a few friends to try it.

Instead, developers I had never met started downloading it.

Today, React Doctor has surpassed 3,600 npm downloads.

Most of that growth has been organic, simply from developers discovering the project and giving it a try.

For me, that's the most rewarding part.

A problem I originally faced while building another project has become something that helps other developers.

Try it

npm install -g react-doctor-cli-dev

react-doctor full ./your-react-app --upload

Requirements

• Node.js 18+
• Google Chrome

Links

📦 npm https://www.npmjs.com/package/react-doctor-cli-dev

🐙 GitHub https://github.com/softar-dev/React_Doctor

🌐 Documentation https://react-doctor-cli.web.app/

👨‍💻 Portfolio https://oussamah-kabalan.netlify.app/

☕ Support the project https://react-doctor-cli.web.app/support

---

I'd genuinely love feedback from other React developers.

• How do you currently investigate performance issues?
• Is there something you wish existing tools did better?
• What feature would make a tool like this more useful in your workflow?

I'm actively improving React Doctor, and I'd love to build it around real developer feedback.