Quando alguém me pergunta qual stack usar para um novo projeto, minha resposta costuma decepcionar. As pessoas esperam uma comparação de benchmarks, mas não é disso que se trata. Escolhi FastAPI e Angular porque resolvem um problema específico da minha realidade: mantenho vários produtos em produção sozinho. Ou seja, cada decisão de stack que tomo hoje é uma decisão que vou carregar por anos, sem uma equipe para dividir o peso.
Por isso, os critérios que importam na escolha entre FastAPI e Angular e qualquer outra combinação mudam completamente.
O problema real: decisão de solo dev, não de equipe
Times grandes podem se dar ao luxo de escolher ferramentas “best of breed” para cada camada. Por exemplo, um framework de validação aqui, outro de rotas ali, um ORM diferente em cada squad. Quem mantém sozinho múltiplos sistemas, no entanto, não pode se dar a esse luxo. Afinal, toda decisão extra que eu preciso tomar de novo em cada projeto é tempo que não vai para o produto em si. Assim, o critério número um pra mim não é “qual é mais rápido” ou “qual tem mais estrelas no GitHub”. É, na verdade, “qual me obriga a tomar menos decisões repetidas”.
Por que FastAPI no backend
O FastAPI ganhou meu backend por três motivos concretos, não por hype.
Primeiro, a tipagem vira validação de verdade. Com Pydantic, o mesmo type hint que uso para documentar uma função já valida o payload da requisição. Dessa forma, elimino uma classe inteira de bugs bobos de “esqueci de validar esse campo”. Isso importa ainda mais para quem não tem um revisor de código do lado o tempo todo.
Segundo, a documentação não precisa ser mantida separadamente. O Swagger/OpenAPI gerado automaticamente significa que a documentação da API nunca fica desatualizada, porque ela é o código. Isso é ouro quando você volta para um projeto seis meses depois e precisa lembrar como uma rota funciona.
Terceiro, o async é padrão, não exceção. Boa parte dos meus sistemas depende de I/O — banco de dados, chamadas externas, filas. Ter suporte assíncrono nativo desde o design do framework evita gargalos. Esses gargalos, aliás, costumam só aparecer quando o sistema já está em produção.
Essas três razões sozinhas já justificam metade da escolha por FastAPI e Angular. Ainda assim, vale o trade-off honesto: o FastAPI é “menos bateria inclusa” que um Django, por exemplo. Autenticação, ORM, admin — você monta essas peças você mesmo. Para mim isso é uma vantagem, porque dá controle total sobre o que entra no projeto. Contudo, é trabalho a mais no início, e uma equipe maior talvez não queira pagar esse preço.
Por que Angular no frontend
Essa é a escolha que mais gera perguntas, porque a maioria dos devs solo migra para React ou Vue justamente pela flexibilidade. Fiz o caminho contrário. O motivo, aliás, é o mesmo princípio do backend: framework opinativo reduz decisão repetida.
Com Angular eu não preciso escolher roteador. Também não preciso escolher como gerenciar estado, nem como estruturar pastas a cada novo projeto. A resposta já vem definida, e é a mesma em todos os meus projetos. Isso tem um valor enorme quando você troca de contexto entre vários sistemas na mesma semana, já que o “formato mental” é sempre o mesmo.
As mudanças recentes do Angular, além disso, tornaram essa escolha ainda mais fácil de defender:
- Standalone components cortaram boa parte do boilerplate de módulos que afastava gente do framework.
- Signals trouxeram um modelo de reatividade mais simples de raciocinar do que RxJS puro para a maioria dos casos de UI.
- Modo zoneless remove a dependência do Zone.js. Ou seja, menos “mágica” acontecendo por trás e mais controle sobre quando a UI realmente re-renderiza — importante para performance em telas com muito dado dinâmico.
O trade-off honesto aqui também existe. A curva de entrada do Angular ainda é mais alta que a do React. Além disso, se um dia eu precisar contratar ajuda, o pool de devs Angular é menor. Ainda assim, é uma aposta que faz sentido para quem já domina o framework e valoriza consistência acima de flexibilidade — não é conselho universal.
FastAPI e Angular: como as duas pontas se encaixam
Existe uma vantagem que só aparece quando os dois lados usam tipagem forte de verdade. Os tipos do Pydantic no backend e as interfaces TypeScript no frontend descrevem o mesmo contrato. Por isso, dá para gerar um client de API automaticamente a partir do schema OpenAPI. Na prática, isso significa menos bugs do tipo “o frontend espera um campo que o backend não manda mais”. Esse é um erro bobo, mas que consome tempo de debug desproporcional, especialmente sem ninguém para revisar o PR.
Se você quer se aprofundar em outro pilar técnico que uso no dia a dia, já falei aqui no blog sobre Kotlin Vs Java. Vale a leitura complementar.
Não é a stack certa, é a stack certa pra mim
Se eu tivesse uma equipe, talvez a resposta fosse diferente. Mais gente, afinal, significa mais capacidade de absorver a complexidade que um framework “menos opinativo” como React exige. Mas, operando vários produtos sozinho, o cenário muda. O valor de uma stack consistente e tipada de ponta a ponta supera qualquer ganho teórico de flexibilidade.
No fim das contas, a escolha entre FastAPI e Angular não é sobre qual é objetivamente superior. É sobre qual reduz decisões repetidas pra quem opera sozinho. Às vezes, a melhor arquitetura não é a mais elogiada no Twitter. É, simplesmente, a que te deixa dormir tranquilo, sabendo que não vai esquecer como o próprio sistema funciona daqui a seis meses.
0 Comentários