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];
▸ 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.
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.
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.
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;
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.
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.
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.
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
✓ 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;
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>
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;
✓ 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
samwx
jct
codingconduct
gurzu
aleyda
addyosmani
smashingmag
cassininazir
tammyeverts
bluesmoon
lauravandoore
sonatard
inesmontani
