Quels avantages confèrent l'utilisation du rendu de page côté serveur?

Je développe une application web et j'ai actuellement écrit le site web entier en html / js / css et sur le backend j'ai des servlets qui hébergent certains services RESTFUL. Toute la logique de présentation se fait en obtenant des objets json et en modifiant la vue via javascript.

L'application est essentiellement un moteur de recherche, mais elle aura des comptes d'utilisateurs avec des rôles différents.

J'ai fait des recherches sur certains cadres tels que Play et Spring. Je suis relativement nouveau dans le développement Web, alors je me demandais quels avantages offrirait le rendu des pages côté serveur?

Est-ce: la vitesse? Développement et workflow plus faciles? Accès aux bibliothèques existantes? Plus? Tout ce qui précède?

Rendu HTML côté serveur:

• Rendu de navigateur le plus rapide
• La mise en cache des pages est possible comme une amélioration rapide et sale des performances
• Pour les applications "standard", de nombreuses fonctionnalités de l'interface utilisateur sont préconfigurées
• Parfois considéré comme plus stable car les composants sont généralement soumis à une validation au moment de la compilation
• S'appuie sur l'expertise backend
• Parfois plus rapide à développer *

* Lorsque les exigences de l'interface utilisateur correspondent bien au cadre.

Rendu HTML côté client:

• Utilisation de bande passante réduite
• Rendu de page initial plus lent. Peut même ne pas être perceptible dans les navigateurs de bureau modernes. Si vous devez prendre en charge IE6-7, ou de nombreux navigateurs mobiles (le webkit mobile n'est pas mauvais), vous pouvez rencontrer des goulots d'étranglement.
• Construire l'API d'abord signifie que le client peut tout aussi bien être une application propriétaire, un client léger, un autre service Web, etc.
• S'appuie sur l'expertise JS
• Parfois plus rapide à développer **

** Lorsque l'interface utilisateur est largement personnalisée, avec des interactions plus intéressantes. De plus, je trouve que le codage dans le navigateur avec du code interprété est beaucoup plus rapide que d'attendre les compilations et les redémarrages du serveur.

Vous pouvez également envisager un modèle hybride avec une implémentation légère de backend utilisant un système de modèles front-end / back-end comme la moustache .

génération HTML côté serveur:

• plus facile à déboguer;
• aucun problème avec la compatibilité du navigateur;
• avec la génération classique côté serveur pleine page, il est plus difficile de mettre en cache HTML, même s'il comporte de grandes parties invariables; (la solution consiste à récupérer des fragments HTML via des appels AJAX);
• ne pas tirer parti des procurations de mise en cache et des CDN pour le HTML dynamique;

génération HTML côté client:

• plus difficile à déboguer;
• certains problèmes avec les navigateurs obsolètes;
• aucun problème de mise en cache côté client des modèles HTML;
• tirer parti des procurations de mise en cache et des CDN pour les modèles HTML et le code JS;
• utilisation du réseau beaucoup plus faible;

Notez que la génération côté client est la façon dont cela se fait en cas de sites mobiles réussis, car apparemment, c'est beaucoup plus efficace avec les navigateurs modernes (les navigateurs basés sur WebKit ont environ 70 à 80% du marché mobile).

LinkedIn a un article sur les avantages de l'approche côté client utilisant dust.js comme exemple: "Laisser les JSP dans la poussière: déplacer LinkedIn vers les modèles côté client dust.js"

Cela dépend de vos besoins. Si vous avez besoin d'une solution hautes performances à faible latence qui dépend de nombreuses petites tâches, vous pouvez opter pour une structure similaire à ce que vous décrivez. Cependant, les solutions les plus courantes, en Java, PHP et C #, ne le font pas par défaut.

La plupart des applications Web dépendent fortement des bases de données - la plupart d'entre elles à tel point que les pages ne peuvent pas s'afficher sans au moins un appel. Évidemment, vous ne voulez pas exposer votre base de données publiquement, pour plusieurs raisons:

• Sécurité (comme le mentionne Oded ) - vous ne voulez certainement pas exposer votre réseau publiquement! Idéalement, la seule interface vers vos systèmes depuis l'extérieur devrait être https vers votre serveur.
• Facilité de développement - vous ne voulez vraiment, vraiment , vraiment pas écrire SQL en Javascript, et les langages conçus pour la présentation Web ne fonctionnent pas bien avec les RDB. Ils n'ont pas de concept d'État, par exemple.

Donc, lorsque vous avez besoin d'une base de données, vous utilisez des langages qui fonctionnent bien avec eux comme Java, C #, PHP, etc. La façon la plus simple de générer une page se présente comme suit: mais JSP et ASP sont deux autres langages très courants) pour construire la page. Le langage fournit des constructions qui appellent d'autres modules. En PHP, c'est généralement dans la page ou dans un autre fichier PHP, en utilisant le modèle MVC. Dans JSP, vous utilisez des scriptlets ou le langage d'expression JSP. Ces autres modules peuvent effectuer le gros travail de connexion à la base de données, d'exécution de la logique et de retour de valeurs à votre couche de vue. Le résultat final est une page HTML générée, rendue sur le serveur et envoyée au client.

Lorsque votre base de données se trouve sur le même réseau que votre moteur de rendu de page, vous obtenez également de meilleures performances. Le client n'a qu'à faire une seule demande et reçoit une page - vous devrez peut-être faire 10 à 15 demandes de base de données avant d'avoir toutes les informations dont l'utilisateur a besoin. Une latence de quelques millisecondes sur votre réseau serait de quelques secondes à quelques minutes si le client devait tout faire.

Lorsque les systèmes s'agrandissent, la séparation des préoccupations et des compétences de base devient cruciale. Le HTML est bon pour l'affichage. Javascript est bon pour le contenu dynamique. SQL est idéal pour interroger une base de données, et d'autres langages sont bons en logique métier. Notre travail de développeur est d'utiliser tous les outils à notre disposition pour construire un système maintenable. Facilité de développement est une grande partie d'un bon système. Dans mon esprit, c'est presque aussi important que les performances et la convivialité. Les grands systèmes évoluent avec le temps. Les mauvais systèmes ont été mal écrits dès le départ et n'ont jamais été améliorés.

Les clients mobiles sont généralement limités en termes de puissance, de bande passante et de mémoire. Il est probablement préférable de leur rendre des pages sur le serveur.

Pour les clients de bureau, vous pouvez envisager d'envoyer js + json pour rendre la page sur le client, la rendre dynamiquement actualisable, etc.

Un énorme avantage du rendu côté serveur est l'accessibilité - les applications basées sur javascript sont toujours un gros problème pour les personnes sans vue. Cela et il y a ce gars aveugle appelé "googlebot" à qui vous pourriez vouloir répondre. Il ne fait pas aussi bien le javascript.