Como gerenciar o frontend em uma arquitetura que está indo do monolítico para microservices ?

[robisson]

Fala galera,

Estamos com o desafio de migrar uma aplicação monolítica gigante ( pense em 9 anos de desenvolvimento ) para uma arquitetura de microservices. As questões de banco de dados e backend quanto a decomposição do sistema e como fazer isso em etapas está bem definida. Até mesmo as questões de testes, orquestração e deploy.

A dúvida que estamos é com relação ao frontend. Como as questões abaixo:

Montamos um frontend único(monílitico) que se alimenta de vários serviços backend ?

Essa abordagem nos deixa com arquitetura baseada em serviços apenas no backend e a medida que o tempo for passando vamos ter um frontend cada vez maior e dificultando mudanças e atualizações.

Dividimos toda a aplicação em serviços totalmente independentes, cada um com sua lógica, e assets
js,css e html e apenas um gateway para transformar tudo isso em uma página web ?

Essa abordagem vem com outras questões que me preocupam.
Como cada parte da aplicação tem tudo que é necessário para funcionar, isto é, seus próprio css, js e html , é possível que exista partes duplicadas de código ou dependências de css e js.
Conforme a aplicação evolui é possível que alguns serviços já usem uma versão de React por exemplo enquanto outras mais novas já utilizem uma mais nova e isso pode gerar conflitos.

Tenho lido lido muitos livros que falam de microservices e visitado muitos artigos, mas parece que a grande maioria dos conteúdos abordam questões do que são microserviços, como dividir e manter a aplicação, e aqueles que falam de implementação geralmente falam apenas de backend.

Para aqueles que estão vivendo esse momento de definição de arquitetura, como vocês tem resolvido questões como essa no frontend ?

[mtmr0x]

Nesse conceito um endpoint de busca pode ser um monolito também.

Pode ser ruim em performance e versao de estilos ter serviços front end separados. Ja pensou no tamanho do seu time e gerenciamento de repositorios?

Eu te diria que seu front end é um micro serviço, um cliente para ser conectado numa interface (API).

Se fizer seu CSS inteligente, fica pequeno, se tacar pau no gzip no build do seu JS, tbm consegue bom resultado.

Eu diria que pode ser ruim ter micro servicos para seu site, a nao ser que tu tenha uma aplicação imensa, não sei seu caso, mas eis sao meus 2 cents.

Beijos de ;

[robisson]

Obrigado @mtmr0x pelas dicas, a aplicação realmente é muito grande, é um ERP integrado com bancos de dados de outros ERPs para retornar resultados, tudo sendo acessado diretamente. Para uma aplicação monolitica está bem escrita até( no classico MVC) , mas olhando para frente o tamanho preocupa.

[felipeuntill]

TL;DR

Obviamente não sou um especialista em microservices todavia tive a oportunidade de gerir vários projetos utilizando este tipo de arquitetura e aprendi que este tipo de componentização definitivamente não é uma bala de prata, principalmente em projetos com muitas regras de negócio como é o seu caso.

Os micro serviços chegaram ao seu ápice após o artigo do nosso amigo Martin Fowler e como tem acontecido com todas as busswords do mercado, instantaneamente virou "a melhor pratica para desenvolvimento de projetos". No mundo real gerir este tipo de arquitetura é significamente mais trabalhoso que gerir uma arquitetura monolítica.

Um artigo muito bacana que ajuda a explicar um pouquinho da complexidade de dividir uma aplicação em microservices => Microservices: Decomposição de Aplicações para Implantação e Escalabilidade

O padrão SOA já apresentava muito dos paradigmas e conceitos de aplicações distribuidas e adotar este tipo de padrão vai ter suas consequências sim!

Montamos um frontend único(monílitico) que se alimenta de vários serviços backend ?
Acredito que este modelo seria o mais adequado para um ERP, obviamente mudar e atualizar vai dar trabalho porém isso pode ser mitigado com a criação de midlewares para que seus recursos não fiquem fortemente acoplados a nenhum framework.
Ex: Supondo que seu frontend seja Angular e você esteja usando o $http para as requisições, encapsule este tipo de recurso em um método proprietário e quando for necessário migrar você só precisará substituir o $http uma única vez.

Dividimos toda a aplicação em serviços totalmente independentes, cada um com sua lógica, e assets
js,css e html e apenas um gateway para transformar tudo isso em uma página web ?
Mesmo o recurso mais vagabundo do mundo aprende algo diariamente, principalmente com o resultado do seu próprio trabalho, adotando este modelo bastarão 3 meses pra que você passe a ter LEGADOS dentro da sua arquitetura, uma vez que os novos projetos estarão recebendo novas funcionalidades e os desenvolvedores estarão mais maduros e os micro serviços implementados não terão acesso a este amadurecimento uma vez que já foram entregues.

Antes de pensar em dividir pense no processo de atualização e seja honesto consigo mesmo, são poucas as empresas que deixam agente voltar em antigos projetos para conseguirmos corrigir o que não implementamos devidamente.
Microserviços só vão aumentar a incidência deste tipo de problema uma vez que arrumar justificativa pra mexer em outra aplicação/projeto vai ser ainda mais difícil que no famoso monolitinho

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

[geidsonc]

Olá @robisson, sei que tem já tem algum tempo, mas poderia compartilhar qual foi a escolha da empresa e as experiências na migração do frontend?

[robisson]

Fala @geidsonc ,

Depois um tempo analisando e discutindo, a abordagem que tomamos foi deixar o frontend monolítico mesmo.

Ainda temos aquela imensa aplicação monolítica, porém todo a manutenção e melhoria que fizemos a gente migra o que pode. No backend começam a ter microserviços utilizando arquitetura orientada a eventos baseada CQRS e Event Sourcing e com Message Queue do Google PubSub. Há 3 anos essa aplicação rodava on-premises, hoje roda no GCP com Kubernetes e Istio Service Mesh, tanto a parte legada quanto a nova.

No frontend adotamos o ReactJs, refizemos a home da aplicação apenas, para apontar os link para a parte antiga ou nova. E toda a nova interface é feita já em ReactJs, melhorias que valem a pena também.

Esse frontend fica todo em um único repositório, rodando em um único servidor, na verdade servidor não, nós exportamos todos os estáticos e hospedemos no Google Cloud Storage com o Google Cloud CDN junto, assim essas requisições nem utilizam backend algum nosso. Preferimos não usar server-side renderer.

Também utilizamos service workers para fazer cache do lado do cliente e code-spliting sempre que possível, por rota ou em componentes complexos mesmo. Isso nos ajuda a ter a aplicação sendo carregada somente a parte que é realmente necessária. Teste unitário com o máximo de cobertura possível também.

Com isso conseguimos ter a aplicação rodando sob o cache da CDN e também do lado do cliente.

Em resumo foi mais ou menos isso que fizemos.