Microfrontends - o que você precisa saber

Introdução

Recentemente, começamos um novo projeto no time em que trabalho, e a proposta de usar microfrontends apareceu logo de cara. E olha... fazia muito sentido.
O problema? Eu sabia quase nada sobre o assunto. 😅

Sabia que existia, já tinha ouvido falar em algumas palestras e artigos, mas nunca tinha colocado a mão na massa de verdade. Foi aí que começou minha jornada: mergulhar nesse universo, entender a fundo o que são microfrontends, por que usá-los, quando não usar e como aplicá-los na prática.

Esse foi um dos motivos para eu ter topado mudar de time, ter essa experiência com microfrontends, algo inédito pra mim, ainda mais nessa escala.

Esse post é o primeiro de uma série onde vou compartilhar meus aprendizados, dúvidas, erros e acertos com essa arquitetura que ainda gera muita dúvida, especialmente pra quem vem de um mundo mais “monolítico”.

Se você também tá começando, ou simplesmente quer entender melhor como os microfrontends funcionam na prática, vem comigo nessa jornada.

Bora começar?!

O cenário

Sexta-feira, final de sprint, e você precisa subir uma nova feature. Mas o medo bate. O deploy leva uma eternidade, o projeto é muito grande e qualquer mudança, por menor que seja, parece poder quebrar features aleatórias.

Talvez você ja tenha passado por isso, geralmente acontece em projetos monolíticos onde vários times trabalhem, um projeto gigante, com um único repositório, um único pipeline de deploy.

E se cada time pudesse cuidar do seu próprio pedaço de código, com suas próprias ferramentas e seu próprio ritmo de deploy, sem medo de derrubar a parte do time vizinho? É exatamente essa a promessa da arquitetura de microfrontends.

O que são Microfrontends?!

Inspirados nos microsserviços do backend, microfrontends são uma abordagem que decompõe uma aplicação frontend monolítica em partes menores, independentes e focadas em áreas de negócio.

Pense em um e-commerce grande (eu sei, é um exemplo comum, mas é mais didático kkk), ao invés de tudo em um único repositório (catálogo de produtos, carrinho, perfil do usuário, promoções, ...), cada uma dessas partes fossem um projeto isolado, em seu próprio repositório, com seu próprio ciclo de desenvolvimento e deploy.
No final, tudo se encaixar em um grande container, a "aplicação Shell", para formar o produto final que você vê na tela.

Microfrontends são a representação técnica de um subdomínio de negócio no frontend.
Eles permitem a implementação independente, podendo utilizar a mesma ou diferentes tecnologias, e devem minimizar o compartilhamento de código e dependências entre subdomínios, sendo cada um de responsabilidade de um único time. - Luca Mezzalira

Exemplo: Spotify

Usando o Spotify como exemplo, podemos pensar que essas diferentes áreas dentro do app podem ser microfrontends distintos, que juntos formam a interface inteira, e a marcação na cor laranja é o shell, que vamos entender mais daqui a pouco.

OBS.: Eu não sei exatamente como eles separaram os contextos, então essa imagem é apenas fins de exemplificação.

Vantagens

• Times Autônomos: Cada time é dono do seu produto (do desenvolvimento ao deploy). Menos reuniões de alinhamento, mais produtividade.

• Deploy Independente: A melhor parte! O time do carrinho pode fazer 10 deploys por dia sem que o time de busca sequer perceba. O risco de um deploy quebrar o sistema inteiro diminui drasticamente.

• Liberdade Tecnológica: O time de busca quer usar React 19 com um design system novo? Sem problemas. O time de checkout, que é mais crítico, pode continuar usando uma versão mais antiga e estável de outro framework. Mas esse é um ponto que complexo, que na pratica, as vezes, não é tão viável...

• Bases de Código Menores: É muito mais fácil entender, dar manutenção e testar um pedaço isolado do que um monolito de 500 mil linhas.

Desvantagens (nem tudo são flores...)

• Complexidade Operacional: Mais repositórios, mais pipelines, mais infraestrutura para gerenciar. A "orquestração" de tudo isso exige um esforço maior.

• Tamanho do Bundle: Se cada microfrontend carrega sua própria versão do React ou do Lodash, o usuário final pode acabar baixando as mesmas bibliotecas várias vezes. E isso impacta a performance.

• Consistência da Experiência (UX): Como garantir que o botão no microfrontend A seja idêntico ao do microfrontend B? Manter a consistência visual e de interação exige uma estratégia bem definida (como um Design System compartilhado).

• Comunicação e Estado Global: Como o microfrontend de "login" avisa para o de "carrinho" que o usuário se autenticou? A comunicação entre as "peças de LEGO" precisa ser planejada.

Como Microfrontends funcionam?

A Aplicação "Shell" (ou Host):

Se os microfrontends são os "apartamentos", o Shell, é o "prédio". Ele é a aplicação principal que o usuário acessa. Ele não contém a lógica de negócio específica (como calcular frete), mas tem responsabilidades cruciais de orquestração:

1. Renderizar a "Casca" Comum: É o shell que renderiza os elementos que são compartilhados por toda a experiência, como o Header, o menu de Sidebar, o Footer, etc.

2. Gerenciar Autenticação e Autorização: O shell é o lugar perfeito para lidar com o login. Uma vez que o usuário está logado no shell, essa informação de sessão pode ser compartilhada com os microfrontends, garantindo o "single sign-on".

3. Carregar e Exibir os Microfrontends: A principal tarefa do shell é atuar como um maestro.

Comunicação entre Microfrontends:

Top-down (de cima para baixo): O Shell passa informações para o microfrontend via Props ou atributos. (Ex: O Shell informa o ID do usuário para o microfrontend de perfil).

Bottom-up (de baixo para cima): Um microfrontend emite um evento genérico (Custom Events) que o Shell (ou outro microfrontend) pode "ouvir". (Ex: O microfrontend de "adicionar ao carrinho" dispara um evento produtoAdicionado e o de "minicart" no header escuta e se atualiza).

Event Bus (Mediador): Uma camada compartilhada de eventos, onde qualquer um pode publicar e qualquer um pode assinar, sem que se conheçam diretamente. Útil, mas pode criar um acoplamento invisível se usado em excesso.

Estratégias de implementação

As Abordagens Clássicas (e seus problemas):

• Iframes: Isolamento perfeito, mas péssima integração. A comunicação é difícil, o SEO é prejudicado e a UX geralmente sofre.

• Build-time (via pacote NPM): Cada microfrontend é uma biblioteca publicada no NPM. O Shell os instala como dependências.

• Vantagem: Fácil de configurar.

• Desvantagem fatal: Mata o deploy independente. Para atualizar um microfrontend, é preciso atualizar a dependência no Shell e fazer um novo deploy dele.

• Web Components: Ótimos para interoperabilidade (funcionam com qualquer framework), mas não resolvem nativamente o compartilhamento de dependências.

A solução...

É aí que entra o Module Federation. E se você pudesse importar um componente de outro projeto... em tempo de execução? Sem npm install, sem versionamento, apenas apontando para uma URL?
O Module Federation, uma feature popularizada pelo Webpack, permite exatamente isso. Mas vamos falar dele em mais detalhes em outro post haha

Testando seu entendimento

Conclusão

Microfrontends não são uma bala de prata, mas uma solução poderosa para um problema real: escalar o desenvolvimento de aplicações frontend complexas.
Eles trocam a complexidade acidental de um monolito pela complexidade intencional de um sistema distribuído.

Você já trabalhou com microfrontends? Qual foi sua experiência? Conta aqui nos comentários!

E muito obrigado por ter lido até aqui, grande abraço e até a próxima.