Quali sono i vantaggi offerti dal rendering della pagina sul lato server?

Sto sviluppando un'app Web e attualmente ho scritto l'intero sito Web in html / js / css e sul backend ho servlet che ospitano alcuni servizi RESTFUL. Tutta la logica di presentazione viene eseguita ottenendo oggetti json e modificando la vista tramite javascript.

L'applicazione è essenzialmente un motore di ricerca, ma avrà account utente con ruoli diversi.

Ho fatto ricerche su alcuni framework come Play e Spring. Sono abbastanza nuovo nello sviluppo web, quindi mi chiedevo quali vantaggi avrebbe offerto l'utilizzo del rendering della pagina laterale del server?

È: velocità? Sviluppo e flusso di lavoro più semplici? Accesso alle librerie esistenti? Di Più? Tutti i precedenti?

Rendering HTML lato server:

• Rendering del browser più veloce
• La memorizzazione nella cache della pagina è possibile come un aumento delle prestazioni rapido e sporco
• Per le app "standard", molte funzionalità dell'interfaccia utente sono predefinite
• A volte considerato più stabile perché i componenti sono generalmente soggetti alla validazione in fase di compilazione
• Si basa su competenze di backend
• A volte più veloce da sviluppare *

* Quando i requisiti dell'interfaccia utente si adattano bene al framework.

Rendering HTML lato client:

• Minore utilizzo della larghezza di banda
• Rendering della pagina iniziale più lento. Potrebbe non essere nemmeno evidente nei moderni browser desktop. Se devi supportare IE6-7 o molti browser mobili (il webkit mobile non è male) potresti riscontrare colli di bottiglia.
• Costruire API in primo luogo significa che il client può essere altrettanto facilmente un'app proprietaria, un thin client, un altro servizio web, ecc.
• Si basa sull'esperienza di JS
• A volte più veloce da sviluppare **

** Quando l'interfaccia utente è in gran parte personalizzata, con interazioni più interessanti. Inoltre, trovo la codifica nel browser con un codice interpretato notevolmente più veloce dell'attesa di compilazioni e riavvii del server.

Potresti anche prendere in considerazione un modello ibrido con un'implementazione di back-end leggero che utilizza un sistema di modelli front-end / back-end come i baffi .

generazione HTML lato server:

• più facile da eseguire il debug;
• nessun problema con la compatibilità del browser;
• con la classica generazione lato server a pagina intera è più difficile memorizzare nella cache HTML, anche se ha parti invariabili di grandi dimensioni; (la soluzione è recuperare frammenti HTML tramite chiamate AJAX);
• non sfruttare i proxy di cache e i CDN per HTML dinamico;

generazione HTML lato client:

• più difficile da eseguire il debug;
• alcuni problemi con i browser obsoleti;
• nessun problema nella memorizzazione nella cache dei template HTML lato client;
• sfruttando i proxy di cache e i CDN per template HTML e codice JS;
• utilizzo della rete molto più basso;

Si noti che la generazione lato client è il modo in cui viene eseguita in caso di siti mobili di successo, poiché apparentemente è molto più efficiente con i browser moderni (i browser basati su WebKit hanno circa il 70-80% del mercato mobile).

LinkedIn presenta un articolo sui vantaggi dell'approccio lato client che utilizza dust.js come esempio: "Lasciando JSP nella polvere: spostare LinkedIn in modelli lato client dust.js"

Dipende dalle tue esigenze. Se hai bisogno di una soluzione ad alte prestazioni e bassa latenza che dipende da molte piccole attività, puoi scegliere una struttura simile a quella che descrivi. Tuttavia, le soluzioni più comuni in Java, PHP e C # non sono predefinite.

La maggior parte delle applicazioni Web dipendono fortemente dai database, molti dei quali così tanto che le pagine non possono essere visualizzate senza almeno una chiamata. Ovviamente non vuoi esporre pubblicamente il tuo database, per diversi motivi:

• Sicurezza (come menziona Oded ) - sicuramente non vuoi esporre pubblicamente la tua rete! Idealmente l'unica interfaccia per i tuoi sistemi dall'esterno dovrebbe essere https per il tuo server.
• Facilità di sviluppo: davvero, davvero , davvero non vuoi scrivere SQL in Javascript e i linguaggi progettati per la presentazione web non funzionano bene con gli RDB. Non hanno il concetto di stato, per esempio.

Quindi, quando hai bisogno di un database, usi linguaggi che funzionano bene con loro come Java, C #, PHP, ecc. Il modo più semplice per generare una pagina risulta essere il seguente: usi un linguaggio di template (il più famoso di PHP, ma JSP e ASP sono altri due linguaggi molto comuni) per costruire la pagina. Il linguaggio fornisce costrutti che invocano altri moduli. In PHP questo è comunemente nella pagina o in un altro file PHP, usando il modello MVC. In JSP si utilizzano scriptlet o JSP Expression Language. Questi altri moduli possono svolgere il pesante lavoro di connessione al DB, esecuzione della logica e restituzione di valori al layer della vista. Il risultato finale è una pagina HTML generata, renderizzata sul server e inviata al client.

Quando il database si trova sulla stessa rete del renderer di pagina, si ottengono anche prestazioni migliori. Il client deve solo fare una richiesta e riceve una pagina - potrebbe essere necessario fare 10-15 richieste DB prima di avere tutte le informazioni di cui l'utente ha bisogno. Una latenza di millisecondi sulla rete sarebbe da pochi secondi a minuti se il client dovesse eseguirli tutti.

Quando i sistemi crescono, la separazione delle preoccupazioni e delle competenze chiave diventa cruciale. HTML è buono per la visualizzazione. Javascript è buono per i contenuti dinamici. SQL è ottimo per interrogare un database e altre lingue sono brave nella logica aziendale. Il nostro compito come sviluppatori è quello di utilizzare tutti gli strumenti a nostra disposizione per costruire un sistema gestibile. La facilità di sviluppo è una parte enorme di un buon sistema. Nella mia mente, è quasi importante quanto le prestazioni e l'usabilità. I grandi sistemi si evolvono nel tempo. I sistemi poveri sono stati scritti male dall'inizio e non sono mai stati migliorati.

I client mobili sono in genere vincoli di potenza, larghezza di banda e memoria. Probabilmente è meglio renderizzare le pagine per loro sul server.

Per i client desktop potresti prendere in considerazione l'invio di js + json per rendere la pagina sul client, renderla aggiornabile dinamicamente, ecc.

Un enorme vantaggio del rendering sul lato server è l'accessibilità: le app basate su JavaScript sono ancora un grosso problema per le persone senza vista. Quello e c'è questo cieco chiamato "googlebot" che potresti voler soddisfare. Non fa neanche javascript così bene.