Turborepo vs Next.js Route Groups: Evitando a Otimização Prematura
Índice do Manual
Na engenharia de software corporativa, existe uma linha muito tênue entre construir para o futuro e cair na armadilha da Otimização Prematura.
Um dos erros mais comuns de times enxutos (ou Solo Founders) ao iniciarem um novo SaaS é tentar copiar cegamente a infraestrutura de gigantes como Uber ou Google, adotando Monorepos complexos no "Dia 1".
[!WARNING] Leia também nosso manual avançado sobre A Engenharia por trás dos Monorepos Corporativos para entender quando o Turborepo se torna de fato a arma secreta das grandes empresas. Mas, se você está começando um projeto do zero, continue lendo.
O Mito do Monorepo no Dia 1
O Turborepo é fantástico, mas ele exige o uso de Workspaces (seja via NPM, PNPM ou Yarn). Isso significa gerenciar múltiplos arquivos package.json, orquestrar a visibilidade entre pacotes (ex: fazer o seu app enxergar a pasta packages/ui) e manter um arquivo turbo.json orquestrando o cache de build.
Para uma startup validando um produto, essa barreira de infraestrutura atrasa a entrega de features que realmente importam e geram faturamento.
A Solução Sênior: O Monolito Next.js
Você não precisa de três repositórios separados (ou um Turborepo complexo) para isolar o Site de Marketing, o Painel do Cliente e o Painel do Administrador. O App Router do Next.js moderno permite que você centralize tudo em um único projeto de forma limpa e direta.
A estrutura padrão e mais recomendada para iniciar é usar Pastas Normais:
src/app/
├── page.tsx (Landing page pública)
├── login/
│ └── page.tsx (Tela de Autenticação)
├── dashboard/
│ └── page.tsx (Área do cliente logado gerando valor)
└── admin/
└── page.tsx (Painel de gestão interna)
Essa abordagem é extremamente simples e resolve 90% dos casos de uso (especialmente para SaaS Internos ou ferramentas de Backoffice).
O "Super-Poder" Opcional: Route Groups
Se o seu sistema crescer e você precisar de Layouts diferentes (ex: O /dashboard precisa de uma Barra Lateral pesada, mas o /login precisa ser uma tela limpa centralizada), o Next.js oferece uma ferramenta chamada Route Groups.
Ao criar pastas envoltas por parênteses (ex: (auth) ou (app)), o Next.js ignora esse nome na URL pública, mas permite que você isole o comportamento do layout.tsx daquela área.
[!NOTE] A Mágica dos Parênteses: Qualquer pasta nomeada entre parênteses é completamente invisível na URL final. Ou seja, o arquivo em
(app)/dashboard/page.tsxcontinua sendo acessado exatamente via/dashboard, mas agora ele herda os layouts exclusivos da pasta(app). Use esse recurso apenas quando a herança de layouts padrão começar a ficar complexa.
As Vantagens do Monolito (Route Groups):
- Domínio Único (Ex:
seu-saas.com): Todos os módulos rodam na mesma URL, divididos apenas pelas rotas (/dashboard,/admin). Isso concentra o SEO e simplifica a configuração de DNS. - Projeto Único na Vercel: Você cria apenas um único projeto no painel da Vercel. Um git push faz o deploy de tudo de uma vez.
- Compartilhamento Absoluto: Todos esses três sub-sistemas consomem o mesmo
package.json, as mesmas cores do TailwindCSS e os mesmos componentes do Shadcn sem nenhuma barreira física. - Zero Configuração: É apenas um repositório clássico. Não há necessidade de configurar variáveis de workspace ou gerenciar rotas complexas de CI/CD.
O Veredito Arquitetural
Quando Migrar para Turborepo? A migração de um Next.js limpo para o Turborepo no futuro é extremamente fácil. Você só deve dar esse passo se o negócio faturar e exigir uma dessas três coisas:
- Construção de um Aplicativo Mobile Nativo (React Native / Expo) que precisa usar os mesmos botões e lógicas da Web.
- Separação de equipes (O time de Marketing não pode ter acesso ao código do App Financeiro).
- O volume de código explodiu a ponto do tempo de build na Vercel gerar gargalos enormes (exigindo o Remote Caching do Turbo).