Durante uma década, o contrato do React foi um só: componentes rodam no navegador. React Server Components (RSC) quebram esse contrato pela primeira vez, e a mudança é mais profunda do que parece: componentes que executam no servidor e nunca chegam ao bundle do cliente.

O problema que eles atacam

O SPA clássico tem um imposto embutido: para mostrar qualquer coisa, o navegador baixa o JavaScript de tudo: o componente, a biblioteca de datas, o parser de markdown, o client do banco de dados que alguém importou sem querer. Depois busca os dados numa API, monta o estado e finalmente renderiza. Cada feature nova engorda o bundle de todos.

Server Components invertem: o componente roda no servidor, acessa os dados diretamente e envia só o resultado (uma descrição da UI, não o código que a gerou). A biblioteca de 80KB que formata datas? Fica no servidor. O usuário recebe HTML pronto e um bundle drasticamente menor.

// app/pedidos/page.jsx: Server Component (padrão no App Router)
import { db } from "@/lib/db";

export default async function Pedidos() {
  // async/await direto no componente, sem useEffect, sem API intermediária
  const pedidos = await db.pedido.findMany({ orderBy: { data: "desc" } });

  return (
    <ul>
      {pedidos.map((p) => (
        <li key={p.id}>{p.cliente}: {formatarMoeda(p.total)}</li>
      ))}
    </ul>
  );
}

Repare no que não existe: useState de loading, useEffect de fetch, endpoint de API só para servir esse componente. O componente é a consulta. E credenciais e lógica sensível nunca vão ao navegador, uma superfície de ataque a menos.

A fronteira: "use client"

Nem tudo pode rodar no servidor: clique, estado, efeito e APIs do navegador continuam sendo trabalho do cliente. A diretiva "use client" marca a fronteira:

// componentes/BotaoFavoritar.jsx
"use client";
import { useState } from "react";

export function BotaoFavoritar({ pedidoId }) {
  const [ativo, setAtivo] = useState(false);
  return <button onClick={() => setAtivo(!ativo)}>{ativo ? "★" : "☆"}</button>;
}

O modelo mental que evita 90% das confusões:

• Server Component (padrão): busca dados, monta a página, não tem interatividade. Roda no servidor, não vai para o bundle.
• Client Component ("use client"): tudo que tem useState, useEffect, eventos. É o React que você já conhecia.
• A página vira uma árvore com ilhas de interatividade: o esqueleto é server, os botões são client.

Duas regras práticas da fronteira: a diretiva contamina para baixo (tudo que um client component importa vira client), e um server component pode ser passado como children de um client component, o padrão para manter o miolo pesado no servidor dentro de um invólucro interativo.

RSC não é SSR (a confusão universal)

SSR renderiza o HTML inicial no servidor, mas o JavaScript do componente ainda é baixado e executado no cliente (hidratação). RSC elimina o código do bundle: o componente executa só no servidor, sempre. Os dois se combinam: server components geram a estrutura, client components são renderizados via SSR e hidratados. A documentação oficial detalha o modelo (react.dev), e na prática você o usa através de um framework: hoje, majoritariamente o App Router do Next.js (tema do próximo artigo).

Os ganhos e os custos, sem torcida

Ganhos reais: bundle menor (o ganho cresce com o tamanho do app), dados sem cascata de APIs intermediárias, segredos fora do cliente, e LCP melhor porque o conteúdo chega pronto.

Custos honestos: modelo mental novo para o time inteiro (a pergunta "isso roda onde?" vira rotina), ecossistema em transição (bibliotecas que assumem navegador precisam da fronteira certa), e depêndencia de framework/infra de servidor, com o custo de operação que renderização no servidor sempre teve.

Quando compensa: aplicações com muito conteúdo orientado a dados (e-commerce, dashboards, portais, blogs). Quando não: apps altamente interativos onde quase tudo precisaria de "use client" (editores, jogos, ferramentas de desenho): aí o React clássico segue ótimo.

A migração sensata

Ninguém reescreve o app para RSC de uma vez, e nem deveria. O caminho: rotas novas no App Router com server components por padrão, "use client" onde a interatividade pedir, e migração das rotas antigas por valor, não por ideologia.

Desenhar essa fronteira (o que roda onde, e por quê) é o tipo de decisão de arquitetura front-end que trabalhamos no serviço de Desenvolvimento Web, Mobile e Desktop.

Seu bundle está pesado demais? Descreva sua aplicação para a IA da Rabelo Digital, aqui no canto da tela, e ela avalia se Server Components pagariam a migração. Sem formulário, sem espera.

---

Leia também

• Next.js: SSR, SSG e ISR, qual renderização usar
• Redux vs Context: estado global sem dogma
• Hooks avançados: useMemo, useCallback e quando não usar