Introdução Microfrontend
•Download as PPTX, PDF•
0 likes•19 views
Introdução a module federation, nx
Recommended
Recommended
More Related Content
Similar to Introdução Microfrontend
Similar to Introdução Microfrontend (20)
Recently uploaded
Recently uploaded (6)
Introdução Microfrontend
- 4. Era uma vez um projeto…
- 7. • Muitos contextos de negócios dentro do mesmo projeto Muitas pessoas trabalhando na mesma base de código Muitas branchs Muitos pull requests Problemas compartilhados
- 10. Precisamos de mudar um botão de lugar…
- 17. Microfrontend A Microfrontend B Microfrontend C
- 18. Micro frontends are a new pattern where web application UIs (front ends) are composed from semi-independent fragments that can be built by different teams using different technologies. Micro-frontend architectures resemble back-end architectures where back ends are composed from semi-independent microservices
- 19. Micro frontends são um novo padrão onde UIs de aplicações web (front-ends) são compostas de fragmentos semi-independentes que podem ser construídos por diferentes equipes usando diferentes tecnologias. As arquiteturas de micro-front-end se assemelham a arquiteturas de back-end em que os back-ends são compostos de microsserviços semi- independentes
- 21. 1. Stack padrão ou independente? Deploy unificado ou independente? Repositórios unificados ou independentes?
- 24. • Múltiplos runtimes, libs e código da aplicação Além do download bundle, todo o código deve ser interpretado pelo navegador. Re renders desnecessários
- 25. • Atualização de stacks Componentes externos(gateway de pagamentos, lib de componentes) Unificação de features
- 31. Manutenção integrada A otimização depende muito da da resolução das dependências
- 32. bundle.js (Core Squad) Microfront A (Squad A) Microfront B (Sqaud B) WebServer Request: /checkout WebApp Browser
- 33. Main BUNDLER index.html main.js styles.css *.svg About BUNDLER about.css about.js Strandalone Build
- 34. • Ao realizar um build separado não é possível realizar tree shaking Você vai ter que optar ou em levar código “repetido” ou levar uma lib inteira, pois não vai saber o que um mf pode usar
- 37. bundle.js (Core Squad) Microfront A (Squad A) Microfront B (Sqaud B) WebServer Request: /checkout WebApp Browser Module Federation git clone moduleB npm i moduleA
- 38. Monorepo About Home Contacts Multi/Polyrepo About Home Contacts Multi/Polyrepo Home, About, Contacts
- 39. bundle.js (Core Squad) Microfront A (Squad A) Microfront B (Sqaud B) WebServer Request: /checkout WebApp Browser
- 41. Tá, mas eu não vou fazer todo esse gerenciamento na mão né?
- 43. Single SPA
- 44. Lerna
- 45. NX
- 46. Turborepo
- 47. Demo
Editor's Notes
- - Acho que todo mundo já deve ter passado algo parecido - Eu já umas 20 - Você fica todo feliz - Projeto dessa vez vai nascer do jeito certo
- - Acho que todo mundo já deve ter passado algo parecido - Eu já umas 20 - Você fica todo feliz - Projeto dessa vez vai nascer do jeito certo
- - Arquitetura nova - Melhores padrões e práticas - Igual squartle - pequeno, bonitinho e todo funcional - vc ja imagina ele virando o warttuttle e o blastoise todo organizado parrudo maromba
- Não quer dizer que seja ruim, Projeto pode ter ir “dando certo” Todo mundo queria uma feature, virou uma coisa que ninguém tem mais controle
- Pessoal de negócio gostou tanto que pediu várias features ficou com muitos contextos (do financeiro até a marcação de escritório) Muita gente entrando pra mexer nos contextos Pessoa que vem de outras empresas trouxe os costumes da empresa antiga Começam a criar branch padrões de branch por squad / por + coloque trava, a fazer release branch interna Muitos prs, de features, dependa bot, de bot de num sei o que pr de gente que não tá na empresa que negócio precisa ver em prod
- Slide vai ficar em branco! - ai quando vc pensa que acabou
- Pessoal de produto, faz um experimento e - call to action tá lugar ruim e pede pra mudar eles sabem que é fácil mas consideram seu drama imaginam algo tipo isso
- Na sua cabeça tá vc sabe que é assim(passar slide) mas no fundo é assim(banana) E quando vc vai entregar ainda tem o Doctor Eggman que nem faz parte do Mário mas ninguém sabe pq ele tá ali
- -vc fica doido com isso todo dia -começa a se atualizar sobre arquitetura pra tentar resolver - ai vc faz o que toda pessoa sensata faria
- Cai na palavrinha mágica
- Mas uma coisa que rola é que …
- mss rodam em pods isolados em instancias isoladas No ifood mss em kotlin, java, rust, node e roda liso, nao posso colocar jQuery, vue, react e svelte na mesma página e achar que vai rodar liso no Chrome num pc (está rodando tudo no mesmo client, vou falar mais na frente) O tamanho do build dos mss
- Vejo que hoje, são basicamente duas abordagens que eu vejo a galera adotando Times baseados em negócio(explicar figura) Então uma página pra cada time ou…
- Ainda por negócio, porém mais contextualizado
- A definição mais legal que de mfs é essa da toptal(pra quem fez inglês)
- Iframes sao microfront(gmail) Na minha visão, a maioria das vezes resume a independência
- Só que independência é muuuuuuito complicado Trouxe 3 pontos dessa independencia nos mfs
- - Aqui, eu sou bem cabeça fechada
- - Eu não vejo aonde isso pode ser uma boa ideia
- Cada framework que surgir vc vai adotar? download, interpretação de código é caro também controlar estados de 4 formas diferentes, é muito fácil de vc fazer um tanto de re render sem necessidade
- Misturar tecnologias não é proibido, tem seus cases - Atualização - Caso da hotmart (vue + meteor + react) - Caso da pagar.me (vue + react)
- Build mais comum, em aplicação tradicional chamar atenção é o nosso bundler, que seria o webpack Ele faz otimizações antes de vc shipar
- Alguém consegue chutar o que vai acontecer quando eu bulidar em prod otimizando esse código?
- remove completamente a classe calculadora, - ele tem toda info que ele precisa pra entender que ali só iria impimr 3 de qualquer forma
- Aqui a mesma coisa, porém eu não dei os números, ai ele eliminou a calcadora, mas deixou a operação de soma E exatamente isso que acontece quando você vai bulidar sua app
- Quanto mais informação sobre o mf A e mf B ele tem EM TEMPO DE BUILD, mais otimizado ele vai ser
- Quando você faz cada Build independente o main não sabe o que é utilizado em about, então ele leva a mais ou repetido
- ou você compartilha e garante deps entre os mfs Vai levar mais do que precisa, pq ele não vai saber o que o mf a não esta usando quando você bulidar o core Ou nao compartilha e pode levar várias partes repetidas O module federation tem uma discussão enorme de como no futuro eles estão tentando resolver isso mas na doc eles falam que ainda não conseguem fazer o tree shaking completo de deis compartilhadas
- Na primeira vez que eu vi falar de monorepo, eu já olhei e falei, “isso não existe… não faz o menor sentido” A ideia é que no Polly ou multirepo
- Ai no build, vc pode fazer ou remoto, tipo module Federation ou vc da um install antes de rodar o build Nao acho bonito mas ja fiz
- em um monólito, - é tudo no mesmo lugar mesmo No multrepo Se uma dependencia muda o contrato você precisa de lembrar que esse contrato é usado Pode fazer igual a versionamento de db, mas é uma gambiarra do caralho No monorepo tudo no mesmo diretório, mas… As ferreamentas te dão impressão que você está em repôs separados Cache computacional Instação de deps, Você nao importa o arquivo diretamente, vc importa como se ele fosse um outro pacote npm Por debaixo dos panos é um synlink
- Se o bundler sabe resolver as dependências no Build ele otimiza mais
- Module federation faz muito sucesso, e é muito bom, remote Só webpack 5 Deploy no s3 todos os mfs e seu cdn toma conta igual todos os outros js Tem uma discussão falando que não é uma solução boa eu achei ok
- Eu mesmo nao uso tem tempo, consegue fazer a mesma coisa do webpack, sem usar o webpack5 suporte a comunicação entre os mfs padrãoo boostrap, e métodos de iniclaição Ele tem um CLI já pronto pra fazer as coisas Botar na balança uma lib pra fazer microfone
- - é um monorepo E ele era utilizado no jest, gatsb Tinha morrido, mas voltou É bem simples e te ajuda muito a rodar as tais Ele faz tudo que um monorepo tem que fazer, é isso Soltaram uma versão com coisas legal, semana passada
- Pra mim é a melhor, ela faz tudo e mais um pouco Ele é um serviço, então você consegue até usar ele como seu ci Scafolding e geradores Cache Se intromente um pouco na sua apliçacão Mas pro bem Se você nao souber nada, é só rodar o Next Next finish dela, que você já vai ter toda configuração do react,vue, etc configurada
- Eu nunca usei, mas dizem que é tão bom quanto nx