| slug: | react-server-components-one-year-in |
|---|---|
| date: | Jan 15, 2026 |
| readTime_en: | 8 min read |
| readTime_pt: | 8 min leitura |
| title_en: | React Server Components — one year in |
| title_pt: | React Server Components — um ano depois |
| excerpt_en: | We migrated part of Dragonboat to RSC last year. What worked, what didn't, and whether I'd do it again. |
| excerpt_pt: | Migrámos parte do Dragonboat para RSC no ano passado. O que funcionou, o que não funcionou, e se voltaria a fazê-lo. |
| tags: | React, Frontend, Performance |
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:
```tsx async function RoadmapList({ teamId }: { teamId: string }) { const roadmaps = await db.roadmaps.findMany({ where: { teamId } }); return
- {roadmaps.map(r => )}
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.