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

JSP para novos projetos


#21

Ah sim, eles ditam os modismos, MAS não dá pra comparar uma empresa pequena qrendo fazer um projeto X com uma google… facebook xD

Se em determinado momento eles percebem que algo não tá bom atchinAngular, eles tem recursos de sobra pra jogar tudo fora e fazer outro do zero… pra uma empresa pequena/média isso já é mais difícil…

no geral, eu diria pra pessoa optar por aquilo que ela tem mais conhecimento e se sente mais confortável do que simplesmente partir pro que tá na moda…xD

mas caso queira brincar com apis e fronts moderninhos, pode-se testar o jhipster, que cria o back com java/spring e o front com Angular4… pra prototipar é bem rápido …


#22

Eu não descrevi “a esturura do(s) sevidor(es)” e nem que a view e outras camadas não poderiam ter frameworks, o que eu queria mostrar (pretérito imperfeito mesmo) era a importância da separação de responsabilidades e desacoplamento, que é pregado no MVC, mas você só enxergou isso no comentário explicito do Igor, será que foi por causa do React? lol

Mas continue montando e montando as camadas e esperando as tendências…

Como você quer tratar de escalabilidade como prioriedade máxima, inicie um projeto 100% voltado a microserviços só react não dá conta não e deixe o cliente esperar, assim, você garante a escalabilidade que tanto esmera, e esqueça de pesar:

*Correção;
*Confiabilidade;
*Eficiência;
*Integridade;
*Usabilidade;
*Manutenibilidade;
*Flexibilidade;
*Testabilidade;
*Portabilidade;
*Reusabilidade;
*Interoperabilidade;

Tipo assim, menos

Mas pra quem acredita em bruxaria, a internet ter morrido amanhã não é um problema.

Acho que deveria haver um projeto de lei exigindo que dispositivos como smartphones e afins sejam proibidos de ter navegador por que o mundo é facebook e só existem sites por que o google veio antes deles.

Pra quem tem interesse em microserviços: https://12factor.net/pt_br/

É importante telos em mente mas não o adotar como prioridade, mas como uma solução futura de escalabilidade para um cliente que não pode esperar a moda:

Obs.: é interessante não oferecer dados do java, com base em falácia.

Minha irrelevante opinião, que morrerá amanhã junto com a web:
A plataforma não deve ser o fator determinante de sucesso da aplicação, seja ela web, móvel ou uma carroça, ele é instrumento, assim como a linguagem de programação.

Fora isso, seja feliz, com ou sem bruxismo.


#23

Não existe isso em frameworks MVC que seguem a abordagem thin client. Nesses casos o model, view e controller existem inteiramente no servidor.


#24

Eu entendo MVC como um padrão de programação que não precisa de framework. (Muita pretenção :joy:)
Eu não vou conseguir transmitir a idéia então guardo pra mim e peço desculpas, pela minha forma afoita de explanar as coisas. :black_joker:

No mais, desejo sinceramente sucesso a você e demais participantes.

Bom descanso!

Té+


#25

No mais, essa historia de morte da web foi antes de me tornar um JavaScriptBoy.


#26

Não vou conseguir explicar também.
Web pra mim sempre foi algo proximo disso:

Dispositivos interligados, assim, quanto mais genérico, maior o público.

Tenho um colega que odeia java e ama uma linguagem em específico, mas isso é um erro do ponto de vista da finalidade.

Não existe uma linguagem melhor que a outra e sim a mais apropriada, eu já vi em outros fóruns os apegados ao poder computacional de uma linguagem, ou de um framework.

Tem um podcast da hipsters, onde a galera resolveu remover o jQuery, e ficar só com JS para emagrecer o site.

Ou seja, eles entenderam que não se deve ficar apegado a ferramentas, mas sim a soluções.

É isso que me move, utilizar o que é estabelecido e criar o que é necessário.

É isso que as grandes empresas de tecnologia procuram fazer, substituir o que tem por coisas melhores.

Eu não me apego a framework, mas não nego sua versatilidade, facilidade e usabilidade, tudo é ferramenta, no meu ponto de vista.

Devaneio: :joy:
A web nunca vai morrer enquanto houve um servidor do outro lado, ela assume varias formas, mas o conceito será sempre o mesmo: Uma rede de computadores interligadas, isso é a web pra mim…

Vc pode dar o nome que quiser mas no final, usa JS.

Fui


#27

A meu ver a vantagem do desacoplamento nesse caso é poder reaproveitar os serviços REST do backend em múltiplas aplicações (por exemplo, uma web app e uma aplicação mobile nativa ou híbrida), sem a necessidade de recriar esses serviços para ambas as aplicações. Se isso não for um requisito, não vejo muita vantagem em desacoplar “just for the sake of it”. Existe alguma outra vantagem?

Eu poderia ter serviços REST e manter a renderização no lado do servidor? A desvantagem que vejo é ter que chamar dois back-ends a cada requisição (o back-end da aplicação e este por sua vez chamaria o do serviço REST), isso é grave? Fora isso não vejo outros empecilhos.


#28

Então, estudando programação multithread eu já caí no problema do container ter que suportar múltiplas threads no servidor, e o gargalo disso era a memória disponível para alocar a pilha de execução de cada thread. Falava-se em milhares de threads (isso num único servidor). Já se tratava de interface dinâmica, com web 2.0. Por isso estranhei suportar só 10 ou 15.

A solução desse gargalo no caso do Tomcat se eu não estiver enganado é configurá-lo para usar NIO. Aí o gargalo, na maioria das aplicações, deve passar a ser as requisições ao banco de dados. Não posso falar muito por falta de experiência; não sei em que pé as coisas estão quando chega a necessidade de se aplicar balanceamento de carga, por exemplo.


#29

Eu não vou falar de empecilhos, vou começar do ponto de vista físico/energético.

Vamos dizer que você faça a renderização, no servidor, assim, você vai aumentar o gasto com a conta elétrica :slight_smile: certo?

Então se você gastou + energia, infima mesmo, você realizou um pouco a mais de processamento, coisa irrelevante, pra 20, 30 mil pessoas.

Pegue esse mesmo servidor e coloque 200 milhões de úsuarios, assim, o processamento ínfimo é multiplicado por um valor alto, logo, você vai pensar em uma forma de melhorar o desempenho da aplicação e começa a pensar em quais processos poderiam ser distribuídos de forma mais eficiente.

Assim, imagine que o lado do cliente, não recebe a página renderizada, ele recebe um PROTOCOLO, lê e monta a página que veioPRONTA” do servidor, como é comum em PHP.

Tem problema?
Não sei, depende da necessidade (não estou com ironia. vide: lógica difusa).

Se a necessidade é melhorar o desempenho para 200 milhões, joga o PROTOCOLO pro cliente e ele que se vire para montar a página, pois ambos conhecem o protocolo de comunicação.

Qual a consequência:
O servidor não vai gastar energia fazendo o que a view pode fazer.

Lembra da tautologia.

Se você não renderizar no servidor, o cliente faz.
Se você renderizar no servidor, no final o cliente também o faz.

Percebeu?
O cliente faz de qualquer forma.

Vamos banalizar:

    servidor.processaNegocios();//throws exception :joy:

    if(servidor.renderiza()){              
        servidor.consomeRecursos();
        servidor.protocoloTo(cliente);
        cliente.renderiza();
        cliente.consomeRecursos();
    }else{
        servidor.protocoloTo(cliente);
        cliente.renderiza();
        cliente.consomeRecurso();
    }


Do ponto de vista lógico, o ideal seria:

    servidor.processaNegocios();//throws exception :cry: 
    servidor.protocoloTo(cliente);
    cliente.renderiza();
    cliente.consomeRecursos();

Se aplicar, lógica, grafos, matemática e física qual você escolhe?
Existe impedimento do ponto de vista de linguagens/ferramentas/frameworks?
Só pra ler a primeira abordagem, VOCÊ pessoa, gastou quantos recursos, lógicos, físicos e TEMPO?
Será que o **SISTEMA -> cliente/servidor/protocolo/etc ** não gastou mais recursos que o necessário?

Computadores não fazem mágica, eles consomem recursos físicos e energéticos.

Ou seja, se eu tiver que procurar alguma fonte para melhorar o desempenho, já começo por outras coisas.
Mas, se a “arquitetura” não suporta vai o que tem:
servidor.processaNegocios() && servidor.renderiza() && servidor.protocoloTo(cliente) && cliente.renderiza().

Veja, se a comunicação acontece por meio de protocolo, ou seja, o cliente não recebe uma página pronta ele vai montar uma de qualquer forma, talvez a comodidade justifique, mas posso estar errado, sei lá.

O que eu mostrei é a finalidade “absoluta”: facadeRenderizarNoCliente() e evitar o consumo de recursos energéticos incluindo o tráfego para a mesma finalidade, que vai acontecer de qualquer forma, pois quem tem que garantir isso é o protocolo de comunicação.

Mas ai é pra quem entende, não é meu caso :smile_cat:.

Acho que essa separação entre front-end e back-end provocou a perda da visão sobre O TODO (o sistema completo), bem como de seu funcionamento.

Acho que nem o mercado sabe o que é um full-stack, nem eu. #MVC -> protocolo - persistente.