BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Como os Microfrontends podem ajudar a focar nas necessidades de negócios

Como os Microfrontends podem ajudar a focar nas necessidades de negócios

Favoritos

Pontos Principais

  • Os microfrontends podem ajudar os desenvolvedores a focar nos requisitos funcionais e nas necessidades de negócios;

  • Os microfrontends podem acelerar o time to market, aumentar o reuso de código na empresa e simplificar o processo de desenvolvimento;

  • As possíveis desvantagens são a complexidade extra, os custos de integração e os impactos negativos na UX e no desempenho;

  • Construir uma plataforma para microfrontends é muito semelhante ao de uma plataforma para microservices;

  • O servidor Mashroom pode ser o componente de integração para a plataforma de microfrontends..

A seguinte situação pode soar familiar: O departamento de negócios contrata alguns desenvolvedores ou uma empresa terceirizada para construir rapidamente um site simples e novo para vender um produto. E em algum momento, essa equipe realiza a passagem de bastão para o departamento de TI da empresa, que é onde as dificuldades começam. Geralmente, a equipe de TI fica desconfortável com a área de negócios, pois contrataram pessoas para criar o novo site sem consultá-los antes. E agora é necessário integrá-lo aos sistemas. Provavelmente o novo site foi escrito em alguma tecnologia que a equipe de TI não está familiarizada e com certeza não respeita o modelo de domínios e os processos internos existentes.

Mas qual o motivo da equipe de negócios não acionar o departamento de TI antes de contratar uma empresa terceirizada? Talvez acreditassem que não conseguiriam ter o que precisavam seguindo o caminho padrão da empresa. Às vezes, essas solicitações levam a discussões entediantes sobre se um requisito está ou não se encaixando na arquitetura geral e no cenário de aplicações existentes. Ou talvez, simplesmente soubessem que a equipe de TI estava completamente sobrecarregada e não conseguiriam entregar algo em um prazo tão curto.

Talvez, uma maneira de resolver esse problema poderia ser a definição de requisitos mínimos para essas pequenas aplicações microfrontend, sem a necessidade de incluir toda a sobrecarga de construção e implantação de aplicações independentes. Para conseguir isso, é necessário uma plataforma microfrontend para fornecer uma implantação padronizada e uma integração com os processos e sites pré-existentes.

Este artigo descreve como construir uma plataforma de microfrontend e quais são os benefícios e dificuldades.

Motivos

O microfrontend certamente não é um canivete suíço para ser usado em qualquer situação. São necessários bons motivos para aceitar a complexidade extra e os custos de integração. Além disso, podem haver outros motivos:

  • Os desenvolvedores recém-contratados precisam ser produtivos quase que imediatamente, sem qualquer fase de introdução, de preferência usando tecnologias que estão acostumados;
  • As aplicações de negócios tendem a durar mais de 5 anos e deseja-se mitigar o problema da dependência de um único web framework, que pode deixar de existir daqui a algum tempo;
  • A empresa pode ter investido em alguns sistemas comerciais como CMS, CRM ou um Portal, e é preciso evitar que as aplicações desenvolvidas internamente se tornem inúteis quando o sistema for substituído. Além disso, é necessário que as aplicações existentes também sejam integradas aos novos sistemas;
  • Será desenvolvido uma enorme aplicação web que simplesmente não pode ser mantida como um monólito por um período de tempo longo;
  • Necessidade de adicionar novos recursos a uma aplicação legada, que não é mais mantida ou nenhum desenvolvedor está mais disponível.

O que é um microfrontend?

Como atualmente o "microfrontend" é uma palavra da moda, este termo será esclarecido conforme o contexto deste artigo.

Algumas definições que podem ser encontradas na internet são:

Estas ideias não são novas. O conceito de construção de sites a partir de pequenas aplicações web integradas via hiperlinks ainda é muito comum. No passado, existiram vários outros conceitos de renderização de páginas de blocos de construção menores e independentes, como o Java Portlets.

Mesmo que atualmente o termo microfrontend seja usado para se referir a aplicações JavaScript modernas, existem diversas abordagens possíveis. Portanto, neste artigo, esse termo se refere a aplicações que:

  • São basicamente um JavaScript Rich Client (um SPA ou um componente Web) que é executado isoladamente em um nó DOM arbitrário e é o menor e mais eficiente possível;
  • Não instalam bibliotecas globais, fontes ou estilos;
  • Não assumem nada sobre o site que está sendo incorporado, em especial, não assumem nenhum caminho existente, portanto, todos os caminhos básicos para os recursos e APIs devem ser configuráveis.
  • Possuem uma interface bem definida que consiste na configuração de inicialização e algumas mensagens em tempo de execução (eventos);
  • Devem ser instanciados para que possam existir diversas vezes na mesma página, com configurações diferentes;
  • De maneira ideal, herdam os estilos compartilhados do site e enviam apenas os estilos absolutamente necessários para definir o layout.:

Esses requisitos técnicos levam a propriedades muito específicas:

  • Esse tipo de aplicação executa praticamente em qualquer lugar, sendo necessário fornecer uma pequena camada de integração para configuração e inicialização. Pode-se até mesmo empacota-la como uma aplicação mobile ou integrá-lo a um fat client via Web View;
  • É flexível no uso, pois o comportamento pode ser configurado e idealmente se adapta ao estilo do site que está sendo hospedado;
  • Nenhum tipo de lock-in com fornecedores, pelo menos quando é utilizado um framework principal para criar o SPA ou o componente web. Não é necessário se acoplar ao framework, basta usar um diferente para o próximo microfrontend ou até mesmo reescrever os existentes, o que teoricamente deve ser fácil pois são pequenos;
  • Dentro das restrições dadas, os desenvolvedores podem adaptar os frameworks e as ferramentas usadas com cada novo microfrontend, portanto, decisões ruins de design não tem um grande impacto;
  • Como não deve haver dependência do site com o local onde os microfrontends estão hospedados, podem ser desenvolvidos completamente isolados, como qualquer SPA normal seria.

O que isso significa em relação aos requisitos de negócios?

  • Podem ser definidos microfrontends específicos que atendem a uma necessidade de negócio, como por exemplo para Pesquisa de cliente, Detalhes do Cliente e Produtos do Cliente, que podem ser reutilizados em diferentes contextos de negócio, tal como novos negócios, processos de manutenção, processos de atendimento ao cliente, etc;
  • Diversos microfrontends podem ser combinados para a geração de dashboards específicos do usuário e fluxos de processo, dessa forma, oferecem suporte para diferentes visualizações e processos de negócios

Integração de microfrontends:

A integração de microfrontends é possível em diferentes níveis:

  • No momento do build, o que resulta num monólito em tempo de execução e não permite implantações independentes;
  • No lado do servidor, com algum template engine (como o Mosaic), que permite implantações independentes, mas não carrega e descarrega em tempo de execução;
  • Em tempo de execução no lado do cliente, que é o método mais poderoso e que será discutido neste artigo.

Do ponto de vista puramente técnico, a integração do lado do cliente não é complexa. Supondo que o microfrontend empacotado exponha alguma função de inicialização global, pode ser tão simples quanto carregar o pacote e chamar a função abaixo:

Mas então rapidamente surgem algumas questões:

  • De onde vem o customerId? Talvez deva ser passado em tempo de execução de algum outro microfrontend, de uma pesquisa por exemplo. Mas como?
  • O showDeleteButton provavelmente depende de algumas funções de segurança, mas de onde vêm e como podemos mapeá-lo para tais permissões mais refinadas?
  • Como podemos acessar a API de backend que pode não ser acessível a partir do cliente?
  • Onde armazenamos a configuração da instância do microfrontend?.

Para enfrentar esses e outros problemas semelhantes, iniciamos uma plataforma de integração para microfrontends e a disponibilizamos como open source há algum tempo: o Servidor Mashroom..

Para integrar um microfrontend existente ao Mashroom, onde basta adicionar alguns metadados ao package.json e um método de bootstrap com uma assinatura específica. O servidor pode registrar pacotes NPM locais ou microfrontends executando em servidores remotos que expõem o /package.json.:

Para o exemplo acima, é necessário somente adicionar a configuração a seguir no package.json:

E um método bootstrap global:

Como se pode ver, o método bootstrap leva algumas coisas a mais do que apenas um simples objeto de configuração. O portalAppSetup também contém informações do usuário e um objeto de permissões. O clientServices é utilizado para injetar handlers nos serviços comuns, como o barramento de mensagem, que pode ser usado para trocar mensagens por meio de publish/subscribe. O uso desses serviços é totalmente opcional.

A seguir uma página de exemplo com vários microfrontends escritos com diferentes estruturas:

Construindo uma plataforma com Kubernetes e servidor Mashroom

Primeiro, precisamos estabelecer no que consiste uma unidade de implantação (uma imagem Docker):

  • Os recursos do microfrontend (JS, CSS, ativos);
  • Um servidor HTTP para fornecer os recursos;
  • Normalmente, uma API REST para simplificar a comunicação com os backends reais (um backend para frontend);
  • Talvez uma página HTML ou um modelo que permita chamar o microfrontend.

A implantação e operação de unidades no Kubernetes não é muito diferente de implantar e operar os microservices, e as mesmas práticas recomendadas podem ser aplicadas. Na realidade, se já existe uma plataforma para microservices, ela também pode ser utilizada para os microfrontends.

O componente que está faltando é o que permite integrar o microfrontend implantado separadamente nas páginas ou nos cockpits. Este componente requer todos os recursos esperados de qualquer Portal:

  • Autenticação e autorização baseada em função;
  • Uma maneira de definir sites e páginas;
  • Suporte para temas.:

Mas também requer um conjunto de recursos muito específicos para a abordagem de microfrontend:

  • Um registro de microfrontend e a capacidade de verificar o cluster Kubernetes em busca de novas implantações;
  • Uma maneira de compor páginas de microfrontends (estaticamente ou dinamicamente);
  • Proxy automático de chamadas de API para que os microfrontends possam alcançar os backends pelo Portal (na maioria dos casos, não acessíveis diretamente de fora do cluster);
  • Uma maneira de tornar os recursos estáticos (por exemplo, imagens) acessíveis para o microfrontend;
  • Capacidade de estabelecer comunicação entre os microfrontends em uma página, ou além disso.

É aí que o servidor Mashroom entra em jogo. Ele suporta todos esses requisitos e tem uma arquitetura de plugins muito flexível e vários plugins existentes para autenticação, persistência, mensagens e monitoramento.

Portanto, a plataforma poderia ser assim:

O Microfrontend Proxy permite que os sistemas legados busquem os recursos do microfrontend e se conectem às APIs na plataforma. Os serviços comuns também podem ser usados ​​pelos microfrontends.

Fornecemos um repositório GitHub com scripts para configurar essa plataforma no Google Kubernetes Engine com apenas alguns minutos. Deve ser simples adaptá-lo a outras plataformas Kubernetes.

Lições aprendidas

Construir o servidor Mashroom e usá-lo em projetos forneceu percepções sobre aspectos técnicos e não técnicos que precisam ser considerados ao adotar uma arquitetura de microfrontend.

Estrutura organizacional

Semelhante à construção de microservices, a chave é permitir que as equipes de DevOps criem e operem os microfrontends da forma mais independente possível. Lembre-se de que o objetivo deles é enviar algo de valor para a equipe de negócios o mais rápido possível. Para permitir que trabalhem com eficiência e rapidez em relação à plataforma e à complexidade de integração, deve haver uma equipe da plataforma para apoiá-los. Esta equipe é responsável pela plataforma e por manter em mente todas as diretrizes necessárias para que novos microfrontends se integrem sem nenhum problema. Idealmente, as equipes de DevOps podem planejar, desenvolver e enviar um novo microfrontend sem incomodar a equipe da plataforma. Além disso, devem ser capazes de acessar registros e monitorar problemas operacionais por conta própria. Caso contrário, a abordagem não será escalonada e a equipe da plataforma ficará sobrecarregada.:

A seguir, um diagrama simplificado da estrutura organizacional:

O que falta no diagrama é a governança. Especialmente se estiver usando essa abordagem em grande escala, é necessário alguma supervisão para evitar o crescimento descontrolado e maximizar a reutilização de microfrontends existentes. Caso já existam muitos microservices ou um catálogo de WebService, poderia ser criado algo muito semelhante para os microfrontends.

 

Experiência do usuário

O design da interface e a experiência dousuário são as partes mais críticas ao construir sistemas com microfrontends. Isso ocorre pois uma UI (interface de usuário) completamente heterogênea com cores, fontes e até mesmo comportamentos diferentes, é difícil de ser aceita pela área de negócios e de usuários.:

A seguir algumas recomendações:.

  • Certifique-se de que os desenvolvedores entendam que um microfrontend nunca deve conter qualquer estilo, exceto o que é exclusivo para o microfrontend;
  • Ao mesmo tempo, forneça um CSS (um tema) que pode ser aplicado durante o desenvolvimento para que possam ver como ficará quando integrado;
  • Defina todos os componentes comuns da UI em CSS puro (ou SASS, LESS, etc). Dessa forma as equipes ainda podem utilizar qualquer framework JavaScript, usando as classes CSS predefinidas;
  • Certifique-se de ter um guia de UI expressivo que abrange não apenas os elementos de UI individuais, mas também os padrões de interação mais importantes.

O estilo e a UX introduzem o acoplamento entre as equipes, mas não há como contornar isso. Devido à própria natureza do CSS, podemos argumentar que o acoplamento é, na verdade, muito fraco.

Conversando com área de negócios

Ao conversar com a área de negócios sobre essa abordagem e os prós e contras, deve-se destacar que os microfrontends permitem que se concentrem a discussão na funcionalidade de negócios necessária. Poucos requisitos não funcionais precisam ser discutidos antes de começar a implementação.

Outras vantagens que pode ser mencionadas são

  • A abordagem torna muito provável que o departamento de TI possa encontrar desenvolvedores para iniciar a implementação rapidamente, uma vez que não precisam de habilidades específicas de um framework ou conhecimento sobre os sistemas existentes (considerando que as APIs de backend estão bem documentadas);
  • Com o catálogo de componentes existentes, o desenvolvimento de novas UIs será mais rápido. Por exemplo, se já existe um microfrontend que mostra alguns dados básicos do cliente, não é necessário uma nova implementação dessa parte, economizando tempo e custos;
  • Configuráveis e com vários temas, os microfrontends podem ser reutilizados para diferentes canais de vendas e subsidiárias, mesmo se o comportamento e a "aparência" precisarem ser bem diferentes.

Granularidade do microfrontend

A pergunta que se ouve com frequência é: "Como quebramos os microfrontends?". Neste aspecto, existem algumas diferenças em relação aos microservices, no qual são identificados os limites do modelo de domínio e a sobreposição de responsabilidades são evitadas. No mundo do microfrontend, por outro lado, a reutilização e a escalabilidade são as principais preocupações e se existir alguma redundância não há tanto problema assim..

Outra diferença importante é quem vai decidir: Como os microservices ficam ocultos no backend e cobrem os processos de negócios com propósitos genéricos, as decisões são tomadas por arquitetos corporativos ou de software. Os microfrontends, ao contrário, ficam na visão do usuário, onde designers de UI e UX Experts são os responsáveis.

Como os designers de UI geralmente trabalham com componentes reutilizáveis, já podem ter identificado os microfrontends sem nem mesmo saber. Podem até ter nomes que usam para se comunicar com a área de negócios. Portanto, os microfrontends devem aparecer quase naturalmente em um design existente. Esse é outro motivo pela qual a abordagem de microfrontend requer um forte foco na UI/UX.

Certifique-se de que os designers de UI estão cientes dos microfrontends existentes, para que os considerem como um componente fixo e não realizem quaisquer alterações. Isso também levará a UIs mais padronizadas em toda a empresa.

Se tiver dificuldades para decidir como decompor um design existente, as perguntas a seguir podem ajudar:

  • Qual componente pode ser reutilizado em outras aplicações?
  • Qual componente faria sentido como uma aplicação independente?
  • Se mencionar o nome do componente para a área de negócios, eles conseguem imaginá-lo?

Assim que tiver estabelecido uma plataforma de microfrontend, pode-se notar uma abordagem de trás para frente, onde as equipes começam a implementar visualizações para os microservices, mesmo sem saber se e onde serão usados. Essa é uma abordagem válida, mas essas visualizações podem precisar de algumas alterações assim que forem realmente integradas em algum lugar.

Modelos de início rápido

Como falado anteriormente, mesmo que exista a necessidade de regras para implantação, UI/UX e integração, há um alto nível de liberdade quando se trata do desenvolvimento de um novo microfrontend. Portanto, a maioria das equipes será grata por alguma estrutura e um ponto de partida..

Faz sentido fornecer alguns projetos de modelo de microfrontend para acelerar o processo. Eles não devem abranger apenas o código-fonte real, mas também o servidor que irá entregar os recursos (pode ser um Backend-For-Frontend), o Dockerfile e todos os pipelines de construção e implantação necessários. Basicamente, tudo o que é necessário para enviar o microfrontend para a produção o mais rápido possível.

Isso também reduz a quantidade necessária de diretrizes. E permite diminuir o número de frameworks diferentes usados nos microfrontends, fornecendo apenas um projeto modelo baseado em algum framework de UI comum. Uma vez que a maioria das equipes apenas utilizará este modelo, isso levará a uma base de código bastante homogênea, o que geralmente atenua o temido risco de ter diversos frameworks em uso e facilita o controle pelos gerentes de TI.

Segurança

A segurança possui vários níveis e aspectos. O principal deles que será abordado neste artigo é a autenticação e autorização. Para os outros, como XSS, injeção de SQL, ataques DOS, uma plataforma de microfrontend não é diferente de outras aplicações web e também deve ser protegida.).

Portanto, a segurança é crucial, mas também complexa e grandes empresas tendem a ter estratégias de autenticação e autorização diferentes, além de vários provedores de identidade. Idealmente, tanto os microfrontends como os desenvolvedores, não precisam se preocupar com isso.

Faz sentido que a aplicação web que hospeda os microfrontends realize a autenticação. E também alguma autorização básica, como verificar se o usuário tem permissão para visualizar uma página ou determinados microfrontends.

Mas e em relação às permissões refinadas em um microfrontend? Uma boa abordagem é definir apenas permissões abstratas para o microfrontend. Basicamente, apenas chaves como deleteCustomer ou assignDiscount. A aplicação hospedeira é então responsável por passar um objeto de permissão junto com a configuração de inicialização, por exemplo:

E o Microfrontend pode ocultar o botão de exclusão caso permission.deleteCustomer for falso.

Essa abordagem empurra a responsabilidade de determinar as permissões corretas para a aplicação hospedeira. O Mashroom oferece essa funcionalidade pronta para uso: Se adicionar um mapeamento entre a chave de permissão e as funções do usuário à definição do plug-in dentro do package.json, as permissões são determinadas e passadas automaticamente. Essa definição pode ter a seguinte aparência:

O interessante é que se o microfrontend não lida com tokens de acesso ou funções, pode até mesmo ser integrado a sistemas legados que utilizem um conceito diferente e antigo. A camada de integração precisa apenas determinar as permissões.:

Mas desabilitar os botões com base em alguma propriedade do JSON não é algo muito seguro. O usuário pode facilmente manipular o DOM e fazer uma solicitação de exclusão. Portanto, devem haver verificações no lado do backend também. Basicamente, existem duas possibilidades:

  1. A aplicação hospedeira adiciona um token de acesso ao encaminhar a solicitação para o backend. Assim, o servidor pode verificar a permissão com base nas próprias regras;
  2. Cada microfrontend tem o próprio BFF (Backend-For-Frontend) e que apenas repete as verificações no lado do servidor com base nas mesmas chaves de permissão.

A primeira abordagem é muito difícil de implementar em um ambiente heterogêneo. Pode ser difícil gerar tokens de acesso se a aplicação hospedeira for algum sistema legado ou se houver vários provedores de identidade..

Normalmente usamos a segunda abordagem e acessamos o sistema de backend por meio de contas de serviço, que é a única maneira em muitas empresas. O Mashroom pode encaminhar automaticamente as permissões calculadas por meio do header HTTP para os BFFs, e então os desenvolvedores podem simplesmente verificar as solicitações do microfrontend contra as chaves de permissão do header.

A abordagem é semelhante ao desenho a seguir, onde o Portal pode ser substituído por qualquer outra aplicação hospedeira:

Comunicação Microfrontend

Curiosamente, ao conversar com desenvolvedores sobre microfrontends, uma das primeiras perguntas sempre está voltada à comunicação. Como os microfrontends podem conversar entre si?.

Por experiência, os microfrontends são bem tímidos e não gostam de conversar. Vivenciamos isso com projetos do Java Portlet há muitos anos atrás. Mesmo que conversem, não vão falar muito, pois passar estruturas de big data significa um acoplamento forte e queremos evitar isso.

Portanto, a recomendação seria:

  • Use um mecanismo simples de publish/subscribe para se comunicar (o Mashroom possui um barramento de mensagem de frontend);
  • Passe apenas pequenas mensagens JSON, como algumas informações de estado ou chaves. Resista ao desejo de usar a comunicação para compartilhar o estado, como alguns dados do cliente, pois normalmente não haverá um modelo unificado em toda a empresa. Passe apenas o ID do cliente, mesmo que isso signifique que os mesmos dados tenham que ser carregados várias vezes em uma única página.

Bibliotecas compartilhadas

A questão das bibliotecas compartilhadas surgirá em dois níveis:.

  1. Pode-se considerar a criação de uma biblioteca com componentes comuns de UI ou funcionalidade do BFF e compartilhá-la entre as equipes de desenvolvimento;
  2. Pode fazer sentido compartilhar bibliotecas em tempo de execução no navegador, por exemplo, as bibliotecas do framework de UI, que não precisarão ser enviadas por cada um dos microfrontends que as utilizam.

Tenha cuidado com o primeiro item mencionado acima. Apesar de fazer sentido do ponto de vista da engenharia de software, introduz um acoplamento e dependências entre as diferentes equipes que poderão ter de esperar umas pelas outras e o risco da equipe da plataforma se tornar um gargalo pode vir a se tornar realidade. Caso tenha desenvolvido bibliotecas comuns, torne o seu uso opcional (o desenvolvedor deve vê-las apenas como uma opção), pois dessa forma não perderá a capacidade de começar o processo do zero..

O que realmente pode ajudar é a uma implementação de referência para os componentes da UI definidos no CSS. Os desenvolvedores podem usá-la diretamente ou como um modelo se usarem um framework JavaScript diferente. Além disso, essa biblioteca pode funcionar como um showcase, o que é muito útil para novos membros da equipe.

Sobre o segundo item: Atualmente, a maioria das bibliotecas de SPA ocupam um espaço pequeno (até mesmo o Angular, graças à compilação AOT). Portanto, carregar em tempo de execução várias vezes, para alguns microfrontends em uma página, não é um grande problema. Mas não parece a coisa certa a se fazer. Se precisar de muitas bibliotecas adicionais ou não puder evitar enormes bibliotecas de componentes de UI, certamente verá um impacto negativo no desempenho. Nesse caso, considere o uso do mecanismo Web DLL do webpack ou o plug-in Mashroom DLL. Mas isso só tem efeito se todas (ou pelo menos a maioria) das equipes de desenvolvimento concordarem com as mesmas versões do framework ou com uma espécie de pacote de dependência, o que introduz, novamente, certo acoplamento.

Desempenho

Existem poucos problemas de desempenho que surgem apenas por causa da abordagem de microfrontend, mas os problemas podem se multiplicar. Portanto, certifique-se de que todos se esforcem para fazer SPAs pequenos e de alto desempenho e mantenha baixo o número de componentes que precisam ser carregados.

Além disso, seria interessante seguir as orientações:.

  • Certifique-se de que todos pensem duas vezes antes de usar alguma biblioteca de componentes de UI grande. Nesse aspecto, se torna útil uma implementação de referência de componente;
  • Concorde com a utilização de uma fonte de icones, caso a empresa não forneça;
  • Continue usando Web DLLs como uma opção;
  • Uma vez que a abordagem de microfrontend pode levar a um nível diferente de over-fetching, onde os mesmos dados são carregados várias vezes, pode ser uma boa ideia adicionar alguns mecanismos de armazenamento em cache, tanto no lado do cliente quanto no lado do servidor.

Questões em aberto

O roteamento como normalmente é utilizado nos SPAs é um pouco problemático. Como os microfrontends da página devem "compartilhar" a URL do navegador? A abordagem mais simples é proibir qualquer manipulação de URL. Isso funciona se não for um problema perder a navegação no browser, o que não parece ser para a maioria dos usuários acostumados com aplicações empresariais. O Mashroom também oferece um serviço para codificar o estado na URL, mas isso causa um acoplamento à aplicação hospedeira, o que não é o ideal. Portanto, pode ser necessário definir um novo padrão em como os microfrontends podem compartilhar o espaço da URL.:

Além disso, seria útil adaptar o padrão de registro de serviço para microfrontends. O Mashroom tem um registro embutido, mas seria melhor usar algum serviço externo como o Eureka. Adicionar metadados a cada microfrontend que descreve os recursos permitiria casos de uso muito além dos microfrontends organizados estaticamente:

  • Ao invés de colocar um microfrontend específico, pode-se apenas descrever os recursos necessários e a aplicação hospedeira pode procurar dinamicamente o melhor candidato;
  • Criar cockpits completamente dinâmicos que crescem conforme o usuário deseja ver mais dados. O sistema apenas procura microfrontends que são capazes de exibir ou editar algum tipo de dados e os carrega;
  • Analisar o e-mail de um cliente (ou basicamente qualquer tarefa) e apresentar ao usuário uma página personalizada que contém tudo para cumprir esta tarefa;
  • Usar metadados para selecionar diferentes microfrontends para diferentes grupos de usuários na mesma página. Pode ser usado para implantações canário ou testes A/B.

Resumo

Para ser claro, a construção de uma plataforma microfrontend exige um grande esforço. Não só do ponto de vista técnico, mas também empresarial, pois será necessário envolver a área de negócios, especialistas em UI/UX e todos do departamento de TI. Os envolvidos precisam entender o conceito básico, as restrições e os benefícios. Portanto, não é apenas uma decisão arquitetural, mas um processo de transformação no qual é necessário convencer muitas pessoas.

Além disso, a abordagem de microfrontend em si, mesmo que em escala mínima e sem uma plataforma completa, possui algumas desvantagens. Será necessário um esforço extra na integração para obter uma experiência de usuário perfeita e evitar problemas de desempenho, e também resolver alguns problemas que não existiam nos sistemas monolíticos, como por exemplo, o roteamento..

Por outro lado, os microfrontends resolvem muitos problemas, especialmente nos departamentos de TI de grandes empresas: A incapacidade de reagir rapidamente a novas ideias e requisitos de negócios, os altos custos pois a mesma funcionalidade da UI precisa ser implementada várias vezes com tecnologias diferentes, os sistemas complexos que exigem um longo período de treinamento dos desenvolvedores até que se tornem produtivos e, o medo constante de tomar decisões erradas de estrutura, que bloqueiam a inovação.

Mais importante ainda, a abordagem microfrontend pode ajudá-lo a ocultar a complexidade não funcional do cenário de TI, permitindo que se concentre nas necessidades de negócios.

Sobre o autor

Jürgen Kofler é desenvolvedor de software e entusiasta da web. Ele é apaixonado por lidar com a complexidade e trazer a diversão de volta ao desenvolvimento empresarial. Nos últimos anos, se concentrou em estratégias para compor sites a partir de blocos de construção menores e independentes, sejam Portlets, Widgets ou Microfrontends. Atualmente está trabalhando em uma plataforma Microfrontend de grande escala em Viena.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT