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

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
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.
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>
32. Micro frontend Aplicação “satélite”
33. Iframe-message-proxy
37. OBRIGADO!