Como funcionam os microfrontends: arquitetura, padrões e exemplos.

Início » Python » Como funcionam os microfrontends: arquitetura, padrões e exemplos.

Os microfrontends se tornaram um dos padrões de arquitetura de front-end mais comentados. Para equipes que superaram a capacidade do clássico monolito de página única. Quando dezenas de desenvolvedores trabalham no mesmo código, os ciclos de lançamento ficam mais lentos, regressões surgem em todos os lugares e pequenas alterações na interface do usuário exigem uma coordenação enorme. Os microfrontends atacam exatamente esse problema, dividindo a interface do usuário em partes independentes, construídas e implantadas separadamente.

Neste guia, vamos abordar o que são microfrontends, por que surgiram e como se relacionam com microsserviços.Neste artigo, abordaremos os principais conceitos arquitetônicos que você deve respeitar ao projetá-los e como eles funcionam na prática com tecnologias como React, Angular, Next.js, Web Components, Webpack Module Federation e Single-SPA. Também exploraremos padrões arquitetônicos reais, boas práticas, armadilhas comuns e exemplos concretos, como um catálogo de produtos e um carrinho de compras implementados como microfrontends separados.

O que são microfrontends e por que surgiram?

O termo “micro front-ends” foi popularizado por volta de 2016 no ThoughtWorks Technology Radar. Como resposta a uma tendência muito concreta: as arquiteturas de backend estavam migrando para microsserviços, mas o lado do navegador permanecia um monolito grande e frágil, pertencente a uma única equipe. Com o tempo, esse SPA "cliente pesado" torna-se difícil de evoluir, mesmo que o backend esteja bem dividido em pequenos serviços.

Um microfrontend é essencialmente a ideia de microsserviços aplicada à interface do usuário do navegador.Em vez de um grande repositório de front-end, você compõe a interface do usuário a partir de vários aplicativos menores e independentes. Cada um possui um domínio de negócios claro (por exemplo, "finalização da compra", "busca de produtos", "perfis de alunos") e pode ser construído, testado e implantado em seu próprio ritmo.

Assim como os microsserviços dividem a lógica de backend em unidades implantáveis ​​separadas, os microfrontends dividem o frontend em fatias verticais. que abrangem desde o banco de dados ou APIs, passando pelo backend, até a interface do usuário. Uma equipe multifuncional é responsável por essa vertente vertical de ponta a ponta, desde o esquema de dados até os componentes da interface do usuário.

Essa “organização vertical” contrasta com uma divisão horizontal por camadas. (Uma equipe para a interface do usuário, outra para as APIs e outra para o banco de dados). Equipes verticais tendem a entregar resultados mais rapidamente porque não precisam coordenar cada pequena alteração em metade da empresa.

Do ponto de vista da aplicação, um microfrontend é uma aplicação web autônoma. que pode ser composta em uma experiência maior: ela pode ter seu próprio roteamento, gerenciamento de estado, sistema de design e pipeline de implantação, desde que respeite um conjunto de contratos com o restante do sistema (URLs, eventos, APIs, bibliotecas compartilhadas, etc.).

Ideias e princípios fundamentais por trás dos microfrontends

Diversos princípios recorrentes aparecem em arquiteturas de microfrontend bem-sucedidas.Não são regras rígidas, mas podem evitar muitos problemas se você as usar como diretrizes.

agnosticismo tecnológico Um dos princípios mais famosos é o seguinte: cada equipe deve poder escolher e atualizar seu conjunto de tecnologias sem precisar se sincronizar com as demais. Talvez um microfrontend esteja em React, outro em Angular e um legado em Vue. Abstrações nativas do navegador, como Elementos Personalizados (Web Components), ajudam a ocultar essas diferenças por trás de uma API DOM padrão.

Outro objetivo fundamental é o forte isolamento entre as bases de código das equipes.Idealmente, os microfrontends não compartilham um ambiente de execução JavaScript nem variáveis ​​globais. Cada pacote é autocontido, carrega suas próprias dependências e não depende de estado oculto de outros. Isso reduz o acoplamento acidental e torna as implantações independentes muito mais viáveis.

Para evitar conflitos de nomes, as equipes geralmente concordam com espaços de nomes explícitos. para classes CSS, eventos DOM, chaves do localStorage, cookies ou até mesmo nomes de tags de elementos personalizados. Por exemplo, uma equipe de finalização de compra pode prefixar os itens com chk- ou use uma etiqueta como <blue-buy>, enquanto uma equipe de recomendações usa rec- or <green-recos>À primeira vista, o DOM (Departamento de Ordenamento do Mercado) mostra quem é o proprietário de cada item.

Outro princípio é dar preferência às funcionalidades nativas do navegador em vez de APIs globais personalizadas.Em vez de inventar um sistema PubSub para todos os fins, você pode confiar em eventos DOM padrão. CustomEvent, API de histórico para roteamento ou o próprio DOM como camada de integração. Sempre que você realmente precisar de uma API compartilhada, mantenha-a o mais pequena e estável possível.

Por fim, a resiliência deve fazer parte do projeto desde o primeiro dia.Cada microfrontend deve continuar a oferecer algum valor mesmo quando o JavaScript estiver lento, falhar ou estiver bloqueado. Técnicas como renderização do lado do servidor, aprimoramento progressivo e telas de esqueleto ajudam a manter o desempenho percebido elevado mesmo em condições de rede precárias.

O que é uma “aplicação web moderna” neste contexto?

Nem todos os sites precisam de microfrontends ou de uma estratégia complexa de integração com navegadores.Um bom modelo mental surge do "contínuo documentos-aplicativos": à esquerda, você tem principalmente documentos estáticos interligados; à direita, você tem aplicativos totalmente interativos, como um editor de fotos online.

Se o seu projeto for mais voltado para documentos estáticos, uma composição simples renderizada no servidor geralmente é suficiente.O servidor reúne fragmentos HTML de diferentes fontes, os une e os envia para o navegador. As atualizações ocorrem por meio de carregamentos completos da página ou pequenas injeções de Ajax, e isso é perfeitamente normal.

Ao migrar para experiências mais dinâmicas, semelhantes a aplicativos, você terá experiências mais práticas e intuitivas.—feedback instantâneo, funcionamento offline, atualizações de interface do usuário otimistas—a integração puramente do lado do servidor deixa de ser suficiente. Você precisa de composição, gerenciamento de estado e roteamento do lado do cliente. É aí que os microfrontends se tornam interessantes: eles oferecem uma maneira de escalar essa complexidade em várias equipes.

Organização vertical e fatias orientadas por domínio

Uma recomendação comum é alinhar os microfrontends com os domínios de negócio em vez das camadas técnicas.Pense em termos de jornadas do usuário: “carrinho”, “detalhes do produto”, “usuários administradores”, “horários de cursos”, “registros de alunos”, “faturas”, etc.

Cada um desses domínios pode se tornar seu próprio microfrontend com uma responsabilidade bem definida.Em um sistema universitário, um aplicativo pode gerenciar perfis de alunos, outro perfis de funcionários, um terceiro horários de cursos e outro a interface de resultados de exames. Eles compartilham uma estrutura básica e talvez alguns elementos de estilo, mas cada um é um aplicativo independente do ponto de vista de implantação.

Uma boa segmentação também leva em consideração os contextos delimitados dos seus microsserviços de backend.Idealmente, o microfrontend de "faturamento" se comunica principalmente com os microsserviços de faturamento, o frontend de "catálogo" se comunica com os serviços de catálogo e assim por diante. Isso mantém cada segmento vertical coeso e reduz as dependências entre equipes.

Integração técnica: DOM como API e Web Components

Em arquiteturas de microfrontends do lado do navegador, o próprio DOM geralmente atua como a principal API de integração.Em vez de chamarem o JavaScript uns dos outros diretamente, as equipes expõem a funcionalidade por meio de elementos HTML, atributos e eventos.

Elementos personalizados (parte dos componentes da Web) são um recurso básico poderoso para isso.Uma equipe pode criar um recurso usando qualquer framework que desejar e, em seguida, encapsulá-lo como uma tag personalizada, por exemplo. <order-minicart></order-minicart>O contrato público desse componente é definido pelo nome da sua tag, pelos atributos e pelos eventos emitidos, e não pela sua implementação interna.

O suporte do navegador para Custom Elements v1 agora é sólido em todos os principais navegadores.Isso significa que você raramente precisa de polyfills. A maioria dos frameworks convencionais – React, Vue, Angular, Svelte, Preact – consegue renderizar ou incorporar elementos personalizados como se fossem tags HTML comuns, e muitos deles também podem ser compilados em um elemento personalizado.

O padrão de integração se parece mais ou menos com isto:Um microfrontend de "página de produto" decide quais recursos aparecem na página (seletores, botões de compra, mini-carrinho, recomendações). Ele injeta elementos personalizados, como: <blue-buy sku="t_porsche"></blue-buy> or <green-recos sku="t_porsche"></green-recos>As equipes responsáveis ​​por esses recursos registram seus elementos com customElements.define e implementar callbacks de ciclo de vida como connectedCallback or attributeChangedCallback.

Quando uma variante de produto é alterada, a página pode recriar o elemento ou apenas atualizar seus atributos.Se o componente observar os atributos relevantes, ele poderá renderizar-se novamente. Internamente, o componente pode usar strings de modelo, React, Vue ou qualquer mecanismo de renderização; o integrador não precisa se preocupar com isso.

Comunicação do lado do cliente: eventos e relações DOM

A passagem de atributos funciona bem em cenários de "entrada de dados unidirecional".Mas muitas interações reais exigem que os componentes se comuniquem com o ambiente ou com outros componentes. Um exemplo típico é um botão "comprar" que precisa notificar o mini-carrinho quando um item é adicionado.

Em vez de criar um barramento de eventos global personalizado, você pode usar os eventos do navegador.Despacho de componentes CustomEvent instâncias que se propagam pela árvore DOM. Um elemento pai ou mesmo window pode ouvir esses eventos e orquestrar respostas.

Por exemplo, o botão de compra pode emitir um evento como blue:basket:changed com a carga útil atual do carrinhoO mini-carrinho se inscreve nesse evento em window ou em um elemento de contêiner compartilhado e atualiza seu estado interno sempre que é acionado.

Essa abordagem mantém os componentes independentes.O botão de compra não tem ideia de quem, se é que alguém, está escutando seus eventos. Ele apenas cumpre seu contrato. E o mini-carrinho depende apenas da semântica dos eventos, não dos detalhes de implementação de outros fragmentos.

Renderização do lado do servidor e componentes universais

Se você se preocupa com o desempenho da primeira renderização, SEO ou resiliência quando o JavaScript falha, a renderização do lado do servidor (SSR) é essencial.Os Web Components puramente do lado do cliente só aparecem depois que o pacote JS é baixado e executado, o que pode resultar em uma tela branca em redes lentas.

Uma solução pragmática é combinar elementos personalizados com includes do lado do servidor (SSI/ESI).Cada microfrontend expõe um endpoint HTTP que retorna o HTML do seu fragmento, por exemplo. /blue-buy?sku=t_porscheA página principal, renderizada por um shell ou aplicativo host, inclui espaços reservados como <!--#include virtual="/blue-buy?sku=t_porsche" --> que o servidor web (geralmente nginx) expande antes de enviar a resposta ao navegador.

Em tempo de execução no navegador, o mesmo elemento personalizado é hidratado ou reinicializado. Assim que seu pacote JS for carregado. Isso lhe dá um componente "universal": ele pode ser renderizado no servidor para velocidade e SEO, e então se comportar como um elemento personalizado totalmente interativo no cliente.

Uma desvantagem do SSR com includes é que o fragmento mais lento determina o tempo total de resposta.O armazenamento em cache no nível do fragmento é quase obrigatório. Para elementos complexos e altamente personalizados (como recomendações), você pode optar por não utilizar a renderização no servidor e carregá-los de forma assíncrona no cliente.

Telas de esqueleto são um bom meio-termo para evitar mudanças bruscas de layout.Um fragmento pode renderizar no servidor um espaço reservado esmaecido com aproximadamente o mesmo tamanho do conteúdo final. Quando os dados reais chegam ao lado do cliente, o esqueleto é substituído sem grandes alterações no layout.

Carregamento de dados e desempenho percebido

Em um mundo de microfrontends, é preciso pensar cuidadosamente sobre onde e quando os dados são buscados.Você pode buscar tudo no servidor, tudo no cliente ou usar uma abordagem híbrida. Cada escolha afeta as estratégias de cache, o tempo de interação e a velocidade percebida.

Os includes do lado do servidor incentivam naturalmente as buscas do lado do servidor por fragmento.Cada microfrontend se comunica com seus serviços de backend, renderiza o HTML e o retorna ao shell. Esse HTML pode ser armazenado em cache independentemente de outros fragmentos, o que ajuda a escalar partes de alto tráfego, como login ou listas de produtos.

Ao carregar dados no cliente, você deve levar em consideração os estados progressivos.Esqueleto inicial, atualizações rápidas quando os atributos mudam e comportamento alternativo quando as APIs estão lentas. Às vezes, manter os dados antigos até que os novos cheguem é visualmente menos impactante do que exibir um esqueleto a cada pequena alteração.

Microfrontends com React

React é uma escolha muito popular para implementar microfrontends devido ao seu ecossistema e otimizações de renderização.O DOM virtual e a comparação de diferenças facilitam a atualização de pequenas partes da interface do usuário com base em alterações de propriedades ou no estado global, e você pode agrupar aplicativos React como SPAs independentes ou como elementos personalizados.

A migração entre versões do React tende a ser incremental e relativamente simples. Em comparação com outros frameworks, isso é útil quando várias equipes independentes mantêm microfrontends separados. Não é necessário que todos os fragmentos migrem de uma versão principal para outra ao mesmo tempo.

A contrapartida é que os microfrontends React descentralizados podem gerar uma proliferação de recursos.Múltiplas equipes, múltiplos pipelines de CI/CD, muitos bundles, muitos repositórios pequenos. Sem automação suficiente para compilação, provisionamento e observabilidade, essa sobrecarga torna-se difícil de gerenciar.

Outra questão prática é o tamanho do pacote.Se cada microfrontend incluir sua própria cópia do React e bibliotecas compartilhadas, o tamanho total do download pode aumentar exponencialmente, especialmente quando vários fragmentos são necessários para renderizar uma página. Soluções como a Federação de Módulos (para compartilhar dependências em tempo de execução) ou uma pilha tecnológica fortemente alinhada entre as equipes podem mitigar esse problema.

Microfrontends com Angular

O Angular se adapta muito bem a configurações de microfrontend mais opinativas., especialmente quando se utilizam monorepos e as ferramentas associadas a eles (como o Nx). Os espaços de trabalho do Angular são organizados em projetos e bibliotecas, o que torna natural dividir uma solução grande em vários aplicativos e bibliotecas compartilhadas.

Desde o Angular 12 e o Webpack 5, a Federação de Módulos tornou-se um recurso essencial.Um projeto Angular pode ser configurado como host ou remoto usando comandos esquemáticos, estabelecendo a infraestrutura necessária. webpack.config.js e lógica de inicialização para você.

Neste modelo, o aplicativo Angular "host" atua como a camada externa (shell). que orquestra a navegação, o estado compartilhado e o compartilhamento de dependências. Microfrontends individuais do Angular (remotos) expõem módulos do Angular que o host pode carregar dinamicamente sob demanda por meio da Federação de Módulos.

Os princípios básicos de roteamento do Angular ainda se aplicam.Dentro de um microfrontend, você usa RouterModule.forChild para definições de rotas filhas, de forma que o host seja o único a usar forRootDessa forma, vários aplicativos Angular podem coexistir em um espaço de URL unificado sem conflitos de roteamento.

Federação de módulos na prática (exemplo em Angular)

O Webpack Module Federation é um recurso do Webpack 5 que permite que várias compilações compartilhem código em tempo de execução.Uma compilação (o host) carrega dinamicamente módulos expostos por outras compilações (remotas) por meio de um pequeno arquivo de manifesto, normalmente chamado remoteEntry.js.

Em Angular, você pode criar a estrutura básica disso com bastante rapidez.Por exemplo, você pode criar um aplicativo host (host-app) e então execute um esquema como ng add @angular-architects/module-federation --project host-app --port 4200Isso configura um ModuleFederationPlugin, inicializando os arquivos e definindo a lógica de tempo de execução.

Em seguida, você cria dois aplicativos Angular remotos: um para um catálogo de produtos e outro para um carrinho de compras.Cada aplicativo recebe sua própria porta (por exemplo, 4201 para products-app, 4202 para cart-app) e sua própria configuração de Federação de Módulos. Em webpack.config.js de cada controle remoto que você usa exposes Publicar um módulo (normalmente o módulo principal do aplicativo) com uma chave como ./ProductsModule or ./CartModule.

O shell do host define então rotas que carregam esses módulos remotos de forma assíncrona. via loadRemoteModule da @angular-architects/module-federationPor exemplo, navegar até /products aciona uma importação dinâmica de http://localhost:4201/remoteEntry.js e cargas ProductsModule; /cart Faz o mesmo com o controle remoto do carrinho.

Dentro do microfrontend do catálogo, você pode ter um ProductsComponent que gera uma tabela de itens, lendo dados de um PRODUCTS_CATALOG constante e oferecendo um botão “Adicionar ao carrinho”. Ao clicar, o item permanece no carrinho. localStorage Sob a chave "carrinho", incrementando as quantidades quando o produto já existe.

O microfrontend do carrinho lê então do mesmo localStorage chaveA página exibe uma tabela com o nome do produto, preço, quantidade e total, e oferece um botão "Limpar carrinho" que limpa o armazenamento e redefine seu estado interno. Esta é uma maneira simples, porém ilustrativa, de compartilhar o estado entre dois aplicativos independentes sem acoplamento rígido.

Construindo o shell do host: layout, página inicial e navegação

Uma infraestrutura de hospedagem robusta é fundamental para uma boa experiência do usuário em microfrontends.Geralmente, ele é responsável pelo layout global (cabeçalho, rodapé, barras laterais), roteamento de nível superior e, às vezes, pelo estado global, como autenticação ou sinalizadores de recursos.

No exemplo do Angular, o host define um LayoutComponent que renderiza um cabeçalho e um aninhado router-outletO cabeçalho reside em seu próprio diretório. HeaderModule e expõe links de navegação para a página inicial, lista de produtos e carrinho através do Angular. routerLinkOs caminhos de rota podem ser centralizados em uma enumeração como RoutesPath Para evitar fios mágicos.

O módulo de roteamento de layout configura uma rota principal com LayoutComponent como seu componente e define rotas filhas para /home, /products e /cart. O /home O caminho carrega um local HomeModule; os outros usam loadRemoteModule para incorporar os microfrontends do Angular em tempo de execução.

Dentro do hospedeiro, um SharedModule pode reunir blocos de construção reutilizáveis como cabeçalho, layout, diretivas comuns e constantes. Este módulo pode ser importado para o diretório raiz. AppModule e o AppRoutingModule, que aponta o caminho vazio para a configuração de roteamento do layout.

Next.js e microfrontends

O Next.js, como framework React de nível de produção, também funciona bem com uma abordagem de microfrontend., especialmente desde que adotou o Webpack 5 e, portanto, o suporte à Federação de Módulos. Seu foco em SSR, regeneração estática incremental e roteamento o torna um bom candidato para o shell, microfrontends individuais ou ambos.

Para implementar microfrontends no Next.js, normalmente você configura a Federação de Módulos no nível do Webpack.A Federação de Módulos consiste em expor determinadas páginas ou componentes como remotos e consumi-los a partir de um host. Embora a Federação de Módulos seja "apenas" um recurso do bundler JavaScript, você pode considerá-la um padrão arquitetural: ela permite carregar dinamicamente código pertencente a diferentes equipes sem precisar agrupar tudo antecipadamente.

Para versões antigas do Next.js sem o Webpack 5, você precisará de adaptadores externos. Para habilitar o suporte à federação. A partir do Next 10.2, o suporte ao Webpack 5 já está integrado, o que simplifica bastante a configuração.

SPA único e outras estruturas de microfrontend

Single-SPA é outra solução bem conhecida para microfrontends, particularmente em ecossistemas React.. Seu foco é orquestrar vários aplicativos independentes na mesma página, cada um montado em seu próprio nó DOM com base na rota atual.

Com o Single-SPA, você pode ter vários aplicativos React (ou até mesmo misturar React, Vue e Angular) coexistindo.O framework gerencia quando inicializar, montar ou desmontar cada microfrontend conforme o usuário navega, e você o integra à sua estratégia de roteamento (por exemplo, com o React Router em cada fragmento).

Ao escolher entre Single‐SPA e Federação de MódulosAs equipes geralmente consideram suas preferências de bundler/ferramentas. O Module Federation se integra profundamente ao Webpack (e, cada vez mais, a alternativas como Rspack ou Rollup, à medida que adicionam suporte). O Single-SPA, por outro lado, foca mais na orquestração em tempo de execução do que no compartilhamento de pacotes, permitindo seu uso com diferentes ferramentas de build e o gerenciamento do compartilhamento de código de outras maneiras.

Objetivos, características e benefícios dos microfrontends

O principal objetivo dos microfrontends é escalar o desenvolvimento de frontend em várias equipes sem que isso comprometa a coordenação.Em vez de uma base de código gigante com lançamentos sincronizados, você obtém unidades menores e implantáveis ​​independentemente.

Os principais objetivos geralmente incluem Permitir que várias equipes trabalhem em paralelo, suportar a implantação independente de diferentes partes da interface do usuário, manter a flexibilidade para usar diferentes tecnologias onde fizer sentido e melhorar a capacidade de manutenção, reduzindo o tamanho e a complexidade de cada base de código.

Características típicas de tal arquitetura incluem a reutilização de componentes por meio de bibliotecas compartilhadas.Integração modular por meio de um shell de aplicação, pipelines independentes por microfrontend, otimização de desempenho via CDN e cache, gerenciamento centralizado de segurança e forte observabilidade.

Do ponto de vista empresarial, os benefícios são substanciais.O desenvolvimento escala melhor com mais equipes, as falhas são melhor isoladas, os recursos podem ser implementados ou revertidos por domínio e as arquiteturas legadas de front-end podem ser migradas gradualmente, substituindo uma parte de cada vez, em vez de reescrever todo o aplicativo.

Componentes-chave em uma arquitetura de microfrontend

Embora as implementações variem, a maioria das arquiteturas de microfrontends compartilham alguns componentes estruturais. que mantêm tudo coerente.

O shell (ou contêiner) da aplicação é a espinha dorsal.Ela é responsável pelo layout externo, navegação global, autenticação, às vezes estado global e pela lógica de carregamento ou descarregamento de microfrontends. Em configurações baseadas em navegador, é a página que importa todos os outros pacotes.

Cada microfrontend é um módulo independente que implementa uma funcionalidade específica.como catálogo de produtos, carrinho de compras, perfil de usuário ou painel de administração. Ele expõe uma superfície de integração (rotas, elementos personalizados, remotos de Federação de Módulos) e oculta detalhes internos do restante do sistema.

Um barramento de eventos ou sistema de mensagens geralmente está presente para comunicação entre microfront-ends.Isso pode ser uma abstração simples sobre eventos DOM, um armazenamento Redux centralizado ou um broker de mensagens personalizado. O objetivo é uma semântica de publicação/assinatura desacoplada: um microfrontend emite eventos sem saber quem os processa.

Bibliotecas compartilhadas hospedam componentes de interface do usuário reutilizáveis, utilitários, tokens de design e clientes comuns.Em configurações de monorepo, ferramentas como o Nx se destacam, permitindo definir pacotes compartilhados consumidos por vários aplicativos com limites definidos e versões consistentes.

Coletores e ferramentas de observabilidade (por exemplo, usando OpenTelemetry) Agrega logs, métricas e rastreamentos de todos os microfrontends, possibilitando o diagnóstico de problemas que abrangem múltiplos fragmentos ou serviços.

As CDNs completam o cenário no lado da entrega.O armazenamento em cache de recursos estáticos, como pacotes JS, CSS e imagens, próximo aos usuários reduz a latência e alivia a carga dos servidores de origem. Em configurações de microfrontends, é comum hospedar os recursos de cada fragmento em seu próprio caminho de CDN para armazenamento em cache e distribuição independentes.

Arquitetura e padrões de design para microfrontends

Existe um vasto catálogo de padrões que se aplicam especificamente a microfrontends., geralmente definida pela forma como você as compõe, implanta e conecta.

A composição baseada em componentes significa construir a interface do usuário a partir de componentes web ou elementos primitivos semelhantes.Cada componente tem uma única responsabilidade, entradas e saídas claras, e pode ser testado isoladamente. Uma camada de composição de nível superior (como um shell ou framework de orquestração) organiza esses componentes em páginas completas.

O padrão de federação enfatiza a autonomia completa da aplicação.Cada microfrontend é um aplicativo independente com seu próprio ciclo de vida e equipe; o shell ou um gateway de API simplesmente encaminha solicitações/dados para o fragmento correto. A comunicação ocorre por meio de APIs REST bem definidas ou eventos.

O padrão de shell de aplicação é, na prática, a abordagem de "host".O shell carrega microfrontends, lida com questões transversais como navegação e segurança e garante uma aparência e experiência consistentes. Isso é muito comum em configurações baseadas em Federação de Módulos ou SPA Único.

Os padrões API Gateway e Backend-for-Frontend (BFF) focam no lado do servidor.Um gateway de API fica na frente de vários serviços de backend, roteando solicitações e aplicando segurança. Um BFF vai além: cada frontend (web, mobile, IoT) pode ter seu próprio backend dedicado, personalizado para suas necessidades.

Os padrões de armazenamento de dados distribuídos reconhecem que diferentes microfrontends podem gerenciar suas próprias fontes de dados. ou caches. No navegador, isso geralmente significa usar chaves localStorage separadas, bancos de dados IndexedDB ou armazenamentos em memória, enquanto no backend significa bancos de dados separados por microsserviço.

Observabilidade, implantação independente, escalabilidade horizontal e padrões de segurança Abordar questões operacionais: como monitorar cada fragmento, como implantá-los sem interrupções globais, como escalá-los sob carga e como aplicar autenticação/autorização de forma consistente.

A composição de rotas e os padrões de carregamento lento são fundamentais para a experiência do usuário e o desempenho.Um roteador mestre decide qual microfrontend lida com qual caminho, e cada microfrontend tem seu próprio roteador interno. O carregamento lento garante que você baixe apenas o código dos fragmentos realmente necessários para a rota atual.

Por fim, os padrões de comunicação baseados em eventos garantem que microfront-ends fracamente acoplados ainda possam se coordenar. por meio de eventos de domínio, sem introduzir dependências diretas que anulariam o propósito da modularidade.

Quando usar microfrontends (e quando não usar)

Microfrontends se destacam em aplicações grandes e complexas com domínios funcionais bem definidos.Pense em plataformas de comércio eletrônico, sistemas de gestão empresarial, portais municipais, plataformas educacionais, grandes portais de saúde ou qualquer produto com muitas equipes trabalhando em áreas funcionais separadas.

São particularmente úteis quando se tem várias equipes trabalhando em paralelo. que precisam de autonomia nas escolhas tecnológicas, ciclos de lançamento e prioridades, ou quando você está modernizando gradualmente um frontend legado e não pode arcar com uma reescrita completa. Você pode criar uma área por vez em um novo microfrontend e integrá-lo ao shell antigo.

Eles também são úteis quando diferentes partes do aplicativo precisam ser dimensionadas de forma diferente.Uma página de login ou de finalização de compra pode receber muito mais tráfego do que uma tela de configuração administrativa; dimensionar essas partes independentemente pode economizar muito em custos de infraestrutura.

No entanto, microfrontends não são uma solução gratuita.Elas adicionam complexidade arquitetônica, exigem forte coordenação em UX e contratos compartilhados, e introduzem novos modos de falha (por exemplo, um fragmento que não carrega). Para aplicativos de pequeno ou médio porte com uma única equipe, um monolito bem estruturado costuma ser mais simples e econômico.

As equipes também devem estar atentas à "anarquia de frameworks".Embora seja tecnicamente possível que cada microfrontend utilize uma pilha de frameworks completamente diferente, uma mistura descontrolada de frameworks dificulta a contratação, o compartilhamento de ferramentas e de código. Um nível razoável de alinhamento (por exemplo, "somos uma empresa que prioriza React, mas permitimos Angular para domínios específicos") geralmente funciona melhor a longo prazo.

Os microfrontends estendem a mentalidade de microsserviços para o navegador, oferecendo às equipes uma maneira de dividir grandes frontends em partes autônomas e orientadas a domínios, que podem evoluir, ser implantadas e escaladas independentemente, mantendo uma experiência de usuário coesa quando combinadas por meio de um shell de aplicativo, bibliotecas compartilhadas, Federação de Módulos, Web Components ou frameworks de orquestração como o Single-SPA.