Baixar para ler offline
Carregado porThiago Martins
Micro frontend
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 aoMicro-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-EndDeveloper - 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 osconceitos 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 Timestrabalhando 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 ● ClientSide ● Server Side ● Edge Side imagem: https://www.clariontech.com/blog/server-side-rendering-vs.-client-side-rendering
- 7. Tá, tudo muitolegal! 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 SingleSPA 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.
- 11. Desafios encontrados ● Faltade 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çãodas features ● Apoio da comunidade; ● Design Systems; ● Plugin do Concurrently; ● Processo de deploy, release e validação; ● Muitos e muitos Researches
- 13.
- 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/
- 15.