Evoluindo suas aplicações utilizando micro frontends - Caso BLiP

009048ba3b1535aa65e3e7bdb232e513?s=47 Samuel Martins
September 03, 2020
3

Evoluindo suas aplicações utilizando micro frontends - Caso BLiP

009048ba3b1535aa65e3e7bdb232e513?s=128

Samuel Martins

September 03, 2020
Tweet

Transcript

  1. MICRO FRONTENDS EVOLUINDO SUA APLICAÇÃO UTILIZANDO

  2. SAMUEL MARTINS - QUEM VOS FALA ▸ Tech Lead na

    Take; ▸ Professor nos cursos de Desenvolvimento web Full Stack e Arquitetura de Software Distribuído; ▸ Contatos: ▸ LinkedIn: https://www.linkedin.com/in/samwx/; ▸ Site/blog: https://samuelmartins.me/; ▸ Email: samuelmartins.sw@gmail.com;
  3. CASO DE USO BLIP

  4. None
  5. STACK E AMBIENTE ‣ AngularJs; ‣ Arquitetura MVVM (Model, View

    e View Model); ‣ ~50k linhas de código; ‣ Aplicação totalmente monolítica, todo o código no mesmo repositório.
  6. DIFICULDADES

  7. STACK E AMBIENTE - DIFICULDADES ▸ Comunidade abandonou o AngularJs;

    ▸ Componentes/diretivas abandonadas. Pull requests não são mais aceitos; ▸ Documentação do AngularJs abandonada e de difícil usabilidade; ▸ Componentes difíceis de testar; ▸ Alta curva de aprendizado para novos integrantes do time; ▸ Conceito de serviços do angular não favorecem o reaproveitamento de código.
  8. ‣ Falta de autonomia dos times; ‣ Deploys são mais

    sucetíveis a falhas; ‣ Deploy fica cada vez mais demorado; ‣ Aplicação totalmente amarrada a uma tecnologia; E MAIS…
  9. ECOSSISTEMA FRONTEND EM CONSTANTE EVOLUÇÃO

  10. O QUE FAZER DIANTE DESSE CENÁRIO?

  11. O QUE FAZER DIANTE DESSE CENÁRIO? ▸ Refatorar o código

    atual, utilizando a mesma arquitetura com melhorias pontuais; ▸ Refatorar todo o projeto do zero com uma nova tecnologia; ▸ Refatorar gradativamente para um novo framework; ▸ Utilizar uma arquitetura de micro frontends.
  12. MESMO CÓDIGO, OUTRA ARQUITETURA ▸ Todo código pode ser melhorado,

    mas nem todo código pode ser escrito da melhor forma; ▸ Limitações de uma tecnologia podem impor limitações ao negócio como um todo; ▸ Suporte da comunidade pode ser crucial para um framework open-source.
  13. REESCREVER O PROJETO COM UMA NOVA TECNOLOGIA ▸ Projetar um

    software do 0 de forma a adaptá-lo a uma regra de negócio já consolidada pode ser positivo; ▸ Reescrever toda a lógica de negócio pode não ser viável; ▸ Todos os bugs resolvidos teriam que ser retestados; ▸ Falta de mão-de-obra e tempo hábil;
  14. REFATORAR GRADATIVAMENTE PARA UM NOVO FRAMEWORK ▸ Maior agilidade na

    refatoração, já que parte do código legado ainda seria mantido; ▸ Manter dois frameworks em uma mesma base de código pode não ser performático; ▸ Aplicação amarrada agora a duas tecnologias; ▸ Compartilhar informações entre as partes não é uma tarefa fácil.
  15. UTILIZAR A ARQUITETURA DE MICRO FRONTENDS ▸ Assim como a

    arquitetura de micro serviços, adiciona uma complexidade a mais no projeto; ▸ Maior independência entre os módulos; ▸ Arquitetura mais agnóstica a frameworks; ▸ Lógica pulverizada em vários projetos; ‣ Pipeline de build, test e deploys mais rápida.
  16. Fonte: https://martinfowler.com/articles/micro-frontends.html

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

  18. CONCEITO ‣ Baixo ou nenhum acoplamento; ‣ Alta coesão; ‣

    Não deve assumir responsabilidades de outro micro frontend; ‣ Não deve interferir ou ser interferido por outro micro frontend; ‣ Base de código independente; ‣ Pipeline de build, test e deploys separados e independentes.
  19. None
  20. ‣ Modernização da aplicação sem a necessidade de jogar tudo

    fora; ‣ Aplicação totalmente agnóstica de novas tecnologias; ‣ Migração gradativa do código legado; ‣ Pipeline de build, test e deploys mais rápida; ‣ Maior tolerância a falhas; ‣ Separação de micro frontends por times. BENEFÍCIOS
  21. FORMAS DE IMPLEMENTAÇÃO

  22. FORMAS DE IMPLEMENTAÇÃO ‣ Implementação em tempo de build; ‣

    Integração por meio de funções javascript; ‣ Integração através de web components; ‣ Integração via iframes.
  23. IMPLEMENTAÇÃO EM TEMPO DE BUILD - PROJETOS COMO PACOTES NPM

    { "name": “@my-project/main”, "version": "1.0.0", "description": “My amazing application", "dependencies": { “@my-project/frontend-1“: “1.0.0”, “@my-project/frontend-2“: “1.0.0”, “@my-project/frontend-3“: “1.0.0”, } }
  24. IMPLEMENTAÇÃO EM TEMPO DE BUILD - PROJETOS COMO PACOTES NPM

    ✓ Baixo ou nenhum acoplamento; ✓ Alta coesão; ✓ Não deve assumir responsabilidades de outro micro frontend; ✓ Não deve interferir ou ser interferido por outro micro frontend; ✓ Base de código independente; - Pipeline de build, test e deploys separados independentes;
  25. INTEGRAÇÃO POR FUNÇÕES JAVASCRIPT <!-- These scripts don't render anything

    immediately --> <!-- Instead they attach entry-point functions to `window` --> <script src="https://browse.example.com/bundle.js"></script> <script src="https://order.example.com/bundle.js"></script> <script src="https://profile.example.com/bundle.js"></script> <div id="micro-frontend-root"></div> <script type="text/javascript"> // These global functions are attached to window by the above scripts const microFrontendsByRoute = { '/': window.renderBrowseRestaurants, '/order-food': window.renderOrderFood, '/user-profile': window.renderUserProfile, }; const renderFunction = microFrontendsByRoute[window.location.pathname]; // Having determined the entry-point function, we now call it, // giving it the ID of the element where it should render itself renderFunction('micro-frontend-root'); </script>
  26. INTEGRAÇÃO POR FUNÇÕES JAVASCRIPT ✓ Baixo ou nenhum acoplamento; ✓

    Alta coesão; ✓ Não deve assumir responsabilidades de outro micro frontend; ✓ Não deve interferir ou ser interferido por outro micro frontend; ✓ Base de código independente; ✓ Pipeline de build, test e deploys separados independentes;
  27. INTEGRAÇÃO ATRAVÉS DE WEB COMPONENTS <script src="https://about.project.com/bundle.js"></script> <script src="https://products.project.com/bundle.js"></script> //

    /about page <div id="container"> <about-micro-frontend></about-micro-frontend> </div> // /products page <div id="container"> <products-micro-frontend></products-micro-frontend> </div>
  28. INTEGRAÇÃO ATRAVÉS DE WEB COMPONENTS { "name": "@my-project/web-components", "version": "1.0.0",

    "description": "My amazing application", "dependencies": { "@my-project/about-micro-frontend": "1.0.0", "@my-project/products-micro-frontend": "1.0.0" } }
  29. INTEGRAÇÃO ATRAVÉS DE WEB COMPONENTS ✓ Baixo ou nenhum acoplamento;

    ✓ Alta coesão; ✓ Não deve assumir responsabilidades de outro micro frontend; ✓ Não deve interferir ou ser interferido por outro micro frontend; ✓ Base de código independente; ✓ Pipeline de build, test e deploys separados independentes; - Passar as rotas da aplicação principal para webcomponents é um problema
  30. IINTEGRAÇÃO VIA IFRAMES // /about page <div id="container"> <iframe src="https://about.project.com"></iframe>

    </div> // /products page <div id="container"> <iframe src="https://products.project.com"></iframe> </div>
  31. None
  32. Micro frontend Aplicação “satélite”

  33. Iframe-message-proxy

  34. None
  35. None
  36. None
  37. OBRIGADO!