Micro-frontend?! 🤔
O que comem? Onde vivem? Como se reproduzem? Isso e muito mais hoje no…
Afinal o que é Micro-frontend ?
Micro-frontend se trata de um conceito de arquitetura para aplicações frontend, basicamente reutiliza o mesmo conceito de micro-serviços. Quando comecei as pesquisas sobre o assunto para o artigo, pensei que encontraria uma tonelada de artigos e tutoriais sobre o assunto, mas foi aí que me enganei mesmo sendo um conceito que vem sendo discutido desde 2017. Acredito que por se tratar de uma questão mais estrutural, ou seja, é mais difícil(um pouco) de se encontrar conteúdo prático e o que encontrei ainda era muito abstrato sem exemplos concretos. O próprio site de referência para micro-frontend explica bem o conceito, porém quando se trata de pôr a mão na massa, temos pouco exemplos e(ou) tutoriais.
Lendo um pouco mais percebi o que micro-frontend é uma nova arquitetura para projetos frontend, em que podemos dividir o front em diversos módulos independentes, mas funcionando como se fosse uma aplicação única(monólito). Levando em conta o que pesquisei, acredito que os pilares centrais do conceito de micro-frontend são:
- Independencias dos módulos
- Agnóstico às tecnologias(Frameworks)
- Organização da aplicação
Como posso começar a construir a estrutura de um micro-frontend ?
Como disse anteriormente, apesar de ser uma ideia que vem sendo discutida há um bom tempo, não encontramos muitos casos de usos ou exemplos que poderíamos nos basear. Como se trata de um tipo de arquitetura de projetos isso nos deixa abertos a tentar aplicar o conceito, mas sempre pensando no dia a dia e na realidade dos projetos em que desenvolvemos. Por isso não temos muitas “receitas” para construir a arquitetura, mas temos algumas ferramentas e abordagens de se construir o projeto pensando em micro-frontend, que podem nos ajudar nesta árdua tarefa.
Quais são as ferramentas e abordagens que podem nos auxiliar
Podemos construir a estrutura utilizando web-components. A maioria dos frameworks modernos, ou melhor, os 3 principais frameworks frontend(Vue, React e Angular) proveem maneiras de escrever nossas aplicações ou componentes e compilar os mesmo para web-components.
Uma segunda maneira, seria construir cada módulo apartado e por meio de container disponibilizar a aplicação numa rota e por meio de um proxy reverso agregar todos os módulos numa url final. É uma solução mais robusta, porém que agrega certa complexidade a solução.
Outra forma seria utilizar um “meta-framework”, em que é necessário que cada módulo tenha um build/output em Javascript que esse “meta- framework” possa importar e agregar todos na mesma página e o single-spa registra e gerência as rotas da aplicação, um exemplo disso é o single-spa que falarei um pouco mais a seguir.
E a última forma seria hospedar cada módulo em hosts diferentes e por meio de iframes fazer a integração numa única página. Mas por ter problemas com a usabilidade essa estratégia é bem desencorajada.
Já escolhi a ferramenta/abordagem o que fazer agora?
Agora devemos analisar nossa aplicação e começar a traçar uma estratégia para a migração, devemos definir algumas coisas:
Delimitar a aplicação
Acredito que a parte de separação dos módulos é umas das importantes fases da migração do monólito para o micro-frontend, devido ao conceito central de separação e independência dos módulos. Devemos tomar cuidado para não atomizar muito a aplicação e acabar dividindo a aplicação em “micro-monólitos”. Para facilitar isso podemos nos basear na API da aplicação para delimitar os módulos, assim delimitando a responsabilidade de cada módulo.
Com isso podemos começar, a pensar como ficará o deploy e organizar os repositórios de cada módulo.
Compartilhamento de componentes
Caso não tenhamos um design system, devemos compartilhar estes componentes comuns para a aplicação, para isso podemos utilizar ferramentas de monorepo, links(yarn, npm) ou publicar o repositório no npm e utilizar como uma dependência instalada via npm. Podemos utilizar web components como alternativa para evitar repetição de código.
Comunicação entre os módulos
O ideal seria que este tipo de comunicação não fosse feita, mas como as nem sempre isso pode ser possível, devemos pensar em uma forma de compartilhar dados entre as micro-apps, para isso podemos utilizar o localStorage/sessionStorage, pensando também em um sistema de eventos para compartilhar isso, mas devemos tomar cuidado ao utilizar custom events no Javascript, para isso temos como alternativa o RxJs.
Avaliar o legado(caso exista)
É comum as aplicações terem legados, o angularjs e o jquery que o digam. Devemos avaliar isso e levar em consideração a complexidade do código legado e verificar se é possível migrar para uma tecnologia mais atual ou separar em módulo e integrar no micro-frontend para posteriormente migrar.
Definir uma estrategia ou roteiro para a migração
Depois de definir os módulos, devemos verificar qual a prioridade de cada um, nos micro-frontend, pelos menos nas abordagens feitas via proxy reverso ou singespa, primeiramente deveríamos começar a partir de um root que funcionaria com um wrapper contendo todos os sub-módulos, depois um módulo comum a toda aplicação(shared) que funcionaria como uma home e ai sim depois partiríamos para os módulos, e nos módulos teríamos outras prioridades para migrar(login, configurações, acessos, etc).
Um pouco mais sobre Single SPA
Uma das ferramentas que podem nos auxiliar na construção de um micro-frontend, é o single-spa. Onde trabalho optamos por utilizar este “meta-framework” devido ter uma documentação aceitável com exemplos e formas de como integrar com os frameworks, e também construir uma estrutura com o single-spa não é tão complexo como em uma estrutura utilizando proxy reverso. E o single-spa integra-se aos principais frameworks front-end do mercado. Basicamente é como se importasse-mos tags script todos os bundles finais dos módulos num index.html e utilizando a biblioteca do single-spa junto da historyAPI para fazer a o registro de cada módulo e a gestão do roteamento exibindo cada módulos para sua respectiva rota.
A principal desvantagem do single-spa perante o “aproch” do proxy reverso é ficar refém da ferramenta, e dependendo da comunidade para atualizar a biblioteca para integrar com as versões mais recentes dos frameworks frontend e corrigindo os eventuais bugs.
Exemplo utilizando single-spa
Micro-frontend é o futuro ?
Apesar de ser um conceito que já está na praça um tempo razoável, deveríamos ter mais cases/inputs sobre esta nova forma de estrutura para os projetos frontend, entretanto não seria o micro-frontend a solução final para nossos problemas com o velho e popular monólito. Confesso que como desenvolvedor fico muito entusiasmado com novas ferramentas e conceitos, entretanto devemos sempre analisar o nosso contexto atual(time, momento da empresa, pros e contras da estrutura atual da aplicação) para fazer estas decisões.
Eu acho muito interessante a ideia do micro-frontend o principalmente pela a independência que temos nos módulos, mas não diria que esta vai ser a nova forma de se trabalhar com projetos frontend e o monólito não será mais utilizado, até porque como tudo tem seus aspectos positivos e negativos, por exemplo, como, ao mesmo tempo em que temos com os micro-frontends uma melhor separação de código, se não tivermos cuidado podemos ao mesmo tempo adicionar muita complexidade ao módulos. Assim como os micro-serviços é mais uma opção que podemos ou não utilizar no nosso dia a dia para resolver alguns problemas do monólito.
Espero ter esclarecido um pouco sobre o assunto, dúvidas, reclamações, opiniões ou elogios😎, deixe sua mensagem aqui. Flw até o próximo artigo.
Referencias e repositórios sobre micro-frontend:
