Eu Removi o Next.js do Meu Projeto e Foi a Decisão Certa

Esta semana tomei uma decisão que demorou muito mais do que deveria: removi o Next.js de um dos meus projetos em produção.

Por muito tempo, tentei fazê-lo funcionar.

Next.js é um framework excelente e uma das ferramentas mais poderosas no ecossistema React moderno. Mas depois de meses adaptando minha arquitetura em torno dele, percebi algo importante:

Boas ferramentas nem sempre são as ferramentas certas para cada projeto.

O principal desafio: WebSockets

Minha aplicação depende fortemente de comunicação em tempo real usando Apollo Client, Apollo Server e GraphQL Subscriptions.

O problema é que o servidor padrão do Next.js não suporta WebSockets por padrão. Por causa disso, tive que construir um servidor customizado para lidar com eles.

Criar essa configuração exigiu uma quantidade significativa de trabalho. Procurei extensivamente por exemplos combinando Next.js com Apollo e GraphQL subscriptions em uma arquitetura similar, mas não encontrei nenhum que correspondesse à minha configuração. No final, tive que projetar e implementar a solução eu mesmo.

Embora o servidor customizado funcionasse, veio com uma desvantagem importante: você perde muitos dos benefícios do servidor padrão do Next.js, incluindo algumas otimizações e ferramentas que tornam o framework tão atraente.

Performance de desenvolvimento virou um problema

Conforme a aplicação crescia, a performance de desenvolvimento começou a diminuir significativamente.

Atualizei o projeto para usar Turbopack, esperando melhorar a velocidade de compilação. A melhoria foi notável, mas ainda não foi suficiente. Navegar entre páginas em desenvolvimento permaneceu lento, especialmente porque a aplicação havia crescido para incluir muitas páginas.

Com o tempo, isso começou a impactar a produtividade do desenvolvedor.

SEO não era uma razão forte para mantê-lo

Outro fator importante foi a natureza do produto.

A maior parte da aplicação está atrás de autenticação e é usada por clientes pagantes, o que significa que há muito poucas páginas públicas. Por causa disso, as vantagens de SEO frequentemente associadas a frameworks como Next.js não eram uma justificativa forte para manter a complexidade adicional.

Uma decisão que deveria ter tomado antes

Olhando para trás, provavelmente deveria ter tomado essa decisão mais cedo.

Às vezes gastamos muito tempo tentando forçar uma ferramenta a se adequar à nossa arquitetura em vez de dar um passo atrás e fazer uma pergunta mais simples:

Esta ferramenta ainda está resolvendo meus problemas ou criando novos?

Pensamentos finais

Isso não é uma crítica ao Next.js. Ele permanece um framework excelente e uma ótima escolha para muitos tipos de aplicações, particularmente plataformas com muito conteúdo e produtos orientados a SEO.

Mas decisões de engenharia devem sempre ser orientadas pelo contexto.

A popularidade de um framework nunca deve substituir o ajuste arquitetural.

Às vezes, a otimização mais impactante que você pode fazer é simplesmente escolher o nível certo de complexidade para o seu sistema.

E no meu caso, remover o Next.js acabou sendo exatamente isso.