Frontend como microservices [Micro Frontends]

[houstondapaz]

Salve!
Estou trabalhando em um projeto para migrar um monolito para microserviços. Já migramos quase todo o back, mas agora surgiu o dilema de como vamos fazer isso com o front. Hoje ele é um app Angularjs (1.3.15) e já decidimos que vamos migrar pra Vue, porem não queremos mais um super front e sim um entrypoint que vai agregar os outros pedaços do sistema.
O problema É como juntar essas partes? Surgiram dois pontos

• Criar os modulos de cada serviço e importar eles no entrypoint;
• Cada serviço disponibilizar um endpoint com seu "bloco" de front e assim no entrypoint ele só agrega esses pontos;

Problemas que ainda ainda não conseguimos pensar/resolver, se escolhido a primeira opção teremos que reimplantar o entrypoint todas as vezes que um serviço for atualizado (acabando com a disponibilidade por conta de um unico ponto).
Escolhendo a segunda opção, como evitar a importação do mesmo modulo várias vezes (exemplo a lib do Vue e qlqr outra lib comum a mais de um serviço) uma vez que pensamos em criar um bundle de cada serviço via webpack e ele cuidar dessa parte de dependencias de modulos.

Enfim, queria saber se alguem já fez algo parecido, se tem uma ideia de como implementar ou uma terceira via.

abrass

[bernardodiasc]

Alo @houstondapaz, só dando um pitaco mesmo, acho que a estrutura de micro serviços para modulos de frontend podem ser vistas como varios apps em uma mesma base de código, por exemplo o front do site e o front do admin, podem ser serviços diferentes rodando na mesma base. Digo, não é uma regra a relação 1 pra 1 entre serviços de back e front. Pra essas preocupações sobre a arquitetura de frontend, recomendo seguir a linha "headless", onde o backend é isolado do(s) front(s) e a comunicação é feita pelas APIs. :)

[wtolotti]

Pra aplicações pequena/mediana, realmente não vejo necessidade de ser um microservice pra cada módulo/componente. A manutenção e legibilidade do código ficará mais dificil, e pode gerar mais problemas com isso.

Acredito que a componentização e uma boa estrutura de pastas/arquivos no repositório, irá abrir mais sua mente.

=)

[ninetails]

Vendo modularização de código, sugeriria muito mais voltar a modularização por componentes/pacotes/módulos que microsserviços.

Com React + Webpack tem o Code Splitting, creio que poderia ser feito algo parecido usando o Lazy Loading, bem semelhante:
https://router.vuejs.org/en/advanced/lazy-loading.html

Aí seu entrypoint seria feito direto no código usando import e não no config do webpack, gerando bundles separados para cada rota (ou componente, se necessário).

[houstondapaz]

@bernardodiasc valeu pelo pitaco rs.
Só para esclarecer melhor, nossa ideia é separar o código em si por responsabilidade, tanto o front quanto o back.
Um exemplo pode ser um modulo de pessoa, hoje já separamos o serviço que faz todo o crud de pessoa, lida com todas as regras de pessoa, mas o front, a tela de cadastro de pessoa, o componente que renderiza essa pessoa na tela, ainda está no "main" junto com os componentes de empresa e tudo mais.
Problema que isso nos causa, tenho que alterar um html lá no componente de login, eu vou ter que gerar o bundle de tudo e subir todo o front, sendo que o sistema inteiro não tem nada haver com isso.
Outro é a separação de conceitos, se eu preciso alterar a forma que o meu servico de pessoa retorna os dados eu vou ter que alterar tb o meu front para se adequar a essa mudança no serviço de pessoa, sendo que se o front dele estivesse na mesma base de código esse problema não iria ocorrer.
Por isso além da separação lógica, tb queremos fazer a separação fisica.

Ahhh obrigado pela dica do "headless" vou dar uma lida.

@wtolotti acho que o que vc flw cai no mesmo caso que expliquei (ou não?)

@ninetails se só fizer via modulos importados direto no entrypoint eu não teria que regerar o bundle toda vez que o modulo for atualizado? Em algum ponto o entrypoint vai ter que saber que aquele modulo existe, mas o que queremos evitar é fazer o deploy do entrypoint só por conta de um update em algum modulo.

Obrigado pelas repostas

[ninetails]

@houstondapaz é, infelizmente do jeito que falei ainda se tem necessidade de regerar o bundle, mesmo pq existem otimizações do webpack que seriam ideais como o CommonChunk e os tree-shaking e sem isso poderia ter código duplicado em bundles diferentes.

mas sobre o code-splitting, o Webpack mesmo gera arquivos diferentes para cada entrypoint, mas somente pros inline (os que forem chamados via System.import, ou só import()). Mesmo separando os arquivos, dado que as configurações estejam corretas no webpack, ele resolve e carrega os arquivos "splittados" somente quando necessário (quando passar pelo import correspondente)

[bernardodiasc]

Entendi que voce quer tipo importar um app dentro de outro app em tempo de uso. Nunca fiz isso, o mais perto que sei li aqui https://medium.com/@tomsoderlund/micro-frontends-a-microservice-approach-to-front-end-web-development-f325ebdadc16

Ao pé da letra, pessoa é um domínio, e domínios se misturam o tempo todo. Pelo que entendi voce tem um serviço pessoa e quer que esse serviço resolva tudo para o domínio? é isso? No seu caso voce vai estar renderizando tambem nesse mesmo mesmo serviço, tipo Vue server-side render?

Na arquitetura headless, o serviço pessoa entregaria dados estruturados nos endpoints, JSON por exemplo, e daí uma aplicação no browser trabalharia com isso, o serviço pessoa não iria conter o frontend. Nesse caso é mais facil fazer uma aplicação que lide com varios domínios e tratar os domínios em seus componentes. Documenta direitinho e valida versão com schema, pimba.

Tem varias formas de fazer isso, não sei qual é a melhor mas vamos vendo ai :D

[houstondapaz]

@bernardodiasc esse link é uma maravilha, abre milhões de possibilidades, tinha visto ele antes mas não achava mais, valeu.

Então é isso mesmo que você disse, mas não necessariamente são apps, são mais para components mesmo.

Mas o server de pessoa não vai devolver o html renderizado, eu vou só expor os js do modulo de pessoa , os components em si e no client que ele se renderiza, busca as infos na api de pessoa e tudo mais.

E depois que eu li o headless, é basicamente o que fazemos hoje em dia né? Um front independente que só busca no server os dados.

A treta é como "servir" esses components, vindo de dominios diferentes, mas já to pegando algumas coisas, esse projeto tem uma arquitetura legal a ser seguida, usando SystemJS.

Uma saida que encontrei para a não duplicação dos modulos comuns é importar eles no entrypoint e não incluir no bundle dos components especificos.

@ninetails Eu tava vendo o esquema do code-splitting do webpack, mas ele cria uma referencia para um arquivo que ele cria e não trabalha com arquivos fora do bundle que ele cria, ou estou errado?

[ninetails]

@houstondapaz sim, no webpack para trabalhar com arquivos de fora do bundle creio que seria usar externals.

[houstondapaz]

@ninetails não conhecia o externals parece interessante

[ghost]

@houstondapaz já viu: Mosaic da Zalando?

É algo que pode te ajudar a nível de estudo de arquitetura. Eu comecei a fazer algo sobre o assunto mas nada a nível de implementações reais mas estou certo que próximo passo para nossa aplicação aqui será um passo como esse até por que temos muitos squads!

Espero ter contribuido =)

[houstondapaz]

Salve @edmolima muito foda essas libs deles, da pra explorar por varios pontos.
Inclusive vendo a arquitetura deles arbiu minha mente de fazer esse esquema de um server simples só para melhorar o retorno pro client (estou vendo mais o Tailor).

Valeu mesmo

[ghost]

Acredito que o @rubenspgcavalcante caso tu precise tirar dúvida seja um cara que pode te ajudar muito @houstondapaz, ele me mostrou esse projeto e é um brazuca que trabalha na Zalando \o/

[rubenspgcavalcante]

Opa, tamo aew @edmolima! :D
Cara, eh um tema muito complexo, porem ultra interessante. A primeira coisa eh se perguntar em qual nível de modularização voce realmente precisa em seu projeto. Por exemplo, aqui na Zalando, os times são organizados em micro-teams (refletindo sua abordagem de micro-services e API first). Temos diversos times que cuidam da online store, então como fazer com que esses caras consigam ser ultra independentes e trabalhem separados?
No front, temos o time de busca, o de sugestões, o de artigos, etc. Cada bloquinho da página fica como responsabilidade de seus respectivos times.
Portanto, como a empresa eh grande (mais de 1000 funcionarios soh no Tech) isso foi meio que uma decisao obrigatoria pra conseguir escalar, nao so os sistemas mas os times em geral.
Eu nao estou trabalhando diretamente na store, estou atualmente na zalon.de, então não trabalho diretamente (ainda) com "micro-services" no front, porem voce pode dar uma olhada nesse projeto bacana que eh utilizado para o site main (zalando.de).
https://www.mosaic9.org/

Voce pode tbm abordar de forma mais simples, algo parecido com o que eu fiz na minha antiga empresa. Lá nos necessitávamos de uma dashboard totalmente customizável, e que novos widgets pudessem ser lançados de forma simples e rápida. Na epoca tbm estavámos usando angular 1.x.
Basicamente você vai utilizar AMD para fazer o carregamento (assim como no mosaic), mas todo componente vai respeitar uma certa interface (inclusive o projeto dos widgets eu utilizei TypeScript, o que caiu como uma luva 😄 ), fazer seu projeto principal carregar e instanciar o componente com o que for necessário (aqui você pode fazer a injeção das dependências) e depois renderizar o componente.
O projeto com os widgets era totalmente separado, com deploy em outro CDN, e com seu repositorio proprio. Você pode controlar o que esse projeto disponibiliza de componentes usando um simples arquivo manifesto. Algo muuuuito importante que voce deve se preocupar tbm eh com a versao das bibliotecas. Existem duas formas de abordar isso, cada componente carrega suas dependências (não aconselho) ou simplesmente criar um repositório de dependências fixada/global, deixando duas "major/breaking" versions para dependencias mais criticas, dando deprecation warnings para a mais antiga quando novas versões vierem, e injetá-las na fase de instanciação do componente. Eu prefiro a injeção de dependencias do que cada componente carregar suas deps, pois isso causa um inchaço desnecessário.

Enfim, dá uma estudada e escolhe a melhor opção! Qq coisa estamos aqui, soh falar! :D

[adrianojdesouza]

Aqui na Arquivei nós usamos o front como um "micro-serviço", dessa forma nós trabalhamos isolados do time de backend.
Normalmente ficamos um sprint a frente deles, fazemos todas as funcionalidades mockando os dados, nossa aplicação no front funciona independente do backend, só não persiste os dados.
Terminado o desenvolvimento da funcionalidade no front nós integramos com o pessoal de backend, nessa fase eles já sabem como tem que enviar os dados para nós do front.
O legal é que assim vamos migrando aos poucos, temos páginas que estão no modelo antigo e páginas utilizando o front como micro-serviço.
Espero que tenha dado pra entender, qualquer só comentar ou mandar alguma mensagem pra trocar idéia 😄

[khaueviana]

@adrianojdesouza isso é o "micro-frontend" ou apenas uma divisão de front / back?

[ninetails]

Pra Webpack:

Tem o externals

diversos plugins pra pegar lib de CDN (creio que isolaria libs)

ou senão utilizar o Webpack DLL Plugin e deixar o mesmo caminho pros split chunks (não tem mais common chunks na versão 4)

[AlisonVilela]

+1

[GustavoGottardi]

Alguém já utilizou o projeto: https://single-spa.js.org/ para realizar o desenvolvimento front-end como microserviços? Se sim, sabem me dizer prós e contras dele? Ou a experiência que obteve utilizando o mesmo...

Estou pensando em implementá-lo na empresa que estou atualmente, pois aqui temos apps legados AngularJS + jQuery (Sim colocaram jQuery junto no controller do AngularJS, quem nunca... rsrs) e como não temos tempo de reescrever o que já está funcionando por enquanto, estou pensando em utilizá-lo para poder desenvolver as novas features com um framework mais atual.

[alexsandro-xpt]

@GustavoGottardi este Single SPA é novo? Não lembro de ter falando dele aqui neste post... Vou dar uma olha pra testar algo..

[klarkc]

Olhando um pouco para a plataforma acredito que não buildar os serviços em bundle de módulos faça bastante sentido nesse cenário.

Usar es6 modules e construir web components que interajam entre si via um serviço de integração ou com as api's. O Google é mestre em fazer isso, parte do YouTube funciona assim. Dois requisitos dessa abordagem seriam servir com http2 para obter performance e usar polyfill em navegadores legados.

[joaogoya]

@GustavoGottardi
Cara quando iniciamos o projeto eu cheguei a dar uma olhada nesse cara.
Acabei optando por fazer na mao.
É um assunto muito novo e eu nao me senti mt seguro em colocar o projeto em cima de uma ferramenta. Não me senti seguro com a ideia de depender da ferramenta ta ligado.

Mas não tenho nada contra.
Só acho que microfrontend é um assunto que ainda ta engatinhando.
Vai levar mais um tempinho para termos os handbooks de boas praticas.
Até lá eu prefiro nao depender muito das ferramentas.

Mas brother se tu usar, compartilha conosco pfv :D

Abrasss

[alexsandro-xpt]

Pessoal saiu um vídeo sobre nosso assunto:
Why would you even want to move to a microfrontends architecture?
https://www.youtube.com/watch?v=Td7w0_nD5_4

[alexsandro-xpt]

Mais um nova talk sobre o assunto.

https://www.youtube.com/watch?v=TQoABqkPkAE

[eliseumds]

Empresas gigantescas como FB, Amazon e Google já têm micro-frontends em produção, mas não são muito bem otimizados. Ao abrir o source code você pode perceber chunks de código repetidos, mas na escala deles faz sentido. O problema é extremamente complexo e o ScriptedAlchemy está trabalhando numa solução com Webpack pra deixar os bundles mais leves: https://github.com/ScriptedAlchemy/webpack-external-import (atenção: esse projeto definitivamente não está pronto pra produção, só dê uma olhada por curiosidade).

Discussão no repositório do Webpack: webpack/webpack#10352

[felipefialho]

Em 2020, alguém mais tem cases e experiências de uso real de Microfrontends? 😄

[fsblemos]

@felipefialho gravamos um podcast no hipsters sobre o case da Conta Azul 😁https://hipsters.tech/micro-frontends-no-conta-azul-hipsters-on-the-road-26/

[ScriptedAlchemy]

@eliseumds It will be for Webpack 5, with a backport to WP4. The rewrite is nearing completion and we will probably begin testing it in production this week. There is a v3 branch which contains the rewrite for webpack core

[felipefialho]

@fsblemos Obrigado pelo link, acabei de escutar tudo.

Parte dos problemas que vocês enfrentaram eu imaginei que aconteceriam, acho que com o tempo vocês vão resolvendo alguns deles. Mas o case de vocês é enorme, conseguiram arrumar uma solução viável em cima de um projeto legado.

Sensacional 😄

[leandromatos]

Alguém aqui teve a necessidade de trabalhar com microfront com server side rendering? Se sim, como resolveu essa questão?

Vejo pouquíssimos materiais mais amplos sobre microfront com SSR, na verdade quase nada.

[guilhermeabell]

Estou curioso sobre esse assunto também.

[ScriptedAlchemy]

@leandromatos yes i have. expose a rendering API and have the MFE being loaded make a call to another one to get the rendered html. Or use ESI with a CDN

I also am working on federated SSR with the webpack core upgrades I'm working on.

https://levelup.gitconnected.com/micro-frontend-architecture-replacing-a-monolith-from-the-inside-out-61f60d2e14c1