A coup de framework JS, Drupal en devient headless !

Dans son article​ d’octobre dernier, Dries Buytaert annonce officiellement que Drupal va intégrer côté backend le framework Javascript de Facebook​, plus connu sous le nom de React. A priori ce serait pour la version 8.6 qui arrive en septembre 2018 dixit la roadmap officielle —, autant dire demain !

Ce changement va dans le sens des sites dits découplés et headless, qui séparent distinctement front end et backend. Ce dernier qui a pour fonction principale le stockage des données et leur envoi côté front peut également les transmettre à d’autres plateformes ou applications, alors que le front end responsable de l’affichage des données peut lui être géré par un autre framework que Drupal. Il se charge également de solliciter le backend en effectuant toute type de demande ou request.

C’est avec le développement des frameworks Javascript comme Angular, React, Ember, et plus récemment Vue.js, que le terme headless est apparu. Aujourd’hui devenu courant  — poussé par la demande croissante des applications mobiles et applications web progressives, ou PWA pour Progressive Web App , il est encore difficile à appréhender par les personnes en charge des projets, car le choix de partir sur un site de ce type ne se fait pas sans réfléchir, et nécessite d'avoir toute sa tête (oui elle est un peu facile, mais tant pis !).

Il est en effet indispensable de cerner clairement le besoin en amont afin de savoir s’il est pertinent d’opter pour cette solution. Dans un article plus récent de Dries How to decouple Drupal in 2018, on comprend mieux l'enjeu de la chose, et les questions à se poser en amont. Tout d'abord, à qui est destiné ce site, et pour quelle(s) plateforme(s) ? Pour le Web, les mobiles, l'IoT, ou tout à la fois ?
Dans le cas d'une expérience multiplateforme, ou à destination d'une application mobile par exemple, une solution headless peut sérieusement être envisagée. On notera qu'il est possible que Drupal soit uniquement utilisé côté backend comme un dépôt ou repository.

Après avoir répondu aux premières questions, l'étape suivante est de clarifier les utilisations liées au projet. Dans le cas d'un site ou application Web, si les besoins sont uniquement éditoriaux, ce n’est même pas la peine de penser à un site découplé. Aucun intérêt, et des complications pour rien. A contrario, si des besoins pour le développement sont importants la question se pose alors.

Dans les besoins pour le développement, on peut lister de manière non exhaustive les points suivants :

  • Un besoin de contrôle poussé des données de présentation, en clair si les développeurs sont prioritaires sur les éditeurs
  • Un besoin d’utiliser du Javascript côté serveur (server side) pour le rendu de son application, avec Node.js par exemple
  • Un besoin de récupérer des données au format JSON, et pas forcément HTML

Dans le cas où les besoins sont répartis des deux côtés édition/développement, on peut partir sur une architecture dite progressively decoupled. Concrètement, on pourra par exemple n'avoir qu'une portion de la page dédiée à un framework JS côté front, et conserver le workflow et la prévisualisation du site côté backend.
Si les besoins sont uniquement orientés pour le développement, on choisira alors une architecture dite fully decoupled.

Vous remarquerez que c'est la notion de site découplé que j'utilise ici, et non headless. La subtilité étant qu'on parle de site headless lorsque le front end n'est pas forcément un site Web, mais un autre (ou plusieurs) type de plateforme comme une application mobile ou sociale. Cette différence est expliquée dans l'article What is the difference between decoupled CMS and headless CMS?.
Cet article n'évoque pas une autre notion importante que vous avez peut-être déjà croisée sur le Web, l'API-first. Un terme parlant souvent assimilé au terme headless, ce qui est logique car l'API est l'outil qui rend possible le multicanal ou mulltiplateforme.

Pour en revenir à l'annonce d'intégrer React dans Drupal, elle donne lieu à un échange sur le site drupal.org : Proposal to experiment with React for building Drupal’s administrative UIs. Dans l'introduction, on comprend mieux le but de cette "new strategic initiative", la recherche et l'amélioration de l'expérience utilisateur  UX pour User eXperience lors de l'administration et l'édition :

to test and research how our administrative and editorial UX could be improved by using a JavaScript framework.

Il est important de comprendre que l’intégration de React ne se fait que côté backend, et que Drupal fait bien attention de ne pas imposer un framework côté front end. Etant donné la guerre qui se joue entre les frameworks, il est important de laisser le choix ouvert aux développeurs !

Le fondateur de Drupal l'a bien compris et le précise dans son article cité précédemment :

Drupal should support a variety of JavaScript libraries on the user-facing front end while relying on a single shared framework as a standard across Drupal administrative interfaces.

On peut observer que la communauté JS semble se tourner de plus en plus vers le framework Vue.js, et le fait savoir :

  • De manière générale, sur le site risingstars.js.org en ce qui concerne l'année 2017 :​ ​"​Once again, Vue.js is the trendiest project of the year, with more than 40,000 stars added on GitHub during the year.​"
  • Au niveau de Drupal aussi, un certain nombres de développeurs souhaitent utiliser Vue.js plutôt que React, au point de contrer l'échange officiel indiqué précédemment par une autre proposition : Proposal to use Vue.js for building Drupal’s administrative UIs

Une nouvelle étape dans l'évolution #drupal à suivre de près !