Arquitetura micro frontend

Compartilhe

Compartilhar no facebook
Compartilhar no google
Compartilhar no twitter
Compartilhar no linkedin

Tente imaginar o seguinte cenário: uma aplicação front-end de médio ou grande porte, de alta escalabilidade e com múltiplos times de desenvolvedores atuando em sua estrutura, que demanda ajustes triviais e também implementação de novas funcionalidades com uma frequência relativamente alta. 

Para manter e suprir tudo isso faz-se necessária a distribuição de responsabilidades por escopo dentro da aplicação para cada time, além da necessidade de escalar novos times.

Como podemos evoluir a stack de tecnologias de uma aplicação como essa de um modo não obstrusivo entre os times? E como podemos mitigar a integração de novos desenvolvedores nesse processo? 

A proposta de uma arquitetura micro frontend é exatamente tentar resolver questões como essa.

A ideia desse artigo é entendermos algumas das principais motivações para se implementar uma arquitetura micro frontend. Em um outro momento podemos nos aprofundar mais no assunto e discutirmos detalhes técnicos mais avançados.

Aplicações monolíticas

Uma aplicação monolítica consiste em um codebase mais complexo, centralizado em uma única unidade, ou seja, em um único repositório. Basicamente não há distinção estrutural para back-end e front-end, e tudo coexiste ali. 

Isso pode soar como algo relativamente arcaico para os dias de hoje, e de fato é. Porém, houve um tempo em que esse tipo de estrutura era amplamente utilizada, razão de hoje termos um bom número de aplicações legadas dessa forma.

Podemos levantar alguns problemas relevantes relacionados a esse tipo de estrutura:

  • Como o codebase é único, logicamente a sua complexidade tende a aumentar de maneira exponencial a cada nova iteração no projeto, seja através de uma simples correção (bugfix) ou através de uma nova funcionalidade implementada. Com isso, é muito provável que tenhamos um impacto negativo na escalabilidade de times, dificultando a integração de novos desenvolvedores, que, consequentemente, precisarão cada vez mais de mais tempo e dedicação para o entendimento de todo o escopo do projeto.
  • Como a complexidade de código e o acoplamento entre os módulos da aplicação são elevados, há maiores riscos e dificuldades nas integrações e entregas contínuas (CI/CD), além da necessidade de um alto nível de coordenação e comunicação para lidar com novas funcionalidades.

Micro serviços

Com o passar doo tempo, surgiu o conceito de micro serviço. Isso ajudou a melhorar o cenário caótico de código que aplicações monolíticas traziam. A partir desse momento, podíamos ter módulos back-end interdependentes, com codebases em repositórios distintos.

Com os micro serviços, parte dos problemas de estruturação de código back-end foram resolvidos. Porém continuávamos a ter um código front-end cada vez mais acoplado e sem perspectiva de evolução técnica. 

Foi então que, em 2016, o ThoughtWorks Technology Radar mencionou pela primeira vez o termo micro frontend. A ideia era trazer conceitos de micro serviço para o mundo front-end.

ASSESS – “We’ve seen significant benefit from introducing microservice architectures, which have allowed teams to scale delivery of independently deployed and maintained services. However, teams have often struggled to avoid the creation of front-end monoliths. We’re seeing an approach emerge that our teams call micro frontends.”

2016, ThoughtWorks Technology Radar

O grande desafio técnico era conseguir fatiar uma aplicação front-end monolítica em pequenas partes interdependentes (micro aplicações), assim como acontecia no back-end com os micro serviços. 

Porém, no caso de uma aplicação front-end, havia particularidades que dificultavam a implementação desse conceito, como compartilhamento de estados, coexistência de múltiplos frameworks/libs JavaScript em uma mesma página, etc.

A partir daí, vários experimentos com diferentes técnicas e ferramentas foram feitos mundo afora. 

Uma das técnicas usadas foi a implementação de micro aplicações usando iframes, mas suas limitações com postMessage não deram muito certo para o contexto de aplicações baseadas em navegadores web.

Um modelo que vem sendo amplamente aceito para esse tipo de arquitetura é o baseado em web components, onde as micro aplicações podem conversar entre si de maneira fluída através de eventos.

“In short, micro frontends are all about slicing up big and scary things into smaller, more manageable pieces, and then being explicit about the dependencies between them. Our technology choices, our codebases, our teams, and our release processes should all be able to operate and evolve independently of each other, without excessive coordination.”

Cam Jackson (ThoughtWorks)

Princípios do micro frontend

  • Agnóstico de tecnologia: cada time deve ser capaz de escolher e atualizar sua stack tecnológica de forma independente.
  • Orientado a micro serviço/negócio: o código de cada serviço deve ser isolado e auto-contido, tendo o seu escopo definido baseando-se no negócio.
  • Funcionalidades autônomas: cada micro aplicação deve ser capaz de executar as suas responsabilidades de maneira independente.
  • UI/UX consistentes: a experiência do usuário deve ser totalmente transparente entre as micro aplicações.

Benefícios do micro frontend

  • Codebases desacoplados e simplificados.
  • Progressive enhancement (strangler pattern).
  • Deploys independentes.
  • Times mais coesos e autônomos.

ADOPT – “Micro frontends have continued to gain in popularity since they were first introduced. We’ve seen many teams adopt some form of this architecture as a way to manage the complexity of multiple developers and teams contributing to the same user experience. We’re confident this style will grow in popularity as larger organizations try to decompose UI development across multiple teams.”

2019, ThoughtWorks Technology Radar

Dependendo do cenário, os ganhos ao se implementar uma arquitetura micro frontend podem ser inúmeros: 

  • Times passando a ter uma maior autonomia nas entregas.
  • Deploys independentes (sem a necessidade de haver um build da aplicação monolítica a cada entrega).
  • Menor curva de adaptação para novos desenvolvedores (que agora requerem menor tempo de integração, necessitando entender inicialmente somente o escopo da micro aplicação).
  • Maior flexibilidade para evoluir ou até mesmo mudar a stack de tecnologias de determinada parte da aplicação, dentre outras vantagens.

Porém, devemos tomar alguns cuidados imprescindíveis ao se trabalhar com uma estrutura como essa.

Por exemplo, os elementos recorrentes de interface (UI) e a experiência do usuário (UX) devem ser transparentes no resultado final, ou seja, a navegação e interação do usuário na aplicação devem ser consistentes, independente do número de micro aplicações existentes. 

Outro ponto importante que vale a nossa atenção é saber lidar de maneira performática com a coexistência de diferentes versões de dependências utilizadas em comum entre as diferentes micro aplicações.

Conclusão

É muito importante entendermos que uma arquitetura micro frontend não é nenhuma bala de prata. É essencial tomarmos uma dose de cautela antes de pensarmos em adotar esse tipo de arquitetura. 

São várias as variáveis que podem definir a necessidade de se implementar ou não micro frontend, e questões como tamanho do time, escalabilidade da aplicação e complexidade do negócio, por exemplo, devem ser levadas em consideração.

Referências

https://thoughtworks.com/radar/techniques/micro-frontends

https://martinfowler.com/articles/micro-frontends.html

https://micro-frontends.org

https://single-spa.js.org

James Clébio

James Clébio

Desenvolvedor front-end há mais de 10 anos, com sólidos conhecimentos nos pilares da área (HTML, CSS e JavaScript) e experiência em tecnologias e ferramentas modernas de desenvolvimento.

Deixe um comentário

Categorias

Posts relacionados

Siga-nos

Baixe nosso e-book!

%d blogueiros gostam disto: