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.
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/
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