Vue SSR et Nuxt.js

Petit retour d’expérience sur la refonte du site de Slickteam.

Mise en situation

Il y a un peu plus d’un an, on a lancé un projet de refonte de notre ancien site web. Et comme chez Slickteam on aime bien Vue.js, on s’est dit qu’on allait l’utiliser sur notre site.

Quand on fait un site en Vue.js, et en général avec n’importe quel autre framework JavaScript, il faut se poser la question de comment le site pourra être référencé. En effet, le confort de développement apporté par les frameworks JS s’accompagne d’un gros manque côté référencement : comme les pages sont construites en JS, côté client, les moteurs de recherche et réseaux sociaux ne sont pas tous capables de voir, et donc d’indexer le contenu des pages. Nous l’avons d’ailleurs expérimenté à nos dépens sur certains réseaux sociaux…

Sur ce projet de refonte, la question du référencement sur les moteurs de recherche et les réseaux sociaux s’est posée un peu (trop) tard… On a foncé un peu tête baissée dans le développement et c’est seulement après avoir pas mal avancé qu’on s’est dit que nos nouvelles pages n’allaient pas pouvoir être référencées si facilement.

Après quelques recherches, on a rapidement envisagé deux solutions pour permettre un référencement de notre site Vue.js : utiliser le module de Server-side rendering (SSR) officiel pour Vue.js, ou migrer les composants qu’on avait déjà développés vers Nuxt.js, un metaframework pour Vue.js qui prend en charge le SSR nativement.

La solution de Nuxt.js était attirante, mais semblait assez contraignante car il aurait fallu réécrire pas mal de choses dans nos composants pour les adapter aux concepts du framework. Au contraire, l’utilisation du module Vue SSR nous permettait de ne pas trop toucher à notre code existant.

Du moins, c’est ce que nous pensions…

L’utilisation de Vue SSR

De base, l’intégration de Vue SSR n’a pas l’air si compliquée. Il y a de la configuration Webpack à ajouter, des petits bouts de code à changer par-ci par-là dans les composants pour charger des contenus venant d’une API…

Sauf que mis bout à bout, tout ça a pas mal augmenté la complexité du code de notre petit site de 4 pages… On se retrouve avec pas mal de conf Webpack à gérer (et c’est jamais super fun de jouer avec Webpack), on doit gérer un petit serveur node.js qui fait office de point d’entrée au SSR…

Tout ça n’est pas insurmontable, mais c’est vite devenu bien plus complexe qu’il n’y paraissait. Mais bon, on avait commencé à le faire, alors c’était un peu difficile de changer d’avis à ce moment là…

Après un peu de développements, on a sorti une version fonctionnelle du site. Enfin, presque…

Ça marchait bien en local (“Chez moi ça marche”), mais une fois en prod, on s’est rendu compte que la solution n’était pas très stable. Le site était bien tel qu’on le souhaitait visuellement, le SSR fonctionnait, les moteurs de recherche et les réseaux sociaux pouvaient indexer nos pages mais… pour d’obscures raisons on avait des plantages aléatoires, parfois même sans que personne ne soit connecté au site. Notre serveur node crashait aléatoirement sans prévenir, parfois plusieurs fois par jour…

La solution de la bidouille (alias l’artillerie lourde)

Le serveur node tourne dans un conteneur Docker, et quand il plante, le conteneur ne redémarre pas tout seul. On a donc mis en place une solution pour contourner ce problème : un docker swarm pour monitorer le conteneur avec un healthcheck, et le redémarrer quand le site ne répond plus. Pour assurer la continuité du service, on a aussi mis deux replicas du même conteneur pour qu’il y en ait toujours au moins un qui tourne.

L’idéal aurait peut-être plutôt été d’investiguer les raisons de ces plantages intempestifs, mais en même temps un Partner Slickteam n’était pas mécontent de pouvoir expérimenter un peu du docker swarm alors… C’était sans doute plus simple.

Et ça a marché ! Le site tournait, sans plantage visible, et c’est tout ce qu’on demandait !

Et si on était parti sur du Nuxt.js dès le départ… ?

Nuxt.js

Ayant travaillé sur ce projet de SSR en Vue.js, j’étais assez intéressé pour tester Nuxt.js. On reviendra sans doute dans un autre article sur Nuxt.js, mais j’avais là un bon projet pour m’initier à cette technologie : l’adaptation de notre site à du Nuxt.js.

L’installation de Nuxt.js et la création d’un nouveau projet se fait assez facilement. On peut rapidement suivre la partie “get started” de la documentation, et on comprend assez rapidement le fonctionnement et les concepts de base de Nuxt.js.

Je me suis donc lancé dans ce projet : j’ai créé un nouveau projet Nuxt.js, et copié petit à petit tous les composants du site slickteam.fr. Et assez rapidement, tous les composants ont été migrés (il faut dire qu’il n’y en avait pas tant que ça, on parle là d’une vingtaine de composants au total).

Qu’on se rassure tout de même : tout le code qui avait été fait pour adapter le site de base vers Vue SSR n’était pas à jeter : en effet, la logique qui avait été mise en place pour faire les appels aux API côté serveur pour intégrer les données dans les pages (des articles de blog par exemple) reste à peu près la même quand on le fait dans une application Nuxt.js. Il en va de même pour la génération des meta données, où seuls des noms de variables ont dû être changés.

Le bilan

Au final, le passage a Nuxt.js n’a pas pris beaucoup de temps. J’ai fait ça durant mes Geekings Days, donc cela s’est tout de même étalé sur plusieurs mois, mais au final, j’ai dû y passer environ 3 jours.

La nouvelle version du site, en Nuxt.js a été mise en ligne, et pour le moment aucun problème n’a été repéré (2 semaines après la mise en production, à l’heure où ces lignes sont écrites).

Le temps passé à implémenter Vue SSR aurait sans doute pu être mieux employé si on avait pris la décision de passer à Nuxt.js dès le départ, mais tout n’a pas été perdu : plusieurs changements qui avaient été faits pour faire fonctionner Vue SSR auraient dû être faits plus ou moins à l’identique pour passer sur du Nuxt.js. Par contre, à mon grand soulagement, toutes les conf Webpack un peu bancales pour builder le site pour Vue SSR ont été complétement abandonnées : tout ça est géré de base par Nuxt.js.

Pour conclure, je dirais simplement que si vous voulez faire du SSR sur une application Vue.js, Nuxt.js est une solution qui pourra peut-être convenir, et qu’il ne faut probablement pas écarter sans s’y intéresser.