GUJ Discussões   :   últimos tópicos   |   categorias   |   GUJ Respostas

Nova arquitetura/infraestrutura de aplicação

angular
java
Tags: #<Tag:0x00007f5156a43360> #<Tag:0x00007f5156a43018>

#1

Pessoal, decidimos (aqui no trabalho) usar o Angular para atualizarmos nossas telas que atualmente são em XML onde converte do XML para telas em html (um meio de deixar padrão em todas as telas do sistema).

Agora vamos querer substituir para usar angular e deixar apenas o que for componente (tipo campo de data, formulários, etc.) e o resto em html mesmo.

Só que nosso problema está na parte de:

  • Como fazer o build em java apenas das telas que forem alteradas e não de tudo.
  • Como fazer com que mantemos essa estrutura de salvar em BD para poder “subir” para produção sem precisar de gmuds (processos de implantar em ambiente de produção)

#2

A estrutura do angular é independente do backend java. Eu optaria por criar um projeto isolado, apenas com o frontend e rodaria num httpd mesmo.

Eu não entendi essa questão, veja, a GMUD (gerência de mudanças) ela não se resume, apenas, a recompilar o artefato e colocar em produção.
Porém, você pode promover o código, tanto back como front, sem a necessidade de envolver nada além de gerar os artefatos e colocar nos respectivos ambientes.
Esse processo pode ser automatizado com a implementação de Maven + Jenkins


#3

Obrigado Darlan pela ajuda…

1ª dúvida: É que a estrutura que está hoje (legado que não podemos tirar ainda), está com esse processo de conversão, por isso do java.

2ª dúvida: A questão da implantação em produção, são os processos de gerar pacote e passar pelas “burocracias”, já sendo direto em BD, podemos alterar quando precisarmos, pelo contrário, tem que envolver áreas e tal.

Não conheço sobre essa parte de Maven + Jenkins, vou dar uma olhada.


#4

Então, se você usar um apache httpd para o front angular, pode configurar de maneira que, achando a página, abre normal, não achando, direciona para a aplicação java.

Você já trabalhou com PHP ou qualquer linguagem de script? Basicamente, você pega a pasta dos códigos prontos e coloca no novo ambiente.


#5

Nunca trabalhei com linguagem de script…

O que queríamos evitar é esse uso de servidores, porque se envolver, entra nessas burocracias que falei, pois não podemos ficar responsáveis pelos servidores, e ficaria em outra área.


#6

Infelizmente, algumas coisas na vida são inevitáveis, afinal, é preciso quebrar os ovos para ter omelete, não?
Eu nunca vi o uso de angular dentro de um projeto java, pois a melhor abordagem é deixar em projetos distintos.
Funciona? Provavelmente, sim, agora, eu desaconselho.


#7

Blz, vlw Darlan mais uma vez pela ajuda… vou passar para o pessoal analisar aqui porque estamos meio que “sem rumo”.

Esqueci de mencionar sobre os acionamentos de serviços (soap) e tal.


#8

O pessoal disse que não podemos ter tudo em um angular só ficaria muito grande (são muitas telas)
Função do java é:

  • Para saber quais modulos angular carregar
  • Registrar acesso
  • Validar sessão
  • Acesso a banco e td mais

#9

Como é, hoje, em java?

Olha, basicamente, você vai criar web services REST, aí você pode usar algo como oauth para autenticar, fica muito mais simples de registrar acesso, validar sessão e controlar o acesso a banco de dados, visto que o angular não faz isso sozinho.


#10

Oi Darlan,

Hoje é uma linguagem “adaptada”… são telas eme xml que passam pelo Java para fazer essas validações e tem algumas telas de configuração que converte algumas TAGs (componentes) em TAGs HTML, como DIVs, Body, etc.


#11

Então, voltamos a omelete e quebrar os ovos.
Existem arquiteturas mais recentes, principalmente no frontend, onde esse tipo de abordagem já não é mais utilizado.
Você tem sim, um (ou mais) template e vários pedaços que se encaixam nele e formam a página que você quer. No angular, por exemplo, chamamos isso de component.
Aliás, esse conceito não é novo, mas, tomou novas proporções com estes frameworks js e os chamados SPA.
É viável? É. É fácil de fazer a troca? Não.


#12

Sim, por essa razão de estar ultrapassado que estamos querendo migrar para tecnologias novas como o Angular e manter esse estilo de component.

Mas nos deparamos com essas questões :frowning:


#13

Toda vez que você mudar a arquitetura para uma mais recente, vai existir problemas. É inevitável.