Paradigmas de frontend: como escolher a arquitetura de um aplicativo web

Antes de escolher uma ferramenta, escolha um paradigma

Quando uma equipe discute «React ou Angular?», com frequência está discutindo a pergunta errada. A decisão que de fato custa anos de manutenção é outra: onde e quando a tela é montada. No navegador do usuário? Em um servidor, a cada visita? Uma única vez, na construção do site? Ou é um aplicativo instalado no computador ou no celular?

Cada resposta é um paradigma, com vantagens reais e custos que não aparecem na demonstração. Este artigo é um mapa para um CTO ou um diretor digital: o que é cada um, quando convém conforme o negócio, quanto custa de verdade e como sair de um sem reescrever tudo. É critério, não receita.

1. Aplicação de página única (SPA)

A MDN a define como uma aplicação web que carrega um único documento e atualiza o conteúdo com JavaScript quando é preciso mostrar outra coisa. A vantagem: o usuário navega sem recarregar páginas inteiras, com uma experiência mais dinâmica. E a MDN também nomeia o custo: SEO, mais esforço para manter o estado e a navegação, e para medir o desempenho de forma significativa.

A documentação do React acrescenta outro: as SPAs são fáceis de começar, mas podem ter tempos de carregamento inicial mais lentos, e, se cada componente pede os próprios dados depois de ser renderizado, formam-se «cascatas» de requisições, em que cada passo espera pelo anterior.

Onde se encaixa: sistemas internos e painéis atrás de um login, e qualquer produto de interação muito intensa em que chegar por um buscador não é a prioridade: ali a interação pesa mais que o primeiro carregamento.

2. Renderização no servidor (SSR)

O servidor monta o HTML a cada requisição e o envia já pronto. O Angular resume assim: o servidor responde com um documento renderizado, o que dá carregamentos mais rápidos do que a renderização no cliente e um HTML completo para os rastreadores. O web.dev nomeia o contrapeso: o primeiro byte pode demorar mais, porque o servidor precisa trabalhar antes de responder.

Há um matiz que convém entender: a página «parece» pronta antes de ser interativa. O web.dev descreve isso como a hidratação: até o JavaScript terminar, a página parece pronta, mas as funções interativas ainda não respondem.

Onde se encaixa: páginas públicas com conteúdo que muda por visita ou por usuário e que importa para os buscadores.

3. Geração estática (SSG)

O HTML de cada URL é gerado uma vez, na construção do site. Segundo o web.dev, isso dá tempos de resposta consistentemente rápidos e permite servi-lo a partir de uma rede de distribuição de conteúdo (CDN); segundo o Angular, o site pode ser publicado apenas com uma CDN ou um servidor de arquivos, sem manter um servidor próprio. O limite também está no web.dev: é inviável quando há milhões de páginas únicas, e exige conhecer as URLs de antemão.

Onde se encaixa: sites corporativos, documentação, blogs, catálogos que mudam pouco.

4. Híbridos e ilhas

A prática real raramente é «um ou outro». O Angular descreve a renderização híbrida como a combinação de servidor, estático e cliente, rota por rota. O Next.js a expressa com componentes de servidor e de cliente: por padrão, páginas e layouts são montados no servidor, e apenas o que precisa de estado, eventos ou APIs do navegador é marcado como de cliente, de modo que se envia menos JavaScript.

// Ilustrativo, tirado da documentação do Next.js: a página é montada no servidor
// e apenas o botão (marcado com 'use client') é interativo no navegador.
<LikeButton likes={post.likes} />

A arquitetura de ilhas leva a ideia ao extremo. A documentação do Astro a descreve assim: a maior parte da página é HTML estático e apenas pequenas «ilhas» recebem JavaScript, somente onde é necessário.

Onde se encaixa: quase qualquer produto público com áreas interativas: um catálogo estático com uma ferramenta de cotação, um site de conteúdo com um carrinho.

5. Microfrontends

Dividem um aplicativo grande em partes que equipes distintas constroem e liberam separadamente. A documentação do single-spa os chama de «um microsserviço dentro do navegador», cada um com o próprio repositório e a própria construção; o Module Federation, do webpack, permite que compilações separadas formem um único aplicativo e compartilhem dependências.

Agora, o que essas páginas não dizem e nós dizemos: um microfrontend resolve um problema de organização, não de tecnologia (critério nosso; as fontes citadas descrevem benefícios e não custos). Faz sentido quando várias equipes, com ritmos de liberação distintos, colidem em uma mesma base de código. Com uma equipe pequena, acrescenta costuras que alguém precisa manter: versões compartilhadas de bibliotecas, consistência visual entre as partes e uma experiência que não pareça costurada.

E há um custo que chega até o usuário: se cada equipe carrega cópias próprias das mesmas bibliotecas, o navegador baixa o mesmo conteúdo várias vezes. As próprias fontes recomendam compartilhar as instâncias das bibliotecas grandes; que isso aconteça depende de as equipes se coordenarem, e se verifica com os sinais de desempenho que mencionamos mais adiante.

6. Aplicativos de computador e de celular multiplataforma

Quando o navegador não basta, há três caminhos de natureza distinta:

• Aplicativo web instalável (PWA). Segundo a MDN e o web.dev, é um aplicativo construído com tecnologias web que se instala, pode funcionar sem rede, receber notificações e usar a tela inteira, com uma única base de código. A MDN esclarece que ele continua dependendo de um motor de navegador e deve ser projetado com melhoria progressiva, porque as APIs avançadas não estão em todos os navegadores.
• Computador (desktop). O Electron empacota Chromium e Node.js para fazer aplicativos de computador com JavaScript, HTML e CSS em Windows, macOS e Linux; a documentação esclarece que o processo que exibe a interface não tem acesso direto ao Node.js, por segurança. O Tauri toma outro caminho: usa o motor web do próprio sistema operacional e um núcleo em Rust, o que a documentação aponta como a razão de os aplicativos serem muito pequenos. Cada decisão tem custo: levar o próprio motor dá um comportamento mais uniforme entre sistemas; depender do que cada um traz economiza tamanho, mas o motor pode diferir de um sistema para outro e a equipe deve resolver diferenças visuais e de comportamento (critério nosso; em ambos os casos é preciso testar em cada sistema operacional suportado). Quando o computador é de fato a resposta —impressoras, leitores, balanças, arquivos locais— explicamos em O aplicativo web já não é suficiente?.
• Celular multiplataforma. O React Native cria, em tempo de execução, as views nativas de Android e iOS a partir de componentes React; por isso, segundo a documentação, os aplicativos se parecem e se comportam como qualquer outro. É uma terceira via entre a web móvel e dois desenvolvimentos nativos separados.

Quando nada disso é necessário

Se o que se precisa é um blog ou uma loja padrão, uma plataforma de conteúdo já pronta, renderizada no servidor de forma clássica, pode ser melhor negócio do que montar uma arquitetura sob medida (critério nosso). Um paradigma se escolhe quando há um problema que o justifique, não por novidade.

Como escolher conforme o negócio

Os custos que não aparecem na demonstração

• Custo de operar. O estático é servido por uma CDN; a renderização no servidor exige executar código a cada visita, em um servidor próprio ou de um provedor, com custo por uso, escalonamento e monitoramento. Que um provedor administre a infraestrutura muda quem a opera, não o fato de alguém precisar vigiá-la.
• Custo de talento. Cada paradigma pede habilidades distintas. Um híbrido bem feito exige que a equipe entenda o que roda onde; do contrário, aparecem erros que só ocorrem «no servidor». E conta o volume: uma ferramenta com menos gente que a domine pode baratear a infraestrutura e encarecer a contratação (critério nosso).
• Custo de medição. Escolher um paradigma não melhora o desempenho por si só. O Google define três sinais de experiência no percentil 75 dos carregamentos, segmentados entre celular e computador: medem-se com usuários reais, antes e depois de cada decisão.
• Custo de segurança. Mover lógica para o servidor protege segredos, mas um servidor exposto também precisa ser defendido; mover lógica para o cliente a torna pública (detalhamos em O que um frontend profissional deve ter).
• Custo de saída. O mais esquecido: quanto custa mudar de ideia. Um paradigma que obriga a reescrever para mudar é uma decisão cara, ainda que hoje pareça barata.

Migrar sem reescrever tudo

Reescrever do zero é a opção que mais custa e a que mais demora a dar resultados. A alternativa que recomendamos como critério é migrar por rotas, começando pelas que mais pesam para o negócio. As fontes tornam isso possível: o Next.js afirma que uma SPA existente pode migrar sem ser totalmente reescrita, que pode começar como site estático ou até como SPA estrita e acrescentar funções de servidor progressivamente, e oferece guias de migração incremental a partir de outros ambientes. A documentação do React assinala que um framework cobre desde o início o que um aplicativo apenas de cliente resolve à mão, como evitar cascatas de requisições.

Três perguntas ordenam uma migração:

1. Qual tela custa mais hoje? Carregamentos lentos na que gera receita, ou uma página pública que não é encontrada. Comece por ali, não pela mais fácil.
2. O que se pode mover sem tocar na lógica de negócio? A apresentação costuma se separar da lógica; se não, esse é o primeiro achado.
3. Como se saberá que melhorou? Definir antes o sinal (desempenho, conversão, erros) e medi-lo com dados reais.

O que responder antes de decidir

Cinco perguntas que um comitê pode responder em uma hora: quem chega por um buscador e quem não? Quais dados não podem viver no dispositivo? Quantas equipes tocam o mesmo produto? Qual canal o cliente mais importante usa? E, sobretudo, quanto custaria mudar de arquitetura dentro de três anos?

Encerramento

A arquitetura certa não é a mais moderna: é a que o negócio consegue operar, medir e mudar. Na Hábil ajudamos a escolhê-la com um critério compartilhado e a construir o caminho de migração que a equipe consiga sustentar.