Quais são as vantagens conferidas usando a renderização de página do lado do servidor?

Estou desenvolvendo um aplicativo Web e atualmente escrevi o site inteiro em html / js / css e no back-end tenho servlets que hospedam alguns serviços RESTFUL. Toda a lógica de apresentação é feita através da obtenção de objetos json e da modificação da visualização através de javascript.

O aplicativo é essencialmente um mecanismo de pesquisa, mas terá contas de usuário com funções diferentes.

Eu tenho pesquisado algumas estruturas, como Play e Spring. Eu sou bastante novo no desenvolvimento web, então eu queria saber quais vantagens o uso da renderização de página no servidor forneceria?

É: Velocidade? Desenvolvimento e fluxo de trabalho mais fáceis? Acesso a bibliotecas existentes? Mais? Tudo acima?

Renderização HTML do lado do servidor:

• Renderização mais rápida do navegador
• O cache de páginas é possível como um aumento de desempenho rápido e sujo
• Para aplicativos "padrão", muitos recursos da interface do usuário são pré-criados
• Às vezes, é considerado mais estável porque os componentes geralmente estão sujeitos à validação em tempo de compilação
• Recorre à experiência de back-end
• Às vezes, mais rápido de desenvolver *

* Quando os requisitos da interface do usuário se ajustam bem à estrutura.

Renderização HTML do lado do cliente:

• Menor uso de largura de banda
• Página inicial mais lenta renderizada. Pode até não ser perceptível nos navegadores de desktop modernos. Se você precisar oferecer suporte ao IE6-7, ou muitos navegadores móveis (o kit da web móvel não é ruim), poderá encontrar gargalos.
• Criar a API primeiro significa que o cliente pode facilmente ser um aplicativo proprietário, thin client, outro serviço da web etc.
• Baseia-se na experiência em JS
• Às vezes, mais rápido para se desenvolver **

** Quando a interface do usuário é amplamente personalizada, com interações mais interessantes. Além disso, acho que a codificação no navegador com código interpretado notavelmente mais rápida do que aguardar compilações e reinicializações do servidor.

Você também pode considerar um modelo híbrido com uma implementação de back-end leve usando um sistema de modelagem de front-end / back-end, como bigode .

geração de HTML no servidor:

• mais fácil de depurar;
• sem problemas com a compatibilidade do navegador;
• com a geração clássica de páginas inteiras no servidor, é mais difícil armazenar em cache o HTML, mesmo que ele possua grandes partes invariáveis; (a solução é buscar fragmentos HTML através de chamadas AJAX);
• não aproveitar os proxies de cache e CDNs para HTML dinâmico;

geração de HTML do lado do cliente:

• mais difícil de depurar;
• alguns problemas com navegadores obsoletos;
• sem problemas para armazenar em cache modelos HTML no lado do cliente;
• aproveitando os proxies de cache e CDNs para modelos HTML e código JS;
• uso de rede muito menor;

Observe que a geração do lado do cliente é a maneira como é feita no caso de sites móveis bem-sucedidos, pois aparentemente é muito mais eficiente com os navegadores modernos (os navegadores baseados no WebKit têm cerca de 70 a 80% do mercado móvel).

O LinkedIn tem um artigo sobre as vantagens da abordagem do lado do cliente usando dust.js como exemplo: "Deixando JSPs no pó: movendo o LinkedIn para os modelos do lado do cliente dust.js"

Depende de quais são seus requisitos. Se você precisar de uma solução de alto desempenho e baixa latência que dependa de muitas tarefas pequenas, poderá optar por uma estrutura semelhante à descrita. As soluções mais comuns, em Java, PHP e C #, não são padronizadas para isso.

A maioria dos aplicativos da Web depende muito dos bancos de dados - a maioria deles tanto que as páginas não foram processadas sem pelo menos uma chamada. Obviamente, você não deseja expor seu banco de dados publicamente, por vários motivos:

• Segurança (como Oded menciona) - você definitivamente não deseja expor sua rede publicamente! Idealmente, a única interface externa para os seus sistemas deve ser https para o servidor.
• Facilidade de desenvolvimento - você realmente, realmente , realmente não quero SQL escrita em Javascript, e as línguas projetados para apresentação web não funcionam bem com RDB. Eles não têm conceito de estado, por exemplo.

Portanto, quando você precisa de um banco de dados, usa linguagens que se adaptam bem a eles, como Java, C #, PHP etc. A maneira mais fácil de gerar uma página é a seguinte: Você usa uma linguagem de modelagem (mais conhecida como PHP, JSP e ASP são duas outras linguagens muito comuns) para construir a página. A linguagem fornece construções que chamam outros módulos. No PHP, isso geralmente ocorre na página ou em outro arquivo PHP, usando o padrão MVC. No JSP, você usa scriptlets ou o JSP Expression Language. Esses outros módulos podem ter o trabalho pesado de se conectar ao banco de dados, executando a lógica e retornando valores à sua camada de visualização. O resultado final é uma página HTML gerada, renderizada no servidor e enviada ao cliente.

Quando seu banco de dados está na mesma rede que o renderizador de página, você obtém melhor desempenho também. O cliente precisa apenas fazer uma solicitação e receber uma página - pode ser necessário fazer 10 a 15 solicitações de banco de dados antes de ter todas as informações de que o usuário precisa. Uma latência de milissegundos na sua rede seria de segundos a minutos se o cliente tivesse que fazer todos eles.

Quando os sistemas crescem, a separação de preocupações e competências essenciais se torna crucial. HTML é bom para exibição. Javascript é bom para conteúdo dinâmico. O SQL é ótimo para consultar um banco de dados, e outros idiomas são bons na lógica de negócios. Nosso trabalho como desenvolvedores é usar todas as ferramentas disponíveis para criar um sistema sustentável. A facilidade de desenvolvimento é uma grande parte de um bom sistema. Na minha opinião, é quase tão importante quanto desempenho e usabilidade. Grandes sistemas evoluem com o tempo. Sistemas ruins foram mal escritos desde o início e nunca foram aprimorados.

Os clientes móveis geralmente têm restrição de energia, largura de banda e memória. Provavelmente é melhor renderizar páginas para eles no servidor.

Para clientes de desktop, você pode enviar js + json para renderizar a página no cliente, atualizá-la dinamicamente etc.

Uma enorme vantagem da renderização do lado do servidor é a acessibilidade - aplicativos baseados em javascript ainda são um grande problema para pessoas sem visão. Isso e existe esse cara cego chamado "googlebot" que você pode querer atender. Ele não faz javascript tão bem também.