Micro frontend
Transferir como PPTX, PDF0 gostou37 visualizações
O documento discute a evolução de um produto monolítico para uma arquitetura de micro-frontends. Apresenta o conceito de micro-frontends, os tipos possíveis e o problema de negócio que motivou a mudança. Explica como o framework Single-SPA atendeu as necessidades e os desafios encontrados, como falta de documentação e erros. Por fim, destaca lições aprendidas como documentação e apoio da comunidade.
Micro frontend
- 1. Saindo do Monolito ao Micro-Frontend Como evoluímos o nosso principal produto Vagner Oliveira vagner.olliver@gmail.com - @vagnerolliver Thiago Martins thiagomsl@gmail.com - @thiagommaartins
- 2. Hello ! Thiago Martins Front-End Developer - App.Zenvia Análise e Desenv. De Sistemas - Unicesumar Vágner Oliveira Front-End Developer - Zenvia Message Sistema para Internet - Ulbra
- 3. Check In O que é Micro-Frontend? Quais os tipos de MFE possíveis Problema de negócio O Single-SPA Desafios e Lições aprendidas Perguntas e bate-papo
- 4. Micro-Frontend ● Estende os conceitos de microservices ● Sistemas isolados, testados e implementados independente de outros ● Trabalhar com funcionalidades de maneira isolada ● Times coesos que podem representar uma camada de negócio de ponta a ponta ● Desenvolvimento e deploys rápidos imagens: https://scs-architecture.org/index.html
- 5. Visualizações do MFE's Vertical Times trabalhando em páginas diferentes Horizontal Times trabalhando em uma mesma página imagens: https://medium.com/@lucamezzalira/micro-frontends-decisions-framework-ebcd22256513
- 6. Composição MFE's ● Client Side ● Server Side ● Edge Side imagem: https://www.clariontech.com/blog/server-side-rendering-vs.-client-side-rendering
- 7. Tá, tudo muito legal! Mas qual o problema de negócio que queremos resolver?
- 8. Problema de negócio ● Alto nível de acoplamento das aplicações. ● Times com velocidades de entregas diferentes. ● Tempo considerável para incluir novos produtos na plataforma. ● Ausência de padrão visual entre os produtos. ● Monolito com alta dependência para as demais aplicações. ● Reduzir o tempo de inclusão de novos produtos na plataforma. ● Deploy independente dos times. ● Autonomia para os times. ● Remover a dependência do monolito. ● Login único entre produtos. ● Experiência única, entre os produtos. ● Fluidez na navegação entre os produtos. ● Atualização da stack. ● Aplicações escaláveis. Cenário que tínhamos Onde queríamos chegar
- 9. Então o Single SPA nos atende pq ... ● Outros grandes players já tinham usado e tínhamos uma base para começar ● Atualização e colaboração ativa da comunidade; ● Muito conteúdo na web; ● Possui três modos de utilização: ○ Single-spa applications: Micro-frontends que renderiza componentes para um conjunto de rotas específicas. ○ Single-spa parcel : Micro-frontends que renderiza componentes sem controlar rotas. ○ Utility Modules: Micro-frontends que exportam lógica JavaScript compartilhada sem componentes de renderização. Fonte: https://single-spa.js.org/
- 10. Ecossistema
- 11. Desafios encontrados ● Falta de documentação do que já tinha sido descoberto ● Descoberta do novo e pouca referência na web ● Erros encontrados no meio do caminho ● Estávamos implementando paralelo a isso um SSO (Single Sign-On) ● Organizar/conhecer melhor o AWS (S3) ● Muuuitas branches e pouco controle! ● Rotina do Jenkins sabotando os devs ● Muito cache e vários F5 para validar implementações.
- 12. Lições aprendidas ● Documentação das features ● Apoio da comunidade; ● Design Systems; ● Plugin do Concurrently; ● Processo de deploy, release e validação; ● Muitos e muitos Researches
- 14. Obrigado! Vagner Oliveira vagner.olliver@gmail.com - @vagnerolliver https://www.linkedin.com/in/vagnerolliver/ Thiago Martins thiagomsl@gmail.com - @twthiagomartins https://www.linkedin.com/in/thiagomaartins/