JSP para novos projetos

Não pareceu.

Esse é o modelo tradicional “web 2.0” que tem como objetivo oferecer uma experiência semelhante à de aplicativos desktop. Como falei, se o objetivo for criar um site tradicional não vejo problema em usar esse modelo.

Faz sentido. Então, até aqui a aplicação web já é responsável por acessar banco de dados para realizar consultas, construir as paginas, retornar o resultado com o layout específico para cada cliente ou o JSON se for uma requisição AJAX.

Bom, se for uma aplicação intranet corporativa com não mais de 5 usuários simultâneos, não vejo problema.

Você citar alguma PWA que é parecida com uma app nativa?

Faz sentido. Então, até aqui a aplicação web já é responsável por acessar banco de dados para realizar consultas, construir as paginas, retornar o resultado com o layout específico para cada cliente ou o JSON se for uma requisição AJAX.

A parte do client só é responsável por realizar as requisições no servidor, como em qualquer aplicação web. Quem realiza as consultas é o servidor e retorna os resultados em JSON, por exemplo, que é um formato minúsculo e utilizando AJAX modifico apenas os dados necessários da página, sem a necessidade de recarregar a página.
Porque não suportaria mais do que 5 usuários simultâneos?

Você citar alguma PWA que é parecida com uma app nativa?

Através do seu mobile, acesse a página pwa.rocks, assim que você entrar na página, será solicitado para adicionar o PWA no seu dispositivo. Adicionando-o, você conseguirá acessá-lo através dos apps instalados no seu dispositivo como uma app nativa, e através dele, você poderá instalar outros PWAs, como Telegram ou Aliexpress.
Esses mesmos apps você consegue acessar através do seu navegador também.

Respondendo a galera:

Eu sou mais iniciante que você, não consigo nem enxergar isso que você diz que é desvantagem. :slight_smile:

Eu entendo que é possível fazer assim e com isso ter uma experiência parecida com a de uma aplicação desktop, por isso não acho que a renderização server-side tenha alguma incapacidade em relação à client-side. Só não é muito claro para mim o que é esse “alguma coisa” que é baixado. Pode ser simplesmente dados (uma string, um json) ou então um trecho de HTML já preparado que é adicionado ou substitui um outro trecho na página renderizada. Tenho pouca experiência com front-end e não tenho essa visão. Preciso formar melhor isso na cabeça ainda.

Aproveitando o ensejo, alguém sabe quais são as tecnologias por trás do GUJ atualmente?

Vixe. PWA? Já entrou em coisa avançada pra mim. :slight_smile:

Aqui fiquei na dúvida. Um site “web 2.0”, que tenta oferecer a experiência do desktop, é tradicional ou moderno? Aqui eu entendi que é tradicional, lá em cima eu entendi que era moderno. :slight_smile:

Ok, eu exagerei vai. Talvez você consegue uns 10 a 15 usuários simultâneos, ou até mais se não usar HttpSession.

Acabei de acessar aqui no mobile… maaaaaano, essa foi uma das experiências web mais sofríveis que tive na minha vida.

Não tenho nem idéia como alguém pode comparar isso com uma app nativa para iOS.

Web 2.0 é tradicional já que é um termo popularizado em 2004. Nessa época não havia internet movel, muito menos iPhone ou Android.

Depois, com a explosão mobile e app-tizaçao de tudo, é que surgiu as soluções “modernas” (SPA, PWA) pra tentar competir com apps móveis nativas.

Mas essas soluções modernas geralmente são tão ruins que a primeira coisa que procuro quando acesso um site no smartphone é uma forma de ativar a versão clássica para desktop. Infelizmente não é sempre que ela esta disponível. :frowning:

Desculpe o meu desconhecimento. Por que só 10 a 15 usuários simultâneos? Seria por gargalo no banco ou na aplicação? Não me lembro de ter ouvido falar que a capacidade de uma aplicação web feita no Java fosse tão baixa assim.

1 curtida

Pra min faz, sentido.

Basicamente você acaba aplicando o modelo MVC.
Imagine que você tem um site de compras com milhares de acessos simultâneos.

Na primeira requisição o usuario recebe a view, que pode ser renderizada usando html, css e JS.
Ao mudar de página, receberia outra view, com html, css e JS personalizados.
Como a atualização do conteúdo é assincrona, por meio de ajax, somente o essencial é consumido, logo não seria justificativa para afetar o desempenho.

Com relação ao dispositivo, seria necessário conhecer apenas as dimensões da tela e o site deveria ser responsivo.

Então como o site é responsivo, ele, o site, não está preocupado com o dispositivo, mas sim com o tamanho da view.
Se utilizar o conceito de cluster, você acaba aliviando a carga no servidor, que ficaria responsável pela camada model e indiretamente o JS, com a camada controler.

A camada de persistência ficaria abaixo da model;

Quando se justificaria a aplicação nativa.
Quando o poder de processamento tivesse que ser maior que o oferecido por navegadores, mantendo o servidor leve.

Ex.: um jogo em android.

Para isto, tem que ter em mente a “clusterização”.

Não vejo como a escolha da forma de implementação bem feita afetar o desempenho do servidor, seja usando aplicações nativas ou não.

Se parar para observar, vai ver que a princípio tudo devia ser MVC e a escolha entre nativo ou não dependeria apenas do tipo de processo a ser realizado.

Assim, eu não gastaria dinheiro criando arco e flecha para “indios nativos” que caçam com com rifle de curto alcançe.

Cabe lembrar que o que é mal feito, é mal feito e pronto.

Crie servicos REST no backend e faca o front com Angular, Vue, React… assim o front fica desaclopado do backend, cada um com sua responsabilidade.

Você já ouviu falar de uma aplicação JSP com interface dinâmica e que suporta alta capacidade? Apenas uma pergunta retórica, não precisa responder.

Sistemas internos corporativos não precisam mais capacidade que isso, e nem interface cheia de firulas, por isso não vejo problema.

Com relação aos sistemas que precisam de mais capacidade, existe um risco em adotar uma arquitetura que concentra tanta responsabilidade em 1 único servidor, porque se não for o suficiente, você vai ter que adotar as técnicas de magia negra sugeridas pelo @addller para escalar sua aplicação web.

Além de não ver vantagem nenhuma, uma vez que não é muito mais difícil começar com o que sugeriu o @igor_ks, desaclopando cliente e server. Provavelmente mais simples no início, quando um serviço/API é suficiente e cada componente tem sua responsabilidade bem definida, servir e apresentar. Agora se depois precisar de mais capacidade, tu pode distribuir a carga sobre o servidor adicionando mais serviços, o que vai aumentar a dificuldade da sua arquitetura, é verdade. Ainda assim, nem de perto a complexidade de rodar sua app web em cluster ou em um servidor de aplicação!

O antigo guj usava jsp e aguentava melhor que essa versão moderna que usa api xP

o coderanch continua usando jForum que é feito com jsp,

e o site zeef.com é feito em (pasmem) jsf xD
http://adam-bien.com/roller/abien/entry/a_java_ee_startup_filtering

pessoal taca muito terror sem motivo, jsp aguenta de boa… o dia que não aguentar mais vc provavelmente estará ganhando o suficiente pra pagar alguém pra melhorar xP

Apesar desses sites funcionarem perfeitamente, eles tem a mesma influência na web de hoje quanto uma aplicação corporativa interna, ou seja, zero.

Hoje quem define o que é tendência na web é o google e facebook, e se eles dizem que o browser tem que suportar um modelo de interação rica pra competir com apps nativas, então é isso que nós vai fazer, se tornar JavaScriptBoy (ainda que a maioria das apps usadas no dia-a-dia, como email, banco, rede sociais, games, etc. sejam nativas, especialmente mobile).

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 …

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.

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

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é+

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

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

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.

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.

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.