1
resposta

melhor estrutura front-back rest/jsf

olá, eu tenho algumas dúvidas em relação à estrutura dos projetos quando se utiliza muitas integrações.. Já passei por várias equipes e cada uma fazia de um jeito, então ainda não consegui encontrar uma linha lógica para a construção dos projetos. Por exemplo

Vamos considerar um gateway de pagamentos e também um portal com telas de relatórios e coisas do tipo.

Faria o projeto do gateway... ele faria toda a lógica dele e seguiria a vida. E para o portal, faria outro projeto a parte. Ele seria independente, utilizaria JSF e tudo mais.

Nas últimas equipes que passei comecei a sentir certa resistência ao JSF. Escolheram fazer o portais com Angular 2. Eu achei um pouco estranho, talvez por estar acostumado com JSF, porque como eram as mesmas pessoas que iam desenvolver o back e o front, achei que era ter o trabalho de 2 feito por 1. Se fosse JSF, seria tudo mais integrado, mas com Angular senti que eram códigos totalmente a parte um do outro (back e front) e nao vi muita vantagem nisso. (entao esse é um dos pontos que queria alguma opiniao...se JSF estaria ficando ultrapassado, se faz sentido usar Angular mesmo sendo a mesma pessoa que fará front e back). Outro ponto que achei estranho é que fizeram o projeto do portal em Angular no mesmo projeto do back do gateway. O projeto era em maven, entao tinha os projetos: - model -business - repository -web todos eles ficam no mesmo war.

No web é onde tem toda a parte angular pro portal e também todos os endpoints da API rest para consumo dos serviços pros clientes (como e-commerces). meus pontos sao:

  • primeiro que acho estranho isso..de colocar o projeto do portal exatamente no mesmo projeto dos endpoints da API... estando no mesmo pacote, é mais facil manter a versao e a integraçao dos dois..pq se alguem mudar alguma API, o portal para de funcionar e aí o build pegaria isso. Por outro lado, acho estranho deixar o portal junto pq aí qualquer alteração numa tela qualquer, vai ter que compilar TUDO e subir TUDO, ou seja, o gateway todo por causa de uma tela...

-outro ponto ...se fosse JSF, ele conversaria com os ManagedBeans e pronto. (ou springMVC). Até pq sei q com angular as telas ficam mais personalizaveis e tudo mais..mas no caso sao telas simples..os componentes do JSF se encaixariam muito bem...

Sendo o angular, ele tem todo o codigo dele, usa os códigos .ts e lá se conecta ao back com as chamadas REST pra API e é isso que acho meio estranho...eu consumir via rest serviços que estão na minha própria camada. Tenho a sensaçao de estar usando uma abordagem de códigos distantes (client-server) mas estando tudo no mesmo pacote..entao me soa contraditório..

1 resposta

E agora Fernando, concordo com você hauhauhaua. Quebrar em 2 projetos realmente vem sendo muito usado no mercado, até no meu curso de react faço desse jeito :).

Existem algumas justificativas que os times podem usar:

  • times com habilidades diferentes
  • escalar cada uma das aplicações de maneira independente
  • uma camada não precisa ficar esperando a outra.. o front pode mockar a api e já foi.

Parece que no seu caso nada disso foi usado, então realmente fica meio estranho entender o motivo.

Em relação ao jsf, realmente o framework dominante do mercado é o Spring e sua stack, com o Spring MVC por exemplo. Além dessa competição pesada no lado java, ele também tem sofrido resistência em função dessas novas tecnologias de front, como angular, react e vue.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software