At Dragonboat we have a large React codebase. Most of it is a classic SPA — client-side routing, Redux, REST API calls from the browser. Last year we started migrating our public-facing pages and some dashboard sections to React Server Components.

Here's my honest take after 12 months.

Data fetching is genuinely simpler. Being able to await directly in a component, close to where the data is used, removes a lot of the boilerplate around loading states and effects:

async function RoadmapList({ teamId }: { teamId: string }) {
  const roadmaps = await db.roadmaps.findMany({ where: { teamId } });
  return <ul>{roadmaps.map(r => <RoadmapItem key={r.id} roadmap={r} />)}</ul>;
}

Bundle size dropped. Heavy dependencies (date libraries, markdown parsers, chart configs) that were previously shipped to the client are now server-only. Our initial JS bundle shrank by ~35%.

Waterfall requests are easier to reason about. With client components you'd fire multiple useEffect fetches that cascade. RSC makes the data flow sequential and explicit.

The mental model is genuinely hard to teach. The "which components are server vs client" question trips up everyone on the team. We've had bugs from accidentally importing server-only code into client components.

Interoperability with our existing state management is painful. Redux and RSC don't mix naturally. We ended up with a hybrid approach that feels awkward.

Error boundaries and loading states feel more fragmented. The Suspense + RSC combination works, but debugging a broken streaming boundary is not fun.

Yes — but only for the right parts of the app. RSC shines for read-heavy, data-driven pages. For interactive, stateful UIs, classic client components are still the right tool.

The migration isn't free, but the performance and DX wins on the right pages are real.

---pt---

No Dragonboat temos uma grande codebase React. A maior parte é uma SPA clássica — routing client-side, Redux, chamadas REST API do browser. No ano passado começámos a migrar as nossas páginas públicas e algumas secções do dashboard para React Server Components.

Aqui está a minha opinião honesta após 12 meses.

O data fetching é genuinamente mais simples. Poder usar await directamente num componente, perto de onde os dados são usados, remove muito do boilerplate em torno de loading states e effects:

async function RoadmapList({ teamId }: { teamId: string }) {
  const roadmaps = await db.roadmaps.findMany({ where: { teamId } });
  return <ul>{roadmaps.map(r => <RoadmapItem key={r.id} roadmap={r} />)}</ul>;
}

O bundle size diminuiu. Dependências pesadas (bibliotecas de datas, parsers de markdown, configurações de charts) que antes eram enviadas para o cliente são agora server-only. O nosso bundle JS inicial reduziu cerca de 35%.

Os waterfall requests são mais fáceis de raciocinar. Com componentes cliente, disparavas múltiplos fetches useEffect em cascata. O RSC torna o fluxo de dados sequencial e explícito.

O modelo mental é genuinamente difícil de ensinar. A questão "quais componentes são server vs client" apanha toda a gente na equipa. Tivemos bugs de importar inadvertidamente código server-only para componentes client.

A interoperabilidade com a nossa gestão de estado existente é dolorosa. Redux e RSC não se misturam naturalmente. Acabámos com uma abordagem híbrida que parece desajeitada.

Os error boundaries e loading states parecem mais fragmentados. A combinação Suspense + RSC funciona, mas depurar um streaming boundary partido não é divertido.

Sim — mas apenas para as partes certas da app. O RSC brilha em páginas orientadas a dados e de leitura intensiva. Para UIs interactivas e com estado, os clássicos componentes cliente continuam a ser a ferramenta certa.

A migração não é gratuita, mas os ganhos de performance e DX nas páginas certas são reais.