Por que continuo escolhendo Next.js para produtos que precisam durar

Muita gente acha que escolho Next.js porque é popular. Não é isso. Escolho para produtos que precisam sobreviver a cinco anos, três times e pelo menos um pivô, e o motivo é estrutural, não modismo.

Já revisei centenas de bases de código construídas em frameworks que eram a escolha certa no primeiro dia e um passivo no segundo ano. O que mata esses projetos não é o framework. É a cola: o pipeline de build customizado, a camada de data fetching feita na mão, as convenções de roteamento que só o autor original entendia.

Um caminho de requisição, um dono

O que eu realmente quero de um framework web é que um único engenheiro consiga seguir uma requisição do navegador até o banco e de volta sem trocar de repositório, de linguagem ou de modelo mental. O Next.js com App Router me dá isso. Uma página é um Server Component. Ela pode ler do banco diretamente, sem camada de API no meio, e entregar props serializadas para as partes do cliente que precisam de interatividade.

Isso elimina uma categoria inteira de bugs que eu encontrava em auditorias: frontend e backend discordando sobre o formato dos dados. Quando os dois vivem no mesmo programa TypeScript, o compilador pega a discordância antes do usuário.

Server Actions fazem o mesmo para mutações. Um formulário submete para uma função que roda no servidor, tipada de ponta a ponta, sem route handler para manter sincronizado. Eu ainda trato cada action como um endpoint POST público, porque é exatamente isso que ela é, e valido a entrada como tal. Mas o encanamento sumiu.

Padrões que envelhecem bem

Os defaults importam mais do que as features. Desde o Next.js 15, chamadas de fetch não são cacheadas a menos que você peça. Páginas são dinâmicas a menos que você opte pelo cache com uma diretiva explícita. Esse é o default correto para um produto que muda, porque dado desatualizado é um bug que você não consegue reproduzir, e um cache surpresa é o pior tipo de surpresa.

Streaming com Suspense é outro default do qual dependo. A casca da página renderiza imediatamente e as partes lentas chegam quando ficam prontas. Isso não é truque de performance, é uma restrição de design que te obriga a decidir o que é crítico em cada tela.

Roteamento baseado em arquivos parece trivial até você herdar um projeto com uma tabela de rotas de 2.000 linhas. Convenções que não dá para discutir são convenções que você não precisa documentar.

O que eu não amo

Não sou fã. Fã não audita. O modelo de cache mudou mais de uma vez e cada mudança criou uma classe de projetos meio migrados. A saída do build pode ser opaca quando algo dá errado, e depurar um hydration mismatch às 2 da manhã ensina humildade.

O framework também torna fácil borrar a linha entre código de servidor e de cliente. Essa linha é onde moram a maioria dos bugs sérios que encontro: segredos importados em bundles de cliente, chamadas ao banco dentro de componentes que alguém depois marca com 'use client'. Eu imponho essa linha com o pacote server-only e com regras de lint, não com confiança.

E a questão do fornecedor é real. Next.js roda bem em um servidor Node.js comum atrás de um reverse proxy, e já fiz deploy assim muitas vezes, mas alguns recursos mais avançados funcionam com menos atrito na plataforma de hospedagem da mesma empresa. Você precisa saber disso antes de se comprometer, e decidir de olhos abertos.

A decisão, com honestidade

Então este é o trade-off que aceito. Ganho uma linguagem, um sistema de tipos, uma unidade de deploy e convenções fortes o bastante para sobreviver à rotatividade. Pago com um framework que evolui mais rápido do que eu gostaria e que exige disciplina na fronteira entre servidor e cliente.

Para um protótipo de fim de semana, use o que te dá prazer. Para um produto que vai processar dinheiro, prontuários médicos ou qualquer coisa da qual uma empresa dependa, quero o caminho chato: TypeScript em tudo, Server Components por padrão, um banco relacional e um framework cujas convenções ainda serão legíveis para o engenheiro que me substituir.

É por isso que continuo escolhendo. Não porque é empolgante. Porque deixa a empolgação ir para o produto em vez do encanamento.