Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[JS EXPERIENCE 2018] Do jQuery aos microfrontends: os desafios de manter uma aplicação web - Luiz Fernando Rodrigues, ContaAzul

110 views

Published on

Do jQuery aos microfrontends: os desafios de manter uma aplicação web - Luiz Fernando Rodrigues, ContaAzul

[JS EXPERIENCE 2018] - 5 de julho de 2018
São Paulo/SP

Published in: Technology
  • Be the first to comment

  • Be the first to like this

[JS EXPERIENCE 2018] Do jQuery aos microfrontends: os desafios de manter uma aplicação web - Luiz Fernando Rodrigues, ContaAzul

  1. 1. do jQuery aos microfrontends: os desafios de manter uma aplicação web.
  2. 2. Antes de tudo, uma história real.
  3. 3. Desenvolver componente de autocomplete Created 30 min ago
  4. 4. <input id="autocomplete" placeholder="Busque..." /> <script src="autocomplete.js"></script> <script> autocomplete("#autocomplete", {}) </script>
  5. 5. Hoisting em JavaScript é o que acontece quando funções e variáveis são elevadas ao topo de um escopo.
  6. 6. @fernahh fernahh.com
  7. 7. ContaAzul contaazul.com/vagas
  8. 8. Plataforma de gestão empresarial A empresa foi fundada em 2012. O objetivo é dar tempo ao micro e pequeno empresário para focar no que interessa: seu negócio.
  9. 9. Nosso tamanho 350+ funcionários 4.000+ escritórios contábeis parceiros 1.000.000+ empresas já começaram a usar
  10. 10. Nossas primeiras tecnologias.
  11. 11. Apresentação Negócio Dados
  12. 12. Apresentação Negócio Dados Tudo em um mesmo servidor, como a maioria das aplicações da época.
  13. 13. Camada de apresentação. ● O HTML era gerado no servidor, prática comum para a época. ● A camada de estilo era escrita com Less para facilitar a criação de temas. ● O comportamento era feito com JavaScript puro e bibliotecas como a clássica jQuery.
  14. 14. Interfaces web são assíncronas, onde temos dois agentes de mudança: usuário e servidor.
  15. 15. Nome Categoria Cadastro de Produto Salvar
  16. 16. Nome Categoria Cadastro de Produto Salvar 1. $.keyup() 2. $.addClass() 3. $.removeClass()
  17. 17. Nome Categoria Cadastro de Produto Salvar 1. $.click() 2. $.get() 3. $.appendTo()
  18. 18. Nome Categoria Cadastro de Produto Salvar 1. $.click() 2. $.post() 3. $(location).attr()
  19. 19. Por vários anos, o paradigma orientado a eventos reinou sobre o desenvolvimento web.
  20. 20. Aprendemos que o DOM é lento, e escrever código performático na maioria das vezes prejudica a legibilidade.
  21. 21. Mesmo quando JavaScript era usado apenas para “validar formulários”, a chance dele se tornar um caos era muito grande.
  22. 22. AMD como sistema de módulos
  23. 23. good parts AMD como sistema de módulos. ● Tinha uma ótima comunidade de apoio em torno da principal implementação: RequireJS. ● Bibliotecas como jQuery e Lodash faziam uso da implementação. ● Evita que o usuário baixe script desnecessário.
  24. 24. bad parts AMD como sistema de módulos. ● “Esconde” tamanho da aplicação. ● Bibliotecas que não dão suporte ao padrão dificultam o uso. ● Após chegada dos ES Modules, ficou custoso reescrever tudo.
  25. 25. Enquanto isso o mercado estava cada vez mais desenvolvendo aplicações com tecnologias web.
  26. 26. Ter apenas um software “na nuvem” já não era mais um diferencial.
  27. 27. Requisitos universais de uma aplicação web.
  28. 28. Atrativa Simples de usar Acessível Rápida
  29. 29. Atrativa Simples de usar Acessível Rápida Design Usabilidade Acessibilidade Performance
  30. 30. Design e usabilidade. ● Corrigindo metade das falhas de uma interface já no início, pode render melhorias de até 700%. (Gilb, 1998) ● Se um sistema for lançado com falhas, as correções podem custar 100 vezes mais do que o período de desenvolvimento. (Laundauer, 1995) - https://www.nngroup.com/articles/return-on-investment-for-usability/ - https://www.nngroup.com/articles/usability-roi-declining-but-still-strong/
  31. 31. “Why does one choose to use Gmail over Yahoo, Medium over Blogger, if the feature are 99% the same? ... https://uxdesign.cc/ux-trends-2017-46a63399e3d2
  32. 32. …It’s definitely not about disrupting usability standards. It’s about that additional layer of sophistication (...) of tiniest details, the most subtle animations, the most elegant transitions.” https://uxdesign.cc/ux-trends-2017-46a63399e3d2
  33. 33. Acessibilidade e performance. ● Há 20,5 milhões de idosos e 45,6 milhões de brasileiros com algum tipo de deficiência. (Censo de 2010) ● A BBC descobriu que eles perdem 10% mais usuários a cada segundo adicional no carregamento de seu site. (Jeremy Wagner, 2018)
  34. 34. “Improving performance should not be seen solely as a means of advancing ourselves, but also as ethically responsible behavior.” Jeremy Wagner https://developers.google.com/web/fundamentals/performance/why-performance-matters/
  35. 35. As limitações da web como plataforma.
  36. 36. Apresentação Negócio Dados
  37. 37. “We are basically hacking Microsoft Word to run apps.” @ken_wheeler http://coldfront.surge.sh/
  38. 38. Apesar de ser a maior plataforma de desenvolvimento de software, o browser possui sérias limitações.
  39. 39. APIs são inconsistentes Para cada web API existem inúmeras bibliotecas de abstração.
  40. 40. Manter estado é um desafio O estado em uma aplicação web precisa estar em sincronia com a URL do usuário.
  41. 41. Instabilidade de conexão A conexão dos usuários é lenta, totalmente instável e heterogênea.
  42. 42. Front-end não é fácil Não é a toa que existem inúmeras tentativas de não escrever HTML, CSS e Javascript.
  43. 43. Reescrever aplicações quase nunca é uma boa ideia.
  44. 44. Especificação Ao longo do tempo muitas melhorias e correções são desenvolvidas, e nunca são documentadas.
  45. 45. Custo Uma aplicação de tamanho médio, vai levar no mínimo ~6 meses para ficar pronta.
  46. 46. http://www.ben-morris.com/why-refactoring-code-is-almost-always-better-than-rewriting-it/
  47. 47. O advento das ferramentas JavaScript.
  48. 48. HTML
  49. 49. HTML CSS
  50. 50. HTML CSS JavaScript
  51. 51. JavaScript CSS HTML
  52. 52. Além de comportamento, hoje o JavaScript atua na entrega de conteúdo, faz build também é responsável pelo estilo.
  53. 53. JavaScript é, indiscutivelmente, a linguagem mais importe da década.
  54. 54. JavaScript é, indiscutivelmente, a linguagem mais importe da década.
  55. 55. Backbone Angular Ember React Vue
  56. 56. Data Binding e MV* Frameworks foram boas ideias...
  57. 57. Data Binding Permite que possamos conectar mudanças de um modelo para a UI.
  58. 58. API Model Template Merge View JSON JavaScript Linguagem de template HTML
  59. 59. Two-way Data Binding Além do fluxo do modelo para a UI, nessa abordagem a UI também faz atualizações no modelo.
  60. 60. API Model View JSON JavaScript HTML Template Linguagem de template Compile
  61. 61. API Model View JSON JavaScript HTML Template Linguagem de template Compile “seria o fim dos callbacks?”
  62. 62. AngularJS como framework front-end
  63. 63. good parts AngularJS como framework front-end ● A comunidade em torno do framework cresceu e se tornou a maior da época. ● Rápido para prototipar ideias e desenvolver experimentos. ● Prioriza a separação de camadas entre HTML e JavaScript.
  64. 64. bad parts AngularJS como framework front-end ● Two-way binding facilmente se torna um rio de side effects. ● Dependency Injection se tornou burocrático após ES Modules. ● Problemas de performance aparecem em pouco tempo de uso.
  65. 65. Side effects O código é difícil de testar, o que se resulta em medo de fazer refactoring e corrigir bugs.
  66. 66. Código duplicado No modelo MVC tudo é orientado a view. Filters e diretivas não são muito amigáveis com perfomance.
  67. 67. Depreciação e código legado É difícil usar “novas” features do JavaScript e a atualização de bibliotecas se tornam caras de implementar.
  68. 68. Jornada em busca de produtividade.
  69. 69. Paradigmas baseados em componentes ganharam mercado.
  70. 70. Abstração
  71. 71. Salvar Possibilidades de uso ● Receber um texto ● Receber um ícone ● Disparar uma ação
  72. 72. R$ 100 Salvar Possibilidades de uso ● Receber um texto ● Receber um ícone ● Disparar uma ação
  73. 73. R$ 100 Salvar Possibilidades de uso ● Receber um texto ● Receber um ícone ● Disparar uma ação ● Receber um totalizador (????) updateTotal()
  74. 74. Salvar <ca-button data-text="Salvar" data-action="save()"/>
  75. 75. Salvar <ca-totals data-value="total"/> Total: R$ 100 <ca-button data-text="Salvar" data-action="save()"/>
  76. 76. “Ao abstrair tornar mais polimórfico, você está restringindo o espaço de implementação, diminuindo a possibilidade de erros.” @rodrigowillrich
  77. 77. Facilidade para testar
  78. 78. Testes end-to-end São difíceis de manter em grande escala, mas numa lib de componentes talvez faça sentido.
  79. 79. good parts Testes end-to-end ● Faz sentido quando você quer testar uma biblioteca de componentes ao invés do sistema todo. ● Podem pegar erros que são difíceis de testar de forma unitária.
  80. 80. bad parts Testes end-to-end ● São difíceis de manter quando se tem muitas telas. ● Podem se tornar lento e custando caro para o processo de CI/CD. ● A certeza que irá pegar todos os bugs não é garantida.
  81. 81. Reuso de código
  82. 82. Possibilidade de pensar no WOW!
  83. 83. Criamos uma biblioteca de componentes “vanilla”
  84. 84. good parts Componentes Vanilla ● Ter o CSS em folhas de estilo facilitam o uso entre tecnologias diferentes. ● Apenas instanciar um objeto padroniza comportamentos.
  85. 85. bad parts Componentes Vanilla ● Código performático != código legível. ● Muitas libs já são escritas diretas nos frameworks. ● Complexo para escrever testes unitários.
  86. 86. O que fazer com o código legado?
  87. 87. Como sobreviver sem reescrever tudo.
  88. 88. Dor Recurso Soluções Continuidade
  89. 89. Dor Recurso Soluções Continuidade
  90. 90. Antes de tudo, é preciso saber onde estão as dores do time.
  91. 91. Débitos técnicos Significam o custo implícito por uma escolha mais “fácil e rápida”. Se a dívida não for paga, ela pode cobrar juros.
  92. 92. Débitos técnicos. ● Ajudam a quantificar e ter uma visão de quanto o time está investindo em soluções paliativas. ● Servem como documentação do histórico de implementações pobres.
  93. 93. O Santo Graal da arquitetura de software não existe.
  94. 94. O que ouvimos falar são as histórias que deram certo. Ninguém conta as cagadas que acontecem no dia-a-dia das empresas. https://engineering.contaazul.com/o-santo-graal-da-arquitetura-de-software-n%C3%A3o-exi ste-7c4cdcc75475
  95. 95. É preciso entender que por trás das boas histórias há muito trabalho e, provavelmente, alguns débitos técnicos foram comprados. https://engineering.contaazul.com/o-santo-graal-da-arquitetura-de-software-n%C3%A3o-exi ste-7c4cdcc75475
  96. 96. Nerd adora falar mal de tecnologia. https://engineering.contaazul.com/o-santo-graal-da-arquitetura-de-software-n%C3%A3o-exi ste-7c4cdcc75475
  97. 97. “We don’t hire people to write code. We hire them to solve problems.” Jem Young https://twitter.com/NetflixUIE/status/1012568486848000000
  98. 98. Dor Recurso Soluções Continuidade
  99. 99. Modelo de maturidade É um modelo que ajuda a determinar a eficácia de um software e onde ele pode ter um desempenho melhor.
  100. 100. https://www.martinfowler.com/bliki/MaturityModel.html
  101. 101. https://info.thoughtworks.com/rs/thoughtworks2/images/agile_maturity_model.pdf
  102. 102. “The vital point here is that the true outcome of a maturity model assessment isn't what level you are but the list of things you need to work on to improve.” Martin Fowler https://www.martinfowler.com/bliki/MaturityModel.html
  103. 103. Dor Recurso Soluções Continuidade
  104. 104. Projetos de Big Picture. ● A cada trimestre, desenvolvedores faziam proposta de projetos em que eram priorizadas por eles mesmos. ● Cada projeto poderia durar duas semanas, e poderia ser executado por dois desenvolvedores. ● Proporcionou-nos pagar diversos débitos e desenvolver features para aumentar a produtividade da engenharia.
  105. 105. Time Foundation. ● Responsável por desenvolver soluções para aumentar a produtividade e a qualidade das entregas do time de engenharia. ● Executa tarefas como atualizações de bibliotecas, desenvolvimento de componentes e continuous integration.
  106. 106. Dor Recurso Soluções Continuidade
  107. 107. Vale a pena desenvolver produtos com AngularJS?
  108. 108. “Isolar” o AngularJS. ● Controllers, factories e filters são escritos apenas com JavaScript. ● As dependências do Angular ficam em um arquivo de configuração de índice do módulo. ● Inversão de Dependência é usado para abstrair implementações, e dessa forma não “espalhar o framework”. https://engineering.contaazul.com/angularjs-e-alguns-passos-para-atualizar-sua-stack-f6ab35 f70af9
  109. 109. Microfrotends
  110. 110. Problemas ● Muitas das soluções para resolver produtividade e qualidade são de longo prazo. ● Tomar decisões sobre design de código e escolha de tecnologias são difíceis em “monolitos”. ● Nosso estrutura organizacional não representava nossa arquitetura de software.
  111. 111. “An alternative route (to rewrite a system entirely) is to gradually create a new system around the edges of the old.” Martin Fowler https://www.martinfowler.com/bliki/StranglerApplication.html
  112. 112. Mount Rota indica um módulo Request do módulo
  113. 113. https://engineering.contaazul.com/evolving-an-angularjs-application-using-microfrontends- 2bbcac9c023a
  114. 114. bad parts Microfrontend ● Ainda é algo novo e pouco explorado pelo mercado. Muito do que fizemos foi dentro de casa. ● Precisamos de disciplina e muito alinhamento para evitar retrabalho dos times.
  115. 115. good parts Microfrontends ● Provê uma maior autonomia para os times tomarem suas próprias escolhas. ● Nos deu a possibilidade de testarmos novas tecnologias e paradigmas. ● O build/deploy é, consequentemente, bem mais rápido que o monolito.
  116. 116. Nenhuma dessas soluções funcionam sem boas pessoas.
  117. 117. obrigado! @fernahh engineering.contaazul.com

×