Tenho dois projetos pessoais que resolvem um problema parecido — gestão de turmas, alunos e atividades — mas com arquiteturas bem diferentes. O ProfessorOS é um projeto Next.js "só", com tudo dentro do mesmo processo: front-end, rotas de API e acesso ao banco convivendo na mesma aplicação. Já o leanpulse tem um back-end separado, construído em NestJS, conversando com um front-end Next.js à parte.
Colocando os dois lado a lado, dá para tirar algumas lições sobre quando cada abordagem faz sentido — não como regra fixa, mas como reflexão de quem tomou os dois caminhos na prática.
Tudo junto: o caso do ProfessorOS
No ProfessorOS, uso as rotas de API do próprio Next.js para tudo: autenticação, regras de negócio (como o cálculo de notas por bimestre), acesso ao Prisma. Não existe uma "API" separada — o front-end e o back-end são, na prática, o mesmo deploy.
*Isso funciona muito bem quando:
*
É um projeto de uma pessoa só (sem outro time consumindo a mesma API)
O domínio é relativamente contido — gestão acadêmica pessoal, sem múltiplos clientes diferentes
Meu objetivo é entregar rápido, sem overhead de coordenar dois serviços
Separado: o caso do leanpulse
Já no leanpulse, o back-end em NestJS existe de forma independente do front-end. Isso significa mais peças móveis — dois serviços para implantar (front no Vercel, back no Render), mais configuração de CORS e variáveis de ambiente entre eles.
Em troca, ganho algo que o modelo "tudo junto" não dá tão facilmente: uma API que existe por conta própria, estruturada em módulos (o NestJS organiza o código dessa forma por padrão), pronta para ser consumida por qualquer front-end — não só o que já está integrado a ela.
O que isso me ensinou
Não acho que uma abordagem seja "melhor" que a outra — acho que resolvem problemas diferentes. Meu critério, olhando para trás, ficou mais ou menos assim: se o projeto for para mim, sozinho, resolver algo específico, o modelo monolítico do ProfessorOS entrega valor mais rápido. Se existe qualquer chance de mais de um front-end (ou mais de uma pessoa) precisar falar com a mesma lógica de negócio no futuro, separar o back-end desde o início evita uma refatoração dolorosa depois.
A parte que mais gosto de admitir: não tomei essa decisão com esse nível de clareza na hora. Ela só ficou óbvia depois, comparando os dois projetos prontos.
Top comments (0)