Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Evoluindo suas aplicações utilizando micro fr...

Samuel Martins
September 03, 2020
47

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

Samuel Martins

September 03, 2020
Tweet

Transcript

  1. 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: [email protected];
  2. 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.
  3. 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.
  4. ‣ 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…
  5. 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.
  6. 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.
  7. 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;
  8. 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.
  9. 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.
  10. 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.
  11. ‣ 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
  12. 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.
  13. 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”, } }
  14. 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;
  15. 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>
  16. 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;
  17. 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>
  18. 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" } }
  19. 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
  20. 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>