Salut et bienvenue sur ce nouvel épisode de Code Garage.
Aujourd'hui, on va aborder un thème que beaucoup voient passer sur les réseaux sociaux, sur
les blogs techniques, etc.
Mais où on connaît pas forcément la chronie, mais on comprend pas toujours bien de quoi
ça s'agit.
Ce thème, c'est le SSR ou qu'on appelle aussi le server-side rendering.
Donc si on reprend une analogie, qui est la mode vestimentaire par exemple, on dit
que les modes, elles tournent.
La mode, c'est un cycle.
Ce qui était très tendance à un moment devient désuère, ringard.
Et au bout d'un certain moment, revient à la mode, on va parler de vintage, on va parler
de rétro.
Et bien là, c'est un petit peu ce qui se passe, c'est même carrément ce qui se passe
avec le server-side rendering puisque à une époque, c'était uniquement ce qu'on utilisait,
mais sans l'appeler spécifiquement comme ça.
Si on se replonge en 2010, en 2010, c'est l'arrivée de la première version d'Anglars
GS.
Et avec Anglars GS, arrive le concept, en tout cas se démocratise le concept de SPA, Single
Page Application.
Et depuis, elles ont monopolisé toute l'attention jusqu'à quasiment devenir la
norme pour démarrer un nouveau projet WED, quel qu'il soit.
Alors dans les frameworks de SPA, on va avoir du Angular, Vue, React, Svelte, etc.
etc.
Mais donc comme je le disais depuis la quelques années, la tendance, temps à s'inverser
et le SSR, ça revient sur le devant de la scène, mais sans toujours qu'on comprenne
exactement ce que ça fait.
Donc c'est ce qu'on va comprendre aujourd'hui.
Alors le principe, c'est d'abord, avant d'aborder le SSR, on va parler justement de
ces fameuses SPA, Single Page Application, pour bien comprendre ce qui différencie les
deux et pourquoi ce sont deux paradigmes vraiment différents.
Donc dans le cas d'une SPA classique, comment ça se passe en termes de communication entre
le client, le navigateur et le serveur.
Le navigateur, quand on arrive sur un nombre de mènes, il va envoyer une requête HTTP
GET, slash, parce que là on arrive sur la racine du nombre de mènes.
Donc cette requête, il va l'envoyer au serveur.
Le serveur, lui, il va retourner une page index.html qui est quasiment vide et qui contient seulement
des liens vers les ressources JavaScript et CSS de l'application web.
Le navigateur, il va récupérer les ressources qui sont indiquées dans l'index.html, il
va les charger en mémoire et exécuter tous ces scripts-là, enfin le script de JavaScript.
Et donc l'application web en tant que tel va se lancer.
Une fois qu'elle est dansée, souvent elle va faire appel à son gloutteur qui va demander
la vue en question et le code logique qui a été demandé par l'utilisateur.
Donc là, en l'occurrence, la page d'accueil de l'application.
Une fois que la vue est chargée, l'application, elle va demander au serveur, la plupart du
temps, des données à injecter dans la page en faisant des requêtes asynchronous.
Et souvent, c'est plusieurs requêtes asynchronous pour plein de choses, charger l'utilisateur,
charger des textes, du contenu, des articles, peu importe.
Et donc ça, ça va être parfois plein de requêtes HTTP.
Le serveur, lui, il va devoir faire des appels à la base de données pour préparer les données
et les renvoyer.
Ça peut être des API REST, ça peut être des API GraphQL, ça peut être plein de choses.
Si les données retournées, donc là au navigateur, contiennent des contenus multimédia,
le navigateur, il devra charger, il devra faire appel à ses ressources pour les charger,
les images, etc., etc.
Et seulement à la fin, l'utilisateur, il pourra consulter la page qu'il a demandé à l'origine
avec toutes les informations chargées dedans et affichées correctement.
Donc ça, c'est le concept de fonctionnement d'une single page application.
Maintenant, on va voir comment ça se passe dans le cas d'un site qui fonctionne en
server-side rendering.
On a la même requête initiale, le client l'envoie donc une requête HTTP.
Le serveur là, par contre, il va se charger de construire la vue.
Il va faire ses appels à la base de données directement.
Il va préparer et injecter les données dans la vue qui lui a été demandé.
Puis, il va retourner un fichier unique, un fichier HTML qui contient tout le contenu,
évidemment avec des liens comme des ressources multimédia, quand même un peu de CSS, des
images, des vidéos, etc., etc.
Mais il renvoie quand même le fichier complet avec toutes les données dedans.
Et à partir du moment où il renvoie ça, le navigateur lui va charger les ressources
externes et la page sera directement disponible pour l'utilisateur.
Si je résume dans la première méthode, c'est le navigateur, le client qui va charger de
faire toutes les demandes de données, qui va faire plein de requêtes au serveur pour
aller récupérer toutes ces données.
Et c'est l'application qui va décider ou injecter les données, afficher, etc.
En server-side rendering, le but du navigateur web, c'est uniquement de charger une page
et quelques ressources externes, mais c'est au serveur de faire tout le reste du travail.
Donc c'est quoi les avantages du server-side rendering ?
Alors d'abord, c'est des meilleures performances en SEO parce que tout le contenu textuel ou
en tout cas tout le contenu en général est disponible après le premier chargement.
Tout est dans l'index pour un HTML.
Et même si Google, Bing et d'autres moteurs de recherche, ils sont capables de parcourir
des SPA, des Single Page Application, ils n'attendent quasiment jamais le chargement
d'un contenu qui est asynchronous.
Ok ? Si vous allez chercher de manière asynchronous la liste de vos articles, il y a très forte
chance pour que vos articles ne soient jamais références.
Le temps de chargement du contenu est plus rapide, surtout sur des connexions internet
lentes ou avec de la latence, parce que l'utilisateur n'a pas besoin d'attendre que tout le code
de l'application soit chargé avant de pouvoir accéder au contenu.
Ok ? En général, il y a un premier chargement d'une SPA qui est assez lourd parce qu'il
y a pas mal de scripts, js, même si c'est un gros script, il y a pas mal de choses à
charger et à exécuter avant de pouvoir juste voir son application web.
Évidemment, le nombre de requêtes HTTP est vraiment réduit et maintenant, on peut même
développer des applications en server-side rendering avec les mêmes librairies que pour
le fond.
React, vue et Angular ont tous des frameworks SSR disponibles par-dessus.
Pour vue, on a Nux, React, Cnext, je crois et Angular, je sais plus exactement, je sais
plus non.
Donc tout ça, c'est les avantages que le server-side rendait.
Maintenant, il y a quelques inconvénients évidemment.
D'abord, il y a un temps de chargement qui est visible entre les pages.
Une SPA, quand vous chargez une nouvelle vue, normalement vous avez un loading, vous
avez quelque chose que vous avez géré, mais comme tout se fait avec des requêtes à Synchron,
c'est vous qui choisissez d'afficher ce que vous voulez pendant le chargement.
Là, en l'occurrence, une application en server-side rendering, c'est le navigateur
qui charge.
Donc, c'est une page blanche potentiellement quelques milliseconds, quelques secondes si
vraiment il y a un problème de chargement.
La charge server va être nécessairement plus importante.
Alors, elle va être importante de manière différente parce que le travail à faire de
créer la vue, d'injecter les données, etc., tout ça, c'est lui qui le fait.
Il n'a pas juste à retourner des données comme il le ferait dans le cas de requêtes
à Synchron.
Et surtout, l'environnement, déploiement du front-end est un peu plus complexe parce
qu'il nécessite plus seulement un hébergement web statique où on a notre index.html,
qui est quasiment vide et qui fait appel à des ressources JS.
Mais par exemple, dans le cas de notre JS, c'est un peu plus complexe parce qu'il
faut faire tourner du node en bac.
Alors, attention, ce dernier point, il n'est pas réellement vrai puisque du SSR, et c'est
là où je voulais en venir, du SSR, on en fait pas depuis la nuit des temps.
Mais en fait, quand on faisait du PHP, même pur, il y a 20 ans, 30 ans, et bien, c'était
du SSR.
Ok ? Qu'est-ce que c'est un simple fichier PHP qui va nous retourner du HTML ? C'est
du server-side rendering parce que c'est le PHP qui va s'exécuter, générer notre
fichier HTML au final et nous le renvoyer.
Donc ça, ce n'est pas plus compliqué à mettre en place qu'une USB.
Mais simplement, on parle rarement de server-side rendering quand on fait simplement du PHP.
Pourquoi ? Je ne sais pas parce que ça vient avec l'IPE, avec la mode, etc.
De ces nouveaux frameworks comme Nuxt, Next, etc.
Mais il faut savoir que quand vous faites du PHP classique ou même du Express qui va
tout simplement construire votre vue, c'est du server-side rendering, même si on ne le
verbalise pas souvent comme ça.
Alors, en conclusion, le server-side rendering, il apporte des solutions aux problèmes que
posent les single-page applications, notamment sur le référencement naturel d'un site.
Mais on ne peut pas vraiment dire qu'il y a de meilleures solutions entre les deux.
C'est à vous de faire le choix entre un SESR ou une SPA en fonction des besoins et
des contraintes de votre projet.
Et surtout, ce que je voudrais qu'on retienne, c'est qu'il ne faut pas se laisser influencer
par la mode du moment.
Il faut vraiment, quand vous choisissez les techno d'un projet, prendre des décisions
documentées, réfléchir, même faire appel à des personnes qui parfois s'y connaissent
plus que vous.
Mais en tout cas, voilà.
Donc là, on a typiquement deux modes qui vont faire des cycles et on aura sûrement
une fois que la hype SESR sera complètement passée, un petit retour des SPA ou d'autres
choses.
Voilà.
En tout cas, je dis un retour, mais elles sont toujours actuellement très, très à la
mode encore.
Voilà.
Donc, j'espère que cet épisode vous aura plu, vous auraient été utiles et pour ceux
qui avaient, celles et ceux qui n'avaient pas encore exactement compris ce qui était
le SESR, la meilleure image pour moi, c'est un petit fichier PHP simple qui va vous construire
votre fichier HTML.
Et ça, c'est du SESR, simplement, le verbe alice-per-comme ça.
Je vous dis à très bientôt pour un prochain épisode.
Salut !