Arquitetura do front-end de uma aplicação de grande/enorme porte

[akfzambrana]

Boa tarde pessoas.

Venho aqui consultar a sabedoria de vocês para me guiar, pois estou procurando por material, livros, apostilas, links, artigos, monografias, etc sobre arquitetura de software mas voltada pro mundo front-end/client-side. Independente de framework, algo que me ajude a criar uma base para uma aplicação de porte enorme e com "features" desconhecidas que sera desenvolvida nos proximos 3 a 5 anos, ou seja, a base precisa ser sustentavel, escalavel e o mais desacoplada possivel pois não sabemos onde estaremos em 3 anos.

Tenho lido bastante sobre arquitetura de software mesmo, mas não tenho achado nada aplicado ao frontend ou que demonstre algum caso de uso.

Me ajudam?

Não preciso de tutorial e sim de material mais conceitual mesmo, com pros e contras das soluções para ver o que atende melhor a necessidade da nossa aplicação.

bjs!

PS: Tenho pensado em uma arquitetura hexagonal mas não consigo pensar em uma forma de implementar ou pelo menos um exeplo ou caso de uso utilizando tecnologia frontend.

[WandersonAlves]

@akfzambrana Não sei se te ajuda, mas ontem, vi essa palestra e achei bacana.

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

[laurindo]

@akfzambrana

Para o back-end, eu curto muito esse link aqui:
http://adrianmejia.com/blog/2016/03/23/how-to-scale-a-nodejs-app-based-on-number-of-users/

Para o front-end eu gosto de fazer a aplicação baseado em features, acredito ser facil de escalar adicionando mais features a medida que a aplicação cresce.

• Outros links de ajuda:
  https://medium.com/unboxd/how-i-built-an-app-with-500-000-users-in-5-days-on-a-100-server-77deeb238e83
  https://www.nginx.com/blog/5-performance-tips-for-node-js-applications/

• Livro
  https://www.amazon.com.br/Introdu%C3%A7%C3%A3o-%C3%A0-Arquitetura-Design-Software/dp/8535250298?tag=goog0ef-20&smid=A1ZZFT5FULY4LN&ascsubtag=5ee78b79-c6fd-48b1-8517-5b3ca84fafe1

[akfzambrana]

@laurindo to lendo esse livro, mas é muito frustrante pq todos os exemplos estão com Java :(
(vou ler os artigos, vlw)

[barbier]

Olá! :)
Já deu uma olhada nos livros Frontend Architecture for Design Systems e Developing Large Web Applications?

[ghost]

@akfzambrana estou atualmente em um projeto que trabalhamos com a arquitetura que o @WandersonAlves apresentou e você o chama de modelo hexagonal.

A gente seguiu muito o caminho de jornada do herói, pegamos nossa aplicação e entendemos o que cada parte fazia realmente. Separamos cada uma em seus domínios (DDD) e criamos os "micro-frontends".

Existem inúmeras formas de fazer isso, mas adaptamos o que encontramos pelo caminho. Mais do que te dizer como escalamos isso e fico a disposição caso queira bater um papo, só chamar lá no twitter, aqui vai alguns materiais que usamos para decidir sobre a arquitetura:

Conteúdos:
Tech Radar
Wilson Mendes: Micro Frontend - A Microservice Architecture From Frontend
RSconf2018. Introduction to Micro Frontends

Livros:
Architecture Frontend

Bom no geral a decisão saiu por ai e principalmente testando antes, fizemos uma poc e etc. Bom dando depoimento próprio, depois de 80% do projeto completo te digo escalar isso tá sendo muito fácil, basicamente envolve um orquestrador de containers e a amazon hehehe.

[laurindo]

@edmolima Legal viu. Estou ouvindo falar muito de micro-frontend.
Quero em breve fazer alguns testes.

[linconkusunoki]

Achei isso aqui neste fórum #661
Vale a pena dar uma olhada na discussão

[ghost]

Boa @laurindo a gente aqui vem trabalhando muito na divisão por dominio, mais do que segmentar componentes em uma interface, nós entendemos que os webapps deveriam seguir seu próprio caminho (jornada).

[munizart]

Independente da arquitetura que for escolher, é importante ter em mente os testes também.
Ter um processo de desenvolvimento que exige do programador testes unitários e de integração, com uma infraestrutura de teste automatizados que podem ser repetidos a cada vez que um código novo é inserido na base (testes de regressão) ajuda a garantir que um código novo não vai quebrar nada que já estava funcionando.

Outra coisa importante pra se ter em mente é uma arquitetura que permita que a aplicação não cresça mais que o necessário, ou seja, uma arquitetura onde fique claro quando uma parte de código pode ser removida e que isso seja fácil de ser feito.

Aqui falam de de um hipotético framework que permite uma arvore de dependências reversa, onde os componentes se cadastram num repositório e configuram a rota onde serão usados, permitindo a remoção do componente por simplesmente remover o arquivo: designing very large javascript applications por @cramforce.

Lembrem-se: Codigo sem teste é codigo legado e, na maior parte do tempo, só teste unitário não basta.

[akfzambrana]

Obrigada @edmolima vou dar uma olhada nessas coisas e com certeza vou te procurar para conversar no twitter.

@munizart a gente ja implementa testes unitários e temos testes de QA automatizados e manuais, o grande problema q temos hoje em dia é acoplamento entre os diversos "dominios" e não estamos nem em 20% do desenvolvimento da aplicação como um todo e isso esta se tornando algo muito dificil de lidar e manter, sem contar que esta ficando insustentavel e não vai dar pra escalar como precisamos.

[gabrielsimas]

Amigos.
Obrigado por todos vocês existirem!
Espero um dia poder contribuir com o meu conhecimento, assim como vocês estão fazendo! Aprendo muito neste grupo!

[houstondapaz]

@akfzambrana Adotamos a ideia de microfrontends e estamos bem felizes aqui, a issue que o @linconkusunoki citou me ajudou muito. A ultima resposto do (@thiagoxvo) tem uma série bem esclarecedora, acabamos optando por IFrames para fazer a montagem e está nos servindo muito bem

[akfzambrana]

@houstondapaz e como vocês fazem a integração entre as micro aplicações? como elas se comunicam?

[houstondapaz]

@akfzambrana fazemos a comunicação via postMessage e eventos no window

Aqui como o serviço recebe o postMessage

const eventMethod = window.addEventListener ? 'addEventListener' : 'attachEvent'
const messageEvent = eventMethod === 'attachEvent' ? 'onmessage' : 'message'

const EVENTS = {
  eventName(){}
}

window[eventMethod](messageEvent, event => {
  if (event.data.serviceId === SERVICE_ID && EVENTS[event.data.name]) {
    EVENTS[event.data.name](event)
  }
}, false)

E assim que enviamos pro serviço

_services[serviceName].postMessage({
  serviceId:idDoServico,
  name:'eventName',
  data:dadosQuePrecisaEnviar
}, '*');

Deu pra entender?
Acho que vou escrever um post para mostrar o passo a passo

[woliveiras]

Acho que vou escrever um post para mostrar o passo a passo

Seria lindo, @houstondapaz

[alexsandro-xpt]

@akfzambrana Já ouvi falar desta lib aqui? https://github.com/zalando/tailor Ela tem este intuito, eu estava procurando sobre o assunto estes dias que vi umas coisas interessantes usando ela.

O que voce acha?

Tem umas Demos bem promissoras no link ai, olha esta https://github.com/tsnolan23/tailor-react-spa

[alexsandro-xpt]

@houstondapaz com IFrames vocês conseguiram trabalhar normalmente com responsividade? e como esta o desempenho do uso de memoria da página?

[ninetails]

aproveitando a pergunta, tiveram algum problema com o Chrome nas últimas versões que, por motivos de segurança, ter deixado por padrão iframes em processos separados?

[houstondapaz]

Oi @alexsandro-xpt , eu dei uma olhada no tailor sim, não lembro bem o motivo agora de não termos adotado, mas como era (ainda é) uma migração de angularjs para vue, acabamos optando por segregar totalmente os ambientes, no caso o iframe.

A responsividade é um ponto bem complicado msm, pq a pagina principal tem q ir "conversando" com as partes para mudar o estilo dela.

@ninetails não tivemos nenhum problema, como já fazemos a comunicação via postMessage, segue as regras de segurança do navegador

[alexsandro-xpt]

@houstondapaz sinto que vocês estão investindo pesado neste negocio usando iframe. Não vejo isto como a melhor opção mas imagino que foi a unica que você pode usar no momento.

Eu vou por enquanto fazer algumas PoC usando o Tailor, mas pra mim, isto vai ter que amadurecer muito ainda por razões de engenharia..

[houstondapaz]

@alexsandro-xpt na real temos um esquema de apps dentro do nosso app, então esses apps que estão sendo carregados via iframe, então eles podem usar qualquer lib, router e tudo mais, e pelo iframe temos certeza que não vai interferir no resto do site;

Dei uma reestudada no tailor esse fds, ele realmente resolve muitos dos problemas, ainda mais com o uso do webpack para organizar os modulos, sem o webpack ia ficar beeeem difícil organizar e controlar as dependências de cada parte do site;
Penei um pouco com o esquema de rotas, ainda mais pensando que cada micro-front pode implantar suas próprias rotas, a "solução" que achei foi cada front ter sua rota base e a partir dela ele se garante, como vc pensou nisso?

[alexsandro-xpt]

@houstondapaz ta ai um negocio que voce disse que tem anos que gostaria de fazer direito.
Apps/features instaláveis dentro de uma App casca. Mas sem usar IFrame.

Tailor parece esta interessante, mas acho que precisam resolver os bundle de forma melhor atraves de contratos estabelecido por por exemplo um Webpack da vida.

Verdade tambem imagino que um micro-front pode implantar suas próprias rotas e com cada rota o JS propagasse esta rota para o backend em Node que seria capaz de propagar pra cada microfrontend e pegar uma resposta caso existisse esta rota no microfronted.

Foi assim que pensei... Eu vi que o pessoal do Tailor tem uma lib de rotas, so não sei real proposito dela ainda com Tailor.. talvez tem haver com que eu disse. Se não, uma nova lib disto deveria se feito.

[houstondapaz]

Cara, não tenha medo do iframe, ele é seu amiguinho, se usar bem e pros propósitos certos ele funciona que é uma beleza!

Se tratando de apps dentro de uma aplicação a ideia do iframe é mais que uma boa pedida, pq assim vc isola o app e só manda pra ele as infos que vc quer, ainda mais se vc pensar que pode ter apps de terceiros nessa jogada, jogar isso dentro do seu dominio pode dar umas bostas grandes.

Já como feature ai sim a ideia do tailor fica mais interessante, não só a do tailor o de como esse cara fez ficou sensacional.

Aqui tem um exemplo com cada elemento resolvendo sua rota, bem simples mas já é um caminho para pensar.

Tailor parece esta interessante, mas acho que precisam resolver os bundle de forma melhor atraves de contratos estabelecido por por exemplo um Webpack da vida.

O que você quis dizer com isso?

E o Project Mosaic tem muito mais coisa que o tailor né? Mas a parte de rota eu acho q é melhor resolver no proprio front msm, independente de um backend pra isso

[dougaraujos]

o de como esse cara fez ficou sensacional.

@houstondapaz Valeu por compartilhar, ótimo guia! (apesar que o próprio autor mudou de opinião depois rs)

[alexsandro-xpt]

@houstondapaz Então da forma que você falou justifica sim usar os Iframes.

Agora como feature que é meu interesse, o Tailor é começo uma saída hoje em dia. Vou olhar estes links que mandou.

Agora sobre o que quis dizer é entre os features project, o backend node quando unir todos os microfrontend seria muito interessante se fissem um tree shaking para evitar codigo JS desnecessário como libs repetidas para que todo código da pagina não fique muito pesado pra baixar.