Não escolhi React e .NET porque eram as ferramentas mais populares. Na verdade, não fiz uma escolha deliberada de todo. Fui trabalhando em projetos que exigiam estrutura do lado do servidor e interatividade do lado do cliente, e estas duas tecnologias eram as que resolviam esses problemas de forma mais direta para mim. Com o tempo, tornaram-se a combinação que associo a como gosto de construir sistemas.
A parte interessante é que continuo a chegar a esta stack mesmo quando começo com outra abordagem em mente. Há qualquer coisa nesta combinação que funciona bem o suficiente para que raramente precise de procurar alternativas.
Porque é que o .NET se encaixa no lado do servidor
O .NET, especialmente o ASP.NET Core, deu-me algo que é difícil de encontrar noutros frameworks: uma estrutura que impõe boas práticas sem ser demasiado restritiva. A injeção de dependências está integrada. O routing é claro. A forma como as APIs são organizadas tem uma lógica que faz sentido mesmo em bases de código grandes.
Comparado com outras abordagens que experimentei, o .NET tem uma curva de aprendizagem mais elevada no início, mas o resultado é um código de servidor que é muito mais fácil de manter a longo prazo. O TypeScript forte no frontend e o C# forte no backend criam uma consistência que ajuda ao trabalhar em ambas as camadas ao mesmo tempo.
Porque é que o React faz sentido do lado do cliente
O React não é perfeito, mas é previsível de uma forma que importa quando se está a construir interfaces complexas. O modelo baseado em componentes torna os casos de uso comuns simples de implementar, e o ecossistema é maduro o suficiente para que a maioria dos problemas já tenha uma solução bem testada disponível.
Mais importante ainda, o React funciona muito bem com o Next.js, que adicionei ao stack mais cedo do que esperava. A capacidade de misturar renderização do lado do servidor e do lado do cliente na mesma base de código, sem mudar de frameworks, provou ser mais valiosa do que antecipava inicialmente.
O que esta combinação resolve bem
O maior benefício não é técnico. É a familiaridade. Quando se conhece bem uma stack, gasta-se menos tempo a resolver problemas de ferramentas e mais tempo a resolver os problemas reais do projeto. Com React e .NET, raramente fico preso em configuração ou a descobrir como as coisas devem funcionar em conjunto.
Também há um claro contrato de separação. O backend lida com dados, lógica de negócio e autenticação. O frontend lida com apresentação e interação. Essa linha raramente fica confusa nesta configuração, o que torna o código mais fácil de raciocinar ao longo do tempo.
Onde não é a escolha certa
Esta stack não é adequada para tudo. Para projetos muito simples, a sobrecarga de ter um backend .NET separado e o React no frontend pode ser demais. Há casos em que algo mais leve funciona melhor, especialmente quando o projeto é essencialmente estático ou quando a velocidade de desenvolvimento é muito mais importante do que a escalabilidade.
Também não é a melhor escolha se a equipa não estiver confortável com C# ou com o ecossistema .NET. Ferramentas que ninguém da equipa conhece bem raramente resultam bem, independentemente de quão boas sejam no papel.
Porque continuo a voltar a ela
A razão mais simples é que funciona. Não perfeitamente, e com os seus próprios trade-offs, mas de forma consistente o suficiente para que eu confie nela quando preciso de construir algo que vai crescer ao longo do tempo. Não é uma escolha excitante, mas a fiabilidade acaba por ser mais útil do que o entusiasmo pelo framework mais recente.
