A era dos

Micro Frontends

William Grasel

@willgmbr

Essa não é talk sobre respostas fáceis ou balas de prata

FrontEnd está cada vez mais difícil e complexo!

Essa é uma talk sobre conceitos de arquitetura e o ecossistema da Web!

E um pouco de minha própria experiência no Itaú Unibanco

Bora lá!

Era uma vez, no hypado mundo de tecnologia...

Alguém teve a maravilhosa ideia:

E se a gente levar micro-serviços para o mundo do FrontEnd?

Trazer um conceito do Back para o Front,

isso já aconteceu antes?

MVC

MVW

MVVM

Que tal?

Nós precisávamos apenas de Componentes!

Precisamos entender o que realmente funciona para a nossa plataforma!

O que vai nos fazer ser mais produtivos e ter mais sanidade mental?

Micro-serviços vai REALMENTE nos funcionar no front?

Buscando a

origem do termo

Primeira referência séria sobre o termo:

Vários outros blog posts e artigos depois disso

Até a criação dessa apresentação...

Ainda não existia nenhuma página na Wikipedia a respeito

Ainda não existia nenhuma manifesto oficial sobre o tema

Nenhum livro impresso detalhando qualquer implementação

Artigos e palestras

não parecem concordar

em todos os princípios, nem na implementação

Pessoas estão usando o mesmo termo para falar de coisas diferentes...

Com modelos de implementação completamente diferentes....

Evolução da Arquitetura da Web

Princípios mais comuns entre os artigos e palestras sobre MFE

Equipes autônomas
Deploys independentes
Bases de código independentes
Ser agnóstico a tecnologia

Agnóstico a tecnologia?

Vamos falar um pouco sobre

Web Performance!

Segundo dados do Google e outras empresas...

Em média sites mobile carregam em

15 segundos!

53% dos usuários abandonam o site se não carregar em

3 segundos!

Sites interativos em menos de 5 segundos têm:

70% de sessões mais longas
35% menos taxa de rejeição
25% mais visibilidade de propagandas

JavaScript é um dos maiores vilões da performance!

200kb de JPG e JS não significa a mesma coisa!

Para atingir os 5 segundos de interação, 300kb de JS seria o máximo aceitável

Normalmente entregamos MUITO mais que 200kb de JS...

Web Performance é um requisito essencial para a maior parte dos casos!

Performance é bem difícil de ser atingida e poder ser facilmente destruída por besteira

Web Performance no contexto de MicroFrontEnd!

Lembra desse exemplo?

Cada framework tem em média ~30kb de JS comprimido

Ter 3 frameworks na mesma página vai te custar 1/3 dos 300kb de JS para 5s de TTL

Esse modelo é completamente INVIÁVEL se seu sistema precisar de performance!

Mas ouvi dizer que o Spotify usa exatamente esse modelo!

Usa sim, mas no app Desktop, onde performance não é um problema

E se os MFE forem divididos por páginas?

MicroFrontEnds na IKEA

Ainda assim cada página teria seu próprio runtime de framework e árvore de dependências

Todo e qualquer tipo de otimização de performance ainda será muito mais difícil...

Autonomia e Isolamento de Tecnologia

O que realmente queremos é Autonomia

Será que realmente precisamos de um total isolamento de tecnologia para sermos autônomos?

A maior parte das grandes empresas de tecnologia tem fortes padrões e restrições de tecnologias

Autonomia não significa liberdade de usar sua tecnologia favorita independente do seu contexto

Se você achou que MFE é apenas para cada time usar o mais novo hype do momento...

Mas as vezes nós realmente precisamos de isolamento total de tecnologia

Caso 1:

Componentes de segurança e autenticação

Caso 2:

Integração e atualização de sistemas legados

Mas mesmo com isolamento completo, você pode ter padrões fortes de ferramentas

WebComponents nativos são a melhor solução para integração numa mesma página

Angular Elements

Mas será que não existe uma opção ainda melhor para um projeto novo?

MicroFrontend Architecture

Isolamento total de tecnologia tem seus próprios problemas

Despadronização

Dependency Hell

Performance

Duplicação de código

E seu eu quiser usar a mesma versão de minhas dependências?

Que versão o Google usa do Angular?

Qual versão do React é usada no Facebook?

A resposta para ambos é a mesma:

Sempre a última!

Só tem uma maneira de conseguir isso: Monorepo!

Quase todas as grandes empresas de tecnologia usam Monorepo!

Todas essas empresas também usam microserviços!

Você não precisa adotar monorepo para empresa inteira

Mas podemos usar monorepos por contexto conforme fizer sentido

Mas se você quer realmente se preocupar com performance...

Mesmo sincronizando todas as versões de todas as dependências

builds e deploys independentes ainda serão um problema!

Tree Shaking:

Uma ferramenta para eliminar código morto

Só conseguimos eliminar código morto entre dependências comuns com um único processo de build e deploy!

Escalando grandes Bases de Código

Muitos de nós já conhecem o conceito de workspace, que é o primeiro passo!

AngularCLI

Workspace

O AngularCLI é extremamente poderoso e extensivo

Mas queríamos algo mais focado para Monorepo mesmo!

Extensible Dev Tools for Monorepos

Conjunto de ferramentas para monorepo que estendem o AngularCLI

Com suporte para outros frameworks, de Front e de Back end!

Alguns comandos:

npm run dep-graph

npm run affected:build

npm run affected:test -- --parallel