Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Evoluindo suas aplicações utilizando micro frontends - Caso BLiP

Samuel Martins
September 03, 2020
38

Evoluindo suas aplicações utilizando micro frontends - Caso BLiP

Samuel Martins

September 03, 2020
Tweet

Transcript

  1. MICRO FRONTENDS
    EVOLUINDO SUA APLICAÇÃO UTILIZANDO

    View full-size slide

  2. SAMUEL MARTINS - QUEM VOS FALA
    ▸ Tech Lead na 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];

    View full-size slide

  3. CASO DE USO
    BLIP

    View full-size slide

  4. STACK E AMBIENTE
    ‣ AngularJs;
    ‣ Arquitetura MVVM (Model, View e View Model);
    ‣ ~50k linhas de código;
    ‣ Aplicação totalmente monolítica, todo o código no mesmo repositório.

    View full-size slide

  5. DIFICULDADES

    View full-size slide

  6. STACK E AMBIENTE - DIFICULDADES
    ▸ Comunidade abandonou o AngularJs;
    ▸ 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.

    View full-size slide

  7. ‣ Falta de autonomia dos times;
    ‣ Deploys são mais sucetíveis a falhas;
    ‣ Deploy fica cada vez mais demorado;
    ‣ Aplicação totalmente amarrada a uma tecnologia;
    E MAIS…

    View full-size slide

  8. ECOSSISTEMA
    FRONTEND EM
    CONSTANTE
    EVOLUÇÃO

    View full-size slide

  9. O QUE FAZER DIANTE
    DESSE CENÁRIO?

    View full-size slide

  10. O QUE FAZER DIANTE DESSE CENÁRIO?
    ▸ Refatorar o 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.

    View full-size slide

  11. MESMO CÓDIGO, OUTRA ARQUITETURA
    ▸ Todo código pode ser melhorado, 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.

    View full-size slide

  12. REESCREVER O PROJETO COM UMA NOVA TECNOLOGIA
    ▸ Projetar um 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;

    View full-size slide

  13. REFATORAR GRADATIVAMENTE PARA UM NOVO FRAMEWORK
    ▸ Maior agilidade na 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.

    View full-size slide

  14. UTILIZAR A ARQUITETURA DE MICRO FRONTENDS
    ▸ Assim como a 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.

    View full-size slide

  15. Fonte: https://martinfowler.com/articles/micro-frontends.html

    View full-size slide

  16. Fonte: https://martinfowler.com/articles/micro-frontends.html

    View full-size slide

  17. CONCEITO
    ‣ 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 e independentes.

    View full-size slide

  18. ‣ Modernização da aplicação sem a necessidade de jogar tudo 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

    View full-size slide

  19. FORMAS DE
    IMPLEMENTAÇÃO

    View full-size slide

  20. FORMAS DE IMPLEMENTAÇÃO
    ‣ Implementação em tempo de build;
    ‣ Integração por meio de funções javascript;
    ‣ Integração através de web components;
    ‣ Integração via iframes.

    View full-size slide

  21. IMPLEMENTAÇÃO EM TEMPO DE BUILD - PROJETOS COMO PACOTES NPM
    {
    "name": “@my-project/main”,
    "version": "1.0.0",
    "description": “My amazing application",
    "dependencies": {
    “@my-project/frontend-1“: “1.0.0”,
    “@my-project/frontend-2“: “1.0.0”,
    “@my-project/frontend-3“: “1.0.0”,
    }
    }

    View full-size slide

  22. IMPLEMENTAÇÃO EM TEMPO DE BUILD - PROJETOS COMO PACOTES NPM
    ✓ 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;

    View full-size slide

  23. INTEGRAÇÃO POR FUNÇÕES JAVASCRIPT






    <br/>// These global functions are attached to window by the above scripts<br/>const microFrontendsByRoute = {<br/>'/': window.renderBrowseRestaurants,<br/>'/order-food': window.renderOrderFood,<br/>'/user-profile': window.renderUserProfile,<br/>};<br/>const renderFunction = microFrontendsByRoute[window.location.pathname];<br/>// Having determined the entry-point function, we now call it,<br/>// giving it the ID of the element where it should render itself<br/>renderFunction('micro-frontend-root');<br/>

    View full-size slide

  24. INTEGRAÇÃO POR FUNÇÕES JAVASCRIPT
    ✓ 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;

    View full-size slide

  25. INTEGRAÇÃO ATRAVÉS DE WEB COMPONENTS


    // /about page



    // /products page



    View full-size slide

  26. INTEGRAÇÃO ATRAVÉS DE WEB COMPONENTS
    {
    "name": "@my-project/web-components",
    "version": "1.0.0",
    "description": "My amazing application",
    "dependencies": {
    "@my-project/about-micro-frontend": "1.0.0",
    "@my-project/products-micro-frontend": "1.0.0"
    }
    }

    View full-size slide

  27. INTEGRAÇÃO ATRAVÉS DE WEB COMPONENTS
    ✓ 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;
    - Passar as rotas da aplicação principal para webcomponents é um problema

    View full-size slide

  28. IINTEGRAÇÃO VIA IFRAMES
    // /about page



    // /products page



    View full-size slide

  29. Micro frontend
    Aplicação “satélite”

    View full-size slide

  30. Iframe-message-proxy

    View full-size slide