1 min de leitura ·

Next.js App Router um ano depois: foi o passo certo ou complicou demais?

O App Router do Next.js foi a maior mudança arquitetural do framework desde que existe. Um ano de uso em produção gerou opiniões fortes nos dois sentidos.

O que App Router acertou

Server Components. Renderizar no servidor sem mandar JavaScript para o cliente é uma mudança real de paradigma, não só de API. Páginas mais rápidas, menos bundle.

Streaming e Suspense. Mostrar partes da página enquanto outras carregam melhora a experiência percebida de forma mensurável.

Layouts aninhados. A abstração faz sentido e reduz muito código de layout repetido.

O que App Router errou (ou não comunicou bem)

A curva de aprendizado é íngreme e a documentação demorou para amadurecer. "Quando usar 'use client'?" ainda gera confusão em devs experientes.

O comportamento de caching é contraintuitivo. Quantas vezes você se perguntou por que uma mudança não estava aparecendo e era cache?

Erros de hidratação são piores de debugar do que antes. O modelo mental de servidor vs cliente exige internalização que leva tempo.

O diagnóstico honesto

App Router é a direção certa. A execução teve problemas que a Vercel está corrigindo gradualmente. Mas migrar um projeto grande do Pages Router ainda é um projeto por si só.

Você migrou para App Router? Valeu a pena ou ficaria no Pages Router se soubesse o que sabe hoje?

buuhuchiha

3 dias atrás

O que eu busco fazer atualmente é não ir diretamente pro nextjs.
Principalmente se eu tiver trabalhando com IA e com Lovable (sem vibe coding, apenas AI-First),
eu procuro usar o lovable-ssr para me dar a parte do nextjs responsável por Renderizar do lado do lado servidor onde eu ganho: SEO, SSR e validação de segurança.
Ela não substitui o NextJs obviamente, mas dependendo do caso elimina a necessidade de usar o next se o projeto só precisa de 10% do que esse framework oferece.

obrenoalvim

Autor

3 dias atrás

Faz sentido para MVPs onde Next.js é overkill. O ponto que vejo: quando o projeto cresce, migrar de uma solução mínima para um framework completo dá mais trabalho do que começar com o framework e simplesmente não usar tudo.

Mas o pacote é interessante, não conhecia. Você usa em produção já?

jeff1992

4 dias atrás

Acho que o grande problema é o lockin do nextjs para uma escalabilidade de acessos.

Depois da versão 12, ficou praticamente impossível escalar fora da vercel por inviabilidade.

Em todos os casos que atuei, compensou refatorar pra reactjs puro + nestjs e colocar o céu como limite em qualquer plataforma.

Escalar uma aplicação nextjs 13+ numa dev azure, gcp ou aws é um caos. De 1 a 1M de acessos simultâneos é algo que te deixa em parafuso fora da vercel.

Aaagora se isso foi de caso pensado, servercomponentes, já não sei. Mas que fez eu sempre sugerir outras stacks nos projetos, siiiim!!!

obrenoalvim

Autor

4 dias atrás

O lock-in é real, e acho que o ponto central é que o Next.js misturou roteamento com infraestrutura de servidor de uma forma que depende muito do ambiente da Vercel pra funcionar bem. Fora dela, você precisa de um Node rodando a aplicação inteira, e qualquer escala horizontal vira trabalho manual que o framework não foi desenhado pra facilitar.

No BloodLink uso Vercel ainda sem sentir o peso disso, mas sei que é um teto estrutural. A escolha de React puro + NestJS que você descreve faz sentido quando o time já tem maturidade pra gerenciar as duas camadas separadas sem a abstração em cima.

A velocidade inicial do Next compensa até um certo ponto de escala. Quando esse ponto chega, o custo de sair do happy path da Vercel pode ser maior do que teria sido começar separado.