Blog/Artigos · Engenharia
A autonomia de time levada ao frontend, as estratégias de composição, a tensão entre independência e experiência coesa, e quando é exagero.
O Mishkan foi construído de muitas cortinas separadas, tecidas independentemente, e a Torá descreve como elas eram unidas por colchetes de ouro até que o tabernáculo se tornasse um. Muitas peças, feitas em paralelo, compostas num todo que parece inteiro. Microfrontends aplicam essa ideia ao frontend. Quando uma aplicação web cresce e muitos times disputam o mesmo código monolítico de interface, a entrega trava: um espera o outro, o deploy é coletivo, o acoplamento sufoca. Microfrontends dividem a interface em pedaços que cada time constrói e entrega sozinho, e depois os compõem numa única aplicação. O desafio, e a arte, é que essas muitas cortinas, unidas pelos colchetes certos, ainda formem um só tabernáculo aos olhos do usuário.
A divisão do backend em microsserviços deu autonomia aos times de servidor, mas muitas vezes deixou o frontend como um único monólito que todos os times precisam tocar. O resultado é um gargalo: o time de pagamentos, o de catálogo e o de conta compartilham o mesmo código de interface, o mesmo pipeline de build e o mesmo deploy, e a autonomia conquistada no backend se perde na frente. Uma mudança pequena de um time espera o ciclo de release coletivo, e o acoplamento no frontend recria exatamente o problema que a divisão do backend resolvera.
Microfrontends estendem a autonomia de time até o frontend. A ideia é dividir a interface por domínio de negócio, alinhado aos mesmos contextos que dividem o backend, de modo que cada time seja dono de uma fatia vertical inteira, do backend ao pedaço de tela correspondente. O time de pagamentos entrega a sua parte da interface no seu ritmo, com sua stack, sem esperar ninguém, e essa parte é composta com as demais numa aplicação única para o usuário. É o mesmo princípio dos microsserviços, autonomia por fatia de negócio, levado à camada que faltava, e nasce da mesma dor: muitos times pisando no mesmo código travam a entrega.
A pergunta central dos microfrontends é como compor as peças num todo, e há um espectro de respostas, cada uma com um trade-off entre acoplamento e autonomia. A composição em tempo de build junta as peças como pacotes num único artefato: simples, mas os times voltam a acoplar no release, porque uma peça nova exige rebuildar o todo. A composição em tempo de execução, no navegador, carrega cada peça dinamicamente, e é aqui que o Module Federation do Webpack e frameworks como o single-spa brilham, dando deploy verdadeiramente independente: cada time publica sua peça e ela aparece na aplicação sem rebuild das outras.
Há ainda a composição no servidor ou na borda, montando a página a partir de fragmentos antes de entregá-la, boa para desempenho e SEO, e a via dos Web Components, o padrão nativo do navegador para encapsular pedaços de interface, agnóstico de framework. Nenhuma estratégia é a certa universal: build-time serve times que toleram release acoplado em troca de simplicidade; run-time serve quem precisa de deploy independente de verdade; server-side serve quem prioriza performance de carga. A escolha dos colchetes que unem as cortinas define quanto de autonomia real os times ganham, e é a decisão técnica mais importante da arquitetura, porque ela determina se a divisão entrega a independência prometida ou só a aparência dela.
| Estratégia | Onde compõe | Autonomia de deploy | Trade-off |
|---|---|---|---|
| Build-time | junta como pacotes no build | baixa, release acoplado | simples, mas rebuild do todo a cada mudança |
| Run-time | no navegador, dinâmico (Module Federation) | alta, deploy independente real | complexidade de carregamento e versões |
| Server/edge | monta fragmentos no servidor | média a alta | boa performance e SEO, mais infraestrutura |
| Web Components | encapsula via padrão do navegador | alta, agnóstico de framework | isolamento de estilo e interoperabilidade |
O grande risco dos microfrontends é o tabernáculo deixar de parecer um. Se cada time tem autonomia total, inclusive de tecnologia e de estilo, o usuário percebe a costura: botões diferentes em cada parte, comportamentos inconsistentes, a sensação de navegar por vários aplicativos remendados em vez de um produto coeso. A autonomia que liberta os times pode fragmentar a experiência de quem usa, e essa é a tensão central que separa os microfrontends bem feitos dos que viram uma colcha de retalhos. As cortinas foram tecidas em paralelo, mas os colchetes de ouro precisam uni-las de modo que pareçam uma.
O colchete que resolve essa tensão é o design system compartilhado. Enquanto os times têm autonomia sobre a lógica e o ritmo da sua fatia, eles consomem os mesmos componentes visuais, os mesmos tokens de cor e espaçamento, as mesmas regras de interação, de uma biblioteca comum. Assim a independência de entrega convive com a coesão de aparência: cada time é dono do seu conteúdo, mas todos falam a mesma língua visual. Sem esse colchete, a autonomia degrada em fragmentação; com ele, as muitas cortinas formam um só tabernáculo. É por isso que design system e microfrontends são inseparáveis: um dá a autonomia, o outro garante que a autonomia não custe a coesão que o usuário sente.
Microfrontends cobram um imposto próprio, análogo ao dos microsserviços. Cada fatia tende a trazer suas dependências, e sem cuidado o usuário baixa três versões de React, uma por microfrontend, inflando o payload e degradando a performance; gerenciar dependências compartilhadas sem reacoplar os times é um problema técnico real. A operação multiplica, mais pipelines, mais deploys, mais pontos de falha, e a depuração de um problema que atravessa fatias de times diferentes fica mais difícil. E há o risco de inconsistência que a seção anterior tratou. Nada disso é impeditivo, mas tudo isso é complexidade que precisa valer a pena.
E na maioria dos casos, não vale. Microfrontends resolvem um problema organizacional, muitos times disputando um frontend grande, e aplicá-los sem esse problema é pura complexidade. Uma aplicação tocada por um único time, ou por poucos que se coordenam bem, não ganha nada em ser fatiada, e perde muito: troca a simplicidade de um frontend coeso pelo overhead de composição, dependências e operação distribuída, sem colher a autonomia que justificaria tudo isso. A regra é a mesma dos microsserviços: a arquitetura espelha a organização, e microfrontends fazem sentido quando a estrutura de times o exige, não quando a interface é grande. Fatiar o tabernáculo em cortinas só faz sentido se há muitos tecelões que precisam trabalhar em paralelo; com um tecelão só, uma peça inteira é mais simples e igualmente bela.
Microfrontends amadurecem do gargalo à composição coesa. No começo é o frontend monolítico que trava muitos times. Depois vem a divisão, às vezes prematura ou pela estratégia de composição errada. No meio vem a composição que dá autonomia real de deploy, com dependências compartilhadas sob controle. No topo é a autonomia de time convivendo com a coesão de experiência, garantida pelo design system compartilhado, e a operação instrumentada para depurar o fluxo entre fatias. Cada degrau busca o equilíbrio entre a liberdade dos tecelões e a unidade do tabernáculo.
Microfrontends são a extensão natural de dois vizinhos deste eixo. São a divisão em microsserviços levada ao frontend, com a mesma lógica de autonomia por fatia de negócio e o mesmo risco de virar um monólito distribuído se as fronteiras estiverem erradas. E dependem visceralmente do design system, que é o único colchete capaz de manter a coesão que a autonomia ameaça. A imagem do Mishkan é precisa: o valor não está em ter muitas cortinas, está em elas formarem um só tabernáculo. Microfrontends só se justificam quando há muitos tecelões que precisam trabalhar em paralelo, e só têm sucesso quando os colchetes, o design system e a estratégia de composição, unem as peças de modo que o usuário veja uma coisa só, e não a costura entre elas.
Microfrontends estendem ao frontend a autonomia de time dos microsserviços: muitas cortinas tecidas em paralelo, unidas por colchetes até o tabernáculo se tornar um. A composição, de build-time a run-time, define quanto de autonomia real os times ganham, e o design system compartilhado é o colchete que impede a autonomia de degradar em colcha de retalhos. Mas o imposto é real, e microfrontends resolvem um problema organizacional, não de tamanho de tela: sem muitos times a disputar o frontend, são exagero. A IA acha as fronteiras e vigia a coesão. O sucesso, porém, se mede numa coisa só: o usuário ver um tabernáculo, e não a costura entre as cortinas.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Engenhariaתּוֹרָה אַחַת
Sem padrão, cada time reinventa o botão, e o produto vira uma babel visual. Design system é uma só lei para toda a interface: tokens e componentes reutilizáveis, montados dos átomos às páginas, numa fonte única da verdade que dá consistência, acessibilidade e velocidade de uma vez.
Engenhariaשָׂפָה אֶחָת
O mercado oscilou do monólito para microsserviços e de volta para o monólito modular. Espalhar em serviços dá autonomia e cobra um imposto pesado de rede, consistência e operação. A pergunta madura não é qual está na moda, é quando o preço de espalhar se paga.
