Gostaria de ler experiências e estratégias que o pessoal aqui usa para desenvolver imensas aplicações Web.
Tentando explicar melhor: Imagine que você tenha uma web app com inúmeros módulos. No seu workspace tem 50 módulos e mais uns 100 importados via jar. Aquele clássico exemplo de aplicação monolítica. Difícil de testar, o build leva horas pra rodar, deploys são complexos (muita coisa pode quebrar).
O que eu gostaria de fazer é criar aplicações menores, mais fáceis de testar, com deploys independentes, integrando todas essas mini-aplicações na principal, que seria só uma casca para essas inúmeras pequenas aplicações.
Seria quase como uma estrutura de micro serviços, mas com apps inteira: front-end + back-end independentes.
Alguém já precisou fazer algo do gênero? Que estratégia usou? Que estratégia usaria num desafio assim?
Acredito que serviços seriam mais adequados se estivesse compondo apenas dados.
Mas estou pensando em uma forma de integrar muito conteúdo html+css+js de uma forma que seja flexível de testar isoladamente e fácil de compor em uma grande aplicação.
A que tipo de componente está se referindo aqui? Alguma referência?
Cheguei a escrever componentes, quando estava respondendo, mas é um termo com tantos sentidos, que deixei de fora na resposta final.
Exato, ter diferentes wars com SSO é o que desejo e relativamente a parte simples da história.
Não entendi como essa integração REST se aplicaria aqui, na prática.
Eu imagino por exemplo, uma simples página (do ponto de vista do usuário) sendo o resultado da composição de diversas aplicações diferentes. Estou preocupado com a forma como cada parte dessa página conversa com o todo, por exemplo:
Identidade visual: como definir um CSS único? Cada um importa o seu?
Interação cliente: como o javascript de uma app pode interagir com o outro?
Quem controla o fluxo da página? Submits? Devo ir full ajax nas iterações do usuário?
Urls significativas: definir algum tipo de namespace para cada app filtrar os parâmetros que lhe são destinados?
Estou particularmente nesse tipo de integração.
[quote=FernandoFranzini]2) Fazer 1 war grande, separado em modulos com virtual deploys de forma que novo deploy, não interrompa as sessions para war antigo.
3) Usar camada de negocio sendo um serviço separado do front-end podendo ser EJB ou POJO simples com REST.
[/quote]
Não acho que essas opções se aplicam nesse caso.
Acho que isso depende. Aplicações evoluem e crescem com o tempo e você lida com a conformidade conforme ela aparece.
As vezes apenas o tamanho da aplicação já é o bastante para tornar os testes lentos. Imagine um portal como o G1, por exemplo. Se a suíte de teste end-2-end deles exercitassem apenas o happy path de cada funcionalidade do site inteiro, quanto tempo não levaria?
[quote=FernandoFranzini]Vc centraliza o CSS num cervidor HTTP e aponta para eles dos wars.
Pelo que vc forneceu de informações…é só isso que eu posso ajudar…[/quote]
FernandoFranzini, agradeço pela tentativa.
Eu provavelmente não dei detalhes suficiente mesmo. As vezes o problema está claro para mim, mas na hora de explicar a gente não o faz de forma clara.
Que outras informações você acha que seriam necessárias exatamente?
Como seria essa separação? Por módulo de funcionalidade? Ou uma mesma funcionalidade seria distribuída entre aplicações diferentes?
O que quero saber é: é possível trabalhar com a ideia de aplicações 100% independentes? Citando um exemplo de uma empresa onde trabalhei:
Na Intranet havia diversas aplicações para os funcionários: site de RH, chamados de TI, consulta de clientes, reembolsos, etc. A Intranet em si era apenas uma tela formada por um Menu de aplicações e um grande frame. Ao selecionar um dos itens, a respectiva aplicação abria no frame; para o usuário era como se fosse uma coisa só, tudo parte de uma grande aplicação “Intranet” mas cada módulo era totalmente isolado, desenvolvido por fornecedores diferentes sem qualquer contato uns com os outros.
Talvez você possa partir daí, mas com as coisas um pouco mais integradas: implementando um Single Sign On, uma aplicação Web dedicada para resources (CSS, JS), integração entre os sistemas através de web service (se necessário).
Já se no seu caso as aplicações forem íntimas umas das outras, compondo funcionalidades em comum, então essa solução pode ficar um pouco estranha.
Bem, por isso perguntei que outras informações você gostaria de saber.
[quote=gomesrod]Como seria essa separação? Por módulo de funcionalidade? Ou uma mesma funcionalidade seria distribuída entre aplicações diferentes?
O que quero saber é: é possível trabalhar com a ideia de aplicações 100% independentes? Citando um exemplo de uma empresa onde trabalhei:
Na Intranet havia diversas aplicações para os funcionários: site de RH, chamados de TI, consulta de clientes, reembolsos, etc. A Intranet em si era apenas uma tela formada por um Menu de aplicações e um grande frame. Ao selecionar um dos itens, a respectiva aplicação abria no frame; para o usuário era como se fosse uma coisa só, tudo parte de uma grande aplicação “Intranet” mas cada módulo era totalmente isolado, desenvolvido por fornecedores diferentes sem qualquer contato uns com os outros.
[/quote]
Respondendo sua pergunta inicial, elas serão sim divididas por funcionalidades e provavelmente não conversam entre sim diretamente.
Eu queria exatamente esse efeito de aplicações isoladas mas sem os problemas tradicionais que o uso de (i)frames traz.
O desafio seria mesclar aplicações diferentes no mesmo html, sem uma influenciar na outra.
Mas é um exemplo de como fazer, vou manter essa idéia como um plano B, caso tudo mais dê errado (ou muito mais complexo de fazer).
Dando um up no tópico, queria ver mais opiniões sobre isso…
Agora uma outra ideia que me ocorreu: E se mudasse radicalmente a estratégia e ao invés de as aplicações “filhas” ficarem dentro da aplicação “mãe”, elas trouxessem a “mãe” para dentro de si? Uma maneira de fazer seria mais ou menos assim:
Primeiramente deixar os recursos que criam o padrão visual (CSS) em um local único acessado pelas aplicações. Depois desenvolver uma taglib que todas as aplicações usam nas páginas para inserir os elementos comuns como Cabeçalhos, Rodapés e Menus.
Dessa forma elas seriam realmente independentes, cada uma abrindo sua página completa, mas parecendo que estão no mesmo site devido a essa padronização visual e de layout.
Como eu disse, foi só uma ideia, não pensei profundamente nas consequências ou dificuldade de implementação, mas talvez valha a pena dar uma olhada.