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

1. do jQuery aos microfrontends:
os desafios de
manter uma
aplicação web.

2. Antes de
tudo, uma
história real.

3. Desenvolver componente de
autocomplete
Created 30 min ago

5. <input id="autocomplete" placeholder="Busque..." />
<script src="autocomplete.js"></script>
<script>
autocomplete("#autocomplete", {})
</script>

7. Hoisting em JavaScript é o que
acontece quando funções e
variáveis são elevadas ao topo de
um escopo.

8. @fernahh
fernahh.com

9. ContaAzul
contaazul.com/vagas

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

11. Nosso tamanho
350+ funcionários
4.000+ escritórios contábeis
parceiros
1.000.000+ empresas já
começaram a usar

12. Nossas
primeiras
tecnologias.

13. Apresentação
Negócio
Dados

14. Apresentação
Negócio
Dados
Tudo em um mesmo
servidor, como a maioria
das aplicações da época.

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

16. Interfaces web são assíncronas,
onde temos dois agentes de
mudança: usuário e servidor.

17. Nome
Categoria
Cadastro de Produto
Salvar

18. Nome
Categoria
Cadastro de Produto
Salvar
1. $.keyup()
2. $.addClass()
3. $.removeClass()

19. Nome
Categoria
Cadastro de Produto
Salvar
1. $.click()
2. $.get()
3. $.appendTo()

20. Nome
Categoria
Cadastro de Produto
Salvar
1. $.click()
2. $.post()
3. $(location).attr()

21. Por vários anos, o paradigma
orientado a eventos reinou sobre o
desenvolvimento web.

22. Aprendemos que o DOM é lento, e
escrever código performático na
maioria das vezes prejudica a
legibilidade.

23. Mesmo quando JavaScript era
usado apenas para “validar
formulários”, a chance dele se
tornar um caos era muito grande.

24. AMD como sistema de
módulos

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

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

27. Enquanto isso o mercado estava
cada vez mais desenvolvendo
aplicações com tecnologias web.

28. Ter apenas um software “na
nuvem” já não era mais um
diferencial.

29. Requisitos
universais de
uma aplicação
web.

30. Atrativa
Simples de usar
Acessível
Rápida

31. Atrativa
Simples de usar
Acessível
Rápida
Design
Usabilidade
Acessibilidade
Performance

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

33. “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

34. …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

35. 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)

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

37. As limitações
da web como
plataforma.

38. Apresentação
Negócio
Dados

39. “We are basically hacking
Microsoft Word to run apps.”
@ken_wheeler
http://coldfront.surge.sh/

40. Apesar de ser a maior plataforma de
desenvolvimento de software, o
browser possui sérias limitações.

41. APIs são inconsistentes
Para cada web API existem inúmeras
bibliotecas de abstração.

42. Manter estado é um desafio
O estado em uma aplicação web precisa
estar em sincronia com a URL do usuário.

43. Instabilidade de conexão
A conexão dos usuários é lenta,
totalmente instável e heterogênea.

44. Front-end não é fácil
Não é a toa que existem inúmeras
tentativas de não escrever HTML, CSS e
Javascript.

45. Reescrever aplicações quase
nunca é uma boa ideia.

46. Especificação
Ao longo do tempo muitas melhorias e
correções são desenvolvidas, e nunca são
documentadas.

47. Custo
Uma aplicação de tamanho médio, vai
levar no mínimo ~6 meses para ficar
pronta.

48. http://www.ben-morris.com/why-refactoring-code-is-almost-always-better-than-rewriting-it/

49. O advento das
ferramentas
JavaScript.

50. HTML

51. HTML
CSS

52. HTML
CSS
JavaScript

53. JavaScript
CSS
HTML

54. Além de comportamento, hoje o
JavaScript atua na entrega de
conteúdo, faz build também é
responsável pelo estilo.

55. JavaScript é, indiscutivelmente, a
linguagem mais importe da década.

56. JavaScript é, indiscutivelmente, a
linguagem mais importe da década.

57. Backbone
Angular
Ember
React
Vue

58. Data Binding e
MV* Frameworks
foram boas ideias...

59. Data Binding
Permite que possamos conectar
mudanças de um modelo para a UI.

60. API
Model
Template
Merge View
JSON
JavaScript
Linguagem
de template
HTML

61. Two-way Data Binding
Além do fluxo do modelo para a UI, nessa
abordagem a UI também faz atualizações
no modelo.

62. API Model
View
JSON JavaScript
HTML
Template
Linguagem
de template
Compile

63. API Model
View
JSON JavaScript
HTML
Template
Linguagem
de template
Compile
“seria o fim dos
callbacks?”

64. AngularJS como framework
front-end

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

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

67. Side effects
O código é difícil de testar, o que se
resulta em medo de fazer refactoring e
corrigir bugs.

68. Código duplicado
No modelo MVC tudo é orientado a view.
Filters e diretivas não são muito
amigáveis com perfomance.

69. Depreciação e código legado
É difícil usar “novas” features do
JavaScript e a atualização de bibliotecas
se tornam caras de implementar.

70. Jornada em
busca de
produtividade.

71. Paradigmas baseados em
componentes ganharam mercado.

72. Abstração

73. Salvar
Possibilidades de uso
● Receber um texto
● Receber um ícone
● Disparar uma ação

74. R$ 100 Salvar
Possibilidades de uso
● Receber um texto
● Receber um ícone
● Disparar uma ação

75. R$ 100 Salvar
Possibilidades de uso
● Receber um texto
● Receber um ícone
● Disparar uma ação
● Receber um totalizador (????)
updateTotal()

76. Salvar
<ca-button
data-text="Salvar"
data-action="save()"/>

77. Salvar
<ca-totals
data-value="total"/>
Total: R$ 100
<ca-button
data-text="Salvar"
data-action="save()"/>

78. “Ao abstrair tornar mais
polimórfico, você está restringindo
o espaço de implementação,
diminuindo a possibilidade de
erros.”
@rodrigowillrich

79. Facilidade para
testar

80. Testes end-to-end
São difíceis de manter em grande escala,
mas numa lib de componentes talvez faça
sentido.

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

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

83. Reuso de
código

84. Possibilidade de pensar no
WOW!

85. Criamos uma biblioteca de
componentes “vanilla”

86. good parts
Componentes
Vanilla
● Ter o CSS em folhas de estilo
facilitam o uso entre tecnologias
diferentes.
● Apenas instanciar um objeto
padroniza comportamentos.

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

88. O que fazer com o código legado?

89. Como
sobreviver sem
reescrever tudo.

90. Dor
Recurso
Soluções
Continuidade

91. Dor
Recurso
Soluções
Continuidade

92. Antes de tudo, é preciso saber onde
estão as dores do time.

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

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

95. O Santo Graal da arquitetura de
software não existe.

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

97. É 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

98. Nerd adora falar mal
de tecnologia.
https://engineering.contaazul.com/o-santo-graal-da-arquitetura-de-software-n%C3%A3o-exi
ste-7c4cdcc75475

99. “We don’t hire people to write
code. We hire them to solve
problems.”
Jem Young
https://twitter.com/NetflixUIE/status/1012568486848000000

100. Dor
Recurso
Soluções
Continuidade

101. Modelo de maturidade
É um modelo que ajuda a determinar a
eficácia de um software e onde ele pode
ter um desempenho melhor.

102. https://www.martinfowler.com/bliki/MaturityModel.html

103. https://info.thoughtworks.com/rs/thoughtworks2/images/agile_maturity_model.pdf

104. “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

105. Dor
Recurso
Soluções
Continuidade

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

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

108. Dor
Recurso
Soluções
Continuidade

109. Vale a pena desenvolver produtos com
AngularJS?

110. “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

111. Microfrotends

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

113. “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

114. Mount
Rota indica
um módulo
Request
do
módulo

115. https://engineering.contaazul.com/evolving-an-angularjs-application-using-microfrontends-
2bbcac9c023a

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

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

118. Nenhuma dessas soluções
funcionam sem boas pessoas.

119. obrigado!
@fernahh
engineering.contaazul.com