Jamstack, retour sur expérience

Auteur(s) de l'article

Chez Antistatique, cela plus d’une année que nous avons pris le virage Jamstack, soit des projets découplés et orientés vers des sites interactifs basés sur JavaScript.
Maintenant nous sommes en été 2020, les choses ont bien muri et il est temps d’en dresser un bilan afin de tirer des leçons de nos expériences.

CMS ?

Rares sont les projets découplés où le client, interface avec laquelle l’utilisateur interagit, se suffit à lui-même. Il faudra avoir généralement recours à une application backend, souvent un CMS, afin de gérer et exposer des données au client.
Maintenant, tous les CMS ne sont pas adaptés au développement de projets découplés. Chez Antistatique, nous avons utilisé différents CMS tels que Wordpress et Drupal et voici nos conclusions préliminaires dans ce contexte.
Wordpress est un CMS bien connu du grand public qui offre, out-of-the-box tous les outils nécessaires à la mise en place de site découplé grâce à sa REST API. C’est néanmoins avec le module WPGraphQL qu’il brille vraiment. Ce plug-in permet d’exposer une API GraphQL et rend donc la consommation des données hyperoptimisée et sur-mesure. Même avec l’utilisation de Gutenberg, le nouvel éditeur rédactionnel de Wordpress, WPGraphQL peut nous retourner un objet de données brutes et bien formatées, moyennement un plug-in annexe.
Drupal c’est une autre histoire. Là aussi, le CMS est tout à fait adapté au découplage, notamment grâce à son module JSON:API basé sur la spécification du même nom. Maintenant si cette spécification ne vous effraie pas, l’implémentation Drupal présente quelques limitations comme l’impossibilité de connaitre le nombre total de nodes d’un même type, lacunaire pour mettre en place une pagination. Pour tout ce qui sort du cadre de la consommation de nodes prévue par le module, des endpoints REST sur mesure devront être développés afin d’offrir de nouvelles fonctionnalités à votre client.
Pour conclure ce point , Wordpress permet une mise en place rapide et propre autour de la consommation de contenu, quant à Drupal, il s’adresse à un public de développeurs seniors maitrisant l’outil pour mettre en place une solution CMS sur mesure. Maintenant, les solutions de gestion de contenu sont légion pour le découplé; que ce soit des Saas propriétaires (Prismic, Contentful, Sanity, etc) ou des solutions backend (Twill + Laravel, Strapi + Node, etc) . Il vous suffit de faire le meilleur choix en fonction des besoins de votre projet.

Avantages

Les avantages sont tous très évidents: grande liberté dans l’intégration et la création des vues, grandes possibilités en termes d’animation, possibilités d’interaction plus étendues qu’avec une approche de rendu serveur, etc. Ces avantages sont intimement liés à la technologie choisie; ci-dessus, Next.js et React.
Maintenant, pour réellement tirer des bénéfices de ces avantages, c’est en amont, durant la phase de design, que les choses se passent. En effet, ce nouveau paradigme de l’application/site et non plus de la page doit nous forcer à aller plus loin. Nous pouvons aller plus loin dans les mécaniques de navigation et d’interaction et nous ne sommes plus limités au pattern “j’arrive sur une page, je fais quelque chose, je vais sur une autre page, etc”, mais bien “j’arrive sur ce site et…”. Grâce à cette approche de développement de sites entièrement en JavaScript, bon nombre de contraintes ont été supprimées.

Inconvénients

Premièrement la taille des équipes et l’autonomie des développeurs peuvent être un inconvénient. Avec deux pôles assez différents, un projet découplé va demander des compétences backend (CMS, Drupal, Symfony, etc) d’un côté et JavaScript de l’autre. Il est plus compliqué dans ces conditions pour un développeur d’être autonome et seul sur ce genre de projet. Maintenant, cet inconvénient peut aussi être un avantage dans le sens où chacun étant spécialiste dans son domaine, la qualité du projet s’en trouvera grandement améliorée.
Ensuite, cette approche pardonne moins. En effet, quand on va utiliser un outil “clé en main” comme Wordpress, tout le traitement des erreurs est déjà existant. Avec du découplé et vu que votre client est fait sur mesure, vous allez devoir mettre place toute une gestion des différents cas de figure et, en particulier, des erreurs sans quoi votre site va potentiellement crasher souvent. Ça semble n’être rien, sachant qu’on est tous des rockstars de React, de Vue.js ou que sais-je, mais confronté au “vrai” contenu et les problèmes apparaissent rapidement.

Convaincu ?

Pour notre part oui ! La DX (developer experience) est dingue, les libertés créatrices sont proches du Flash à l’époque (oui oui, Flash était cool) et outils (librairies, hébergement, etc) sont incroyables. On baigne vraiment dans ce qu’il se fait de mieux en technologies web en 2020. Après ça demande de changer pas mal de choses dans nos façons concevoir et d’approcher un projet, mais au final, ce n’est que des bénéfices pour la team et le client. Un site mieux fait, c’est un site qui vivra mieux avec son temps.
Pour finir, aussi tentant que ce soit, comme pour toutes approches technologiques, il faut évaluer la pertinence de cette approche dans le cadre de votre projet et ne pas partir avec du découplé par défaut. Il s’agit toujours, au finale, d’une pesée entre la meilleure technologie dans l’intérêt du projet et les compétences disponibles.