Cyrillo Heimart
💻 Software Engineer ▪ Front-end @ Restaurants no iFood
Olá, pessoal, vim aqui compartilhar um pouco da minha visão sobre module federation. Primeiramente, esse é um artigo de opinião que tem única e exclusivamente o intuito de demonstrar as vantagens de incorporar uma arquitetura de micro-frontends com Module Federation. Esclareço que a arquitetura demonstrada nesse artigo, tem a finalidade de exemplificar o comportamento da tecnologia.
Além disso, Para não confundir vocês, toda vez que eu me referir a MFE, quer dizer que estou falando em micro-frontend, ok?
Motivação
Como muitos sabem ou estão prestes a descobrir, a arquitetura de MFEs apesar de estar presente no mercado desde 2011(talvez até anteriormente a isso), agora tem se tornado muito popular e cada vez mais empresas estão incorporando. Com isso, surgiram várias dúvidas em meio a comunidade das vantagens e desvantagens de migrarem da arquitetura convencional para arquitetura de MFEs utilizando Module Federation. Por conta disso, vim compartilhar um pouco da minha experiência envolvendo a tecnologia com vocês.
Mas o que é esse Module Federation?
Module Federation, como o próprio nome diz, é uma federação de módulos. Mas dããã, isso vocês já sabiam. Agora sério, Module Federation é um plugin que veio junto com o WebPack 5 para facilitar e trazer vantagens a arquitetura de MFEs, ele sanou uma das principais desvantagens em relação a arquitetura convencional e vou comentar depois de falar um pouco sobre prós e contras da arquitetura aqui embaixo, então fica por ai!
Vantagens e desvantagens da arquitetura baseada em micro-frontends
Aqui, vou trazer algumas vantagens e desvantagens em utilizar uma arquitetura de MFEs, independente da tecnologia e implementação. Obviamente não listarei todos os pontos, mas busquei trazer os principais que você deve considerar no momento de começar ou migrar sua arquitetura.
Vantagens
- É possível splitar(separar) toda a sua aplicação em vários projetos ou codebases distintas, separando responsabilidades, e permitindo que times que atuam no mesmo produto, possuam mais independência em suas atividades.
- Também torna possível que os MFEs sejam compartilhados entre aplicações, por exemplo: Um mesmo login com suas regras de negócio, pode ser compartilhado entre diversas aplicações, fazendo assim que todas respeitem uma única fonte, não tendo que reinventar a roda a cada novo projeto que venha a surgir.
- A separação em vários projetos faz com que a implementação de novas funcionalidades, correções de bugs e a manutenção do projeto fiquem muito mais fáceis devido ao desacoplamento em relação a um projeto monolítico convencional.
- Também facilita o entendimento, pois no caso de pessoas que não possuam contexto do projeto, podem entender um código muito menor do que em aplicações monolíticas.
- A publicação de um MFE sensibiliza todas as aplicações que o consomem, sem a necessidade de publicar as outras aplicações.
- Podemos publicar os MFEs completamente apartados, fazendo com que o tempo de build e release sejam bem menores.
Desvantagens
Obviamente nem tudo é feito de chocolate e preciso trazer também os principais problemas envolvendo micro-frontend para vocês.
- Algumas implementações de MFEs podem fazer com que haja duplicações de dependências entre os projetos, fazendo assim com que cada um dos MFEs necessitem de suas próprias dependências para conseguirem serem implementados. Provoco vocês a pensarem em uma aplicação com dezenas de MFEs utilizando a mesma dependência. Cada MFE teria sua dependência instalada, fazendo com que a performance da sua aplicação seja prejudicada.
- Algumas formas de implementação adicionam bastante complexidade ao projeto.
Por que migrar para o Module Federation?
Bem, como prometido, lá vai!!!
O Module federation veio para sanar a principal desvantagem que temos em arquiteturas de MFEs que é a… Tararan, PERFORMANCE. Como eu mostrei para vocês no tópico acima, na arquitetura convencional cada MFE possuem suas próprias dependências e elas não são reaproveitadas, fazendo com que cada vez que chamamos um MFE em tela, ele venha com toda sua bagagem para poder ser utilizado(já viram o problemão né?)..
O Module Federation, por sua vez, compartilha as dependências entre os MFE, fazendo com que fique a cargo do desenvolvedor decidir o que vai ser compartilhado entre eles. Então ao invés de termos diversas vezes a mesma dependência, todos eles compartilham da mesma fonte.
As dependências são compartilhadas através de uma camada compartilhada pelo webpack, denominada __webpack_share_scopes__ — Sim, é possível printar no console! =)
Deu pra entender? Não? Bora pra lousa!
Perceberam para onde as flechinhas estão apontando? Mas porque isso?
Simplesmente o Module Federation compartilha as dependências na ordem em que os MFEs são colocados em tela, então no caso do cyrillover@10.0.1, o MFE de Login, foi o primeiro a compartilhar a dependência, e no caso do caps-lock@2.0.1 foi o MFE de Cadastro.
Repararam também que a dependência caps-lock está com versões diferentes? O compartilhamento requerendo a versão fica a cargo do desenvolvedor, então devemos tomar muitoooo cuidado com o que vamos compartilhar e como. Além disso, se o desenvolvedor decidir não compartilhar a dependência, ela não será reaproveitada, como no caso da pay-day@2.0.0 que mesmo possuindo a mesma versão, não é compartilhada.
Entenderam?
Mas o MFE só compartilha dependências?
O mais interessante é parar de pensar em MFE como uma aplicação apartada, e sim, como um repositório remoto de componentes, pois agora nós só buscamos no MFE os componentes que queremos apresentar. Então um MFE pode prover vários componentes que são utilizados entre as duas aplicações. Da um bizu como fica.
Então duas aplicações podem compartilhar componentes do MFE de login. Nesse caso, caso o Hero seja alterado pelo MFE, as aplicações que o consomem vão ser sensibilizadas.
Devo utilizar Module Federation em toda aplicação?
Nananinanão, um gigantesco NÃO!
A arquitetura de aplicações costuma ser singular, ou seja, ela atende a um propósito! Então não devemos repetir a arquitetura simplesmente porque gostamos muito. Devemos construir a arquitetura de acordo com o propósito que queremos atender. Então levem em consideração as vantagens e desvantagens na hora de construir a arquitetura, pois ela vai guiar você ao sucesso ou ao fracasso do que você está construindo!
Agradecimentos
Esse foi meu primeiro artigo por aqui.
Gostaria de agradecer a você que dedicou seu tempo a ler um pouco sobre o que escrevi!! E espero que tenha sido útil!!
Fontes
Module Federation
Um abraço, até a próxima Rex`s.
