Drupal Headless - Quoi, Quand, Comment & Où - Le Guide Ultime de Drupal Découplé

Dans un site web Drupal traditionnel, Drupal est la solution complète pour servir les utilisateurs avec des pages. Il est utilisé pour créer, stocker et afficher du contenu à l'utilisateur final. Dans une approche headless, l'ajout et le stockage se font toujours sur Drupal mais l'affichage ne se fait pas.

Définition :

Headless Drupal est une approche de construction de sites web Drupal, dans laquelle Drupal sert de référentiel de contenu backend. Le frontend est construit avec différentes technologies et communique avec Drupal via une API. 

Dans le graphique, nous pouvons voir que Drupal sert de système backend. Le frontend, que le client voit, est séparé de Drupal. C'est de là que vient le nom headless - Drupal n'a plus la couche supérieure (la tête ;), mais expose seulement les API que le frontend consomme et utilise comme sources de contenu.

Le frontend peut être construit dans divers frameworks et langages de programmation. Cependant, dans la majorité des cas, cela sera l'un des suivants :

• Javascript - dans la majorité des cas - les frontends sont principalement construits sur des frameworks comme React, Angular ou Vue, qui permettent une création rapide d'interfaces dynamiques et interactives. Si un pré-rendu des pages est requis sur le serveur (par ex. à des fins de SEO), Nextjs ou Gatsby peuvent aider.
• PHP - parfois le frontend est construit sur un framework PHP rapide comme Symfony ou Laravel. Cela est surtout fait lorsque le pré-rendu sur le serveur est requis. Un avantage supplémentaire est que, puisque Drupal est construit sur PHP et utilise Symfony, souvent la même équipe est capable de gérer le frontend.
• N'importe quel autre - un site web dans toute autre technologie qui peut communiquer avec une API peut consommer du contenu de Drupal. 

Pourquoi choisir le headless Drupal

Il y a de nombreuses raisons pour lesquelles les entreprises pourraient choisir de suivre une approche headless avec Drupal. Ci-dessous, je vais énumérer les plus courantes.

Plus de consommateurs de contenu

De nos jours, les marques communiquent avec leurs clients non seulement par le biais de leurs sites web mais via plusieurs canaux. Le CMS, par conséquent, n'est pas utilisé uniquement pour envoyer du contenu aux navigateurs web. Il envoie du contenu vers divers autres endroits. Vous pouvez lire plus sur l'évolution du paysage marketing dans un article sur les Plateformes d'Expérience Numérique.

Drupal est parfaitement positionné pour être la source de contenu pour divers consommateurs. En plus de servir du contenu pour un site web frontend, Drupal découplé peut servir du contenu via une API pour être consommé par divers autres médias, dans lesquels la marque souhaite être présente :

• applications mobiles
• IoT
• affichages sur kiosque
• etc.

Gestionnaire de microsites

Parfois, une entreprise doit créer plusieurs sites web qui sont séparés (par ex. un pour chaque marque, événement, promotion, pays), mais qui partageront beaucoup de contenu. Dans un tel cas, il peut être plus facile de créer un seul moteur de contenu (Drupal) qui livrera le contenu à tous les microsites. Les microsites peuvent être rapidement créés et fermés dès qu'un besoin se présente et le contenu peut être contenu dans un seul hub de contenu.

Besoin d'une interface utilisateur élégante

Drupal est fantastique pour la création de contenu, le stockage de données, etc., mais il est écrit en PHP, qui est un moteur de rendu côté serveur. Si le site web ou l'application en particulier nécessite une interface utilisateur très élaborée ou tout simplement interactive, elle doit probablement être construite en javascript.

Javascript nous permet de créer des interactions fantastiques qui sont faciles à utiliser pour les visiteurs et rapides. Les bibliothèques comme Angular, React ou Vue aident les développeurs à créer rapidement des applications frontend complexes. Les Applications Web Progressives - un standard publié par Google gagne aussi en popularité et nécessite qu'une application soit construite en javascript.

Si vous souhaitez construire une application web interactive, associer Drupal avec un framework frontend Javascript est vraiment une excellente option. Pour un tutoriel, vous pouvez lire notre article sur l'association de Drupal et React.

Diversification des équipes

Les experts Drupal sont très rares. Certaines entreprises, pour avancer plus rapidement, décident de construire le backend en Drupal et de déléguer le frontend à une équipe spécialisée dans une technologie différente, où le talent est plus disponible ou qui est plus simple à apprendre.

Un autre avantage d'inviter diverses équipes à travailler sur un projet est le partage des meilleures pratiques provenant de diverses sources. Cela peut aboutir à de bien meilleurs résultats que de compter sur une seule équipe pour construire le backend et le frontend.

Réduction de la dépendance technologique à une seule plateforme

Plus le système est grand sur lequel on construit sur Drupal, plus la dépendance est grande. Abstraire Drupal du service du frontend permet aux entreprises d'être plus dynamiques dans le changement des technologies du frontend, sans avoir à reconstruire ou réarchitecture des backends Drupal énormes.

De nombreux sites web, qui doivent maintenir une apparence moderne et fraîche, subissent une refonte tous les quelques années. Si le frontend est séparé du backend, il est beaucoup plus facile de le reconstruire. Dans ces cas, le coût global du site web peut s'avérer être inférieur à celui d'une reconstruction complète d'un site Drupal.

Drupal est idéal pour le headless

Drupal est très souvent choisi lorsqu'un CMS headless est requis. La raison en est que Drupal, tel quel, a la plupart des fonctionnalités requises. C'est l'un des CMS les plus matures et possède des API fantastiques.

La communauté Drupal travaille très activement pour permettre à Drupal d'être un formidable CMS piloté par API. En 2016, une initiative “Api First” a été lancée. Son objectif était de coordonner l'effort de développement pour permettre à Drupal d'être un CMS totalement headless.

À la date de rédaction de cet article, d'énormes progrès ont été réalisés pour permettre à Drupal de servir et de recevoir du contenu via des API. 

Module RESTful

Depuis Drupal 8.2, il existe un module RESTful disponible dans le noyau de Drupal qui, tout simplement, permet une interaction facile avec toutes les entités standard disponibles dans Drupal (nodes, utilisateurs, taxonomies, commentaires). Accompagné par le module REST UI, il permet un contrôle très précis de ce qui peut être accédé via l'API REST et comment.

Au départ, ce module était la norme pour construire des installations headless de Drupal. Il présente cependant quelques points de douleur, ce qui le rend parfois assez difficile à utiliser.

1. Les structures de données retournées sont par défaut dérivées des tableaux de Drupal, qui, convertis en JSON, ne sont pas très conviviaux et difficiles à naviguer pour les développeurs frontend.
2. Obtenir et filtrer des listes d'entités est un peu problématique. Pour chaque type de liste et de filtre, une vue dans Drupal avec des champs particuliers et des filtres exposés doit être créée. Les développeurs frontend ne peuvent pas facilement demander des listes personnalisées.

Malgré les inconvénients, RESTful a été un pas fantastique dans la bonne direction.

Module JSON:API

Le module JSON:API a été livré avec Drupal 8.8. Il a considérablement amélioré l'expérience REST avec Drupal, en en faisant un système incroyablement polyvalent, supérieur à pratiquement tous les CMS sur le marché.

Le module JSON:API expose toutes les entités de Drupal permettant des interactions faciles, mais il le fait de manière très élégante :

1. Il est conforme au standard JSON:API (https://jsonapi.org/) le rendant facile pour quiconque souhaitant intégrer un site Drupal de comprendre les structures de données sans avoir besoin de beaucoup de documentation personnalisée.
2. Il permet de faire des requêtes pour obtenir des listes et de filtrer par propriétés d'entité et champs également selon le standard JSON:API.

La fonctionnalité core de JSON:API est encore étendue par le module JSON:API Extras, qui permet une configuration supplémentaire des points d'accès.

Les fonctionnalités ci-dessus transforment effectivement Drupal en un backend très robuste pour les applications frontend, où toutes les structures de données peuvent être créées en utilisant l'UI de Drupal, tandis que les points d'accès REST fonctionnent automatiquement, tels quels, sans besoin de travail de programmation.

Une comparaison approfondie des deux modules peut être trouvée ici : https://www.drupal.org/docs/8/modules/jsonapi/jsonapi-vs-cores-rest-module

REST dans Drupal est profondément intégré dans le système

Ce qui mérite d'être mentionné est que dans les deux modules ci-dessus, les API REST ne sont pas ajoutées à Drupal de manière secondaire. Elles sont profondément intégrées dans le noyau de Drupal. Le contrôle d'accès de Drupal, le prétraitement des valeurs, les hooks, les événements etc. Tout cela est automatiquement pris en compte lorsque un point d'accès est interrogé, tout comme si un nœud Drupal était demandé de façon plus traditionnelle en accédant à une URL via le navigateur. 

Cela donne à Drupal un avantage énorme sur d'autres CMS. En utilisant REST, vous pouvez toujours étendre et modifier le comportement par défaut de la manière que vous souhaitez !

Headless vs progressivement découplé

Dans cet article, nous discutons de Headless Drupal, mais il est également intéressant de mentionner que ce n'est pas la seule façon d'ajouter de l'interactivité à un site web Drupal. Une autre option est de créer une architecture Drupal progressivement (ou partiellement découplée).

Le découplage progressif est une approche plus proche d'une configuration Drupal typique, où la requête initiale au serveur est gérée par Drupal et la page renvoyée est assemblée par Drupal. Sur la page, cependant, nous intégrons des éléments interactifs construits en javascript, qui récupèrent ensuite les données dont ils ont besoin en s'appelant une API REST également fournie par Drupal. 

Cette approche peut avoir du sens dans les scénarios suivants :

• La plupart du site n'est pas interactif mais il y a quelques éléments très interactifs qui nécessitent Javascript.
• Le site utilise des sources de données externes qui doivent être présentées à l'utilisateur mais qui ne proviennent pas de Drupal et ne sont pas bien adaptées à Drupal (par ex. les cotations boursières changeant au fil du temps) qui peuvent être extraites directement de la source par une application JS intégrée dans Drupal.

Si vous ne savez pas quelle solution choisir, il y a un excellent post par Dries Buytaert sur comment découpler Drupal en 2019.

Considérations importantes

Le développement est plus compliqué et plus cher

Une infrastructure headless est plus complexe qu'un site web Drupal traditionnel. Cela peut causer des difficultés supplémentaires et augmenter les coûts. En choisissant une approche headless, vous devez considérer si les avantages compensent les coûts. 

Gestion de plusieurs équipes

Dans un Drupal headless, il y a 2 composants distincts (frontend et backend) et ceux-ci doivent être développés (au moins dans une certaine mesure) en coordination. Très souvent, il y aura des développeurs ou des équipes distinctes (backend et frontend) travaillant sur le site web. Parfois ce sont 2 entreprises différentes. Cela nécéssite une coordination et beaucoup plus de communication parce que les modèles de données doivent être convenus, les points d'accès créés et testés. Il est vrai que dans Drupal, beaucoup de ces points peuvent être disponibles tels quels, mais il y aura probablement des exigences pour certains points personnalisés.

Coûts de développement globaux plus élevés

Le temps de développement global sera probablement plus long puisque nous construisons maintenant 2 systèmes, et par conséquent le coût de développement sera également plus élevé que celui d'un site Drupal standard comparable, surtout en tenant compte de l'effort de coordination.

Coûts de maintenance ultérieure plus élevés

La maintenance d'un système découplé est plus difficile. Les tests sont plus importants lorsque vous dépendez des API REST parce que les modifications d'un système peuvent le rendre incompatible avec l'autre.

Les déploiements devront peut-être être plus orchestrés lorsque des modifications à plusieurs systèmes sont déployées en même temps. Alternativement, de multiples versions d'une API pourraient être maintenues, mais cela ajoute aussi aux coûts. Tout cela peut augmenter les coûts de maintenance.

De plus, les mises à jour de sécurité seront requises plus souvent car il y aura besoin de corriger non pas un mais au moins 2 systèmes.

SEO (et autres moteurs consommateurs de métadonnées)

Google devient de plus en plus performant dans l'indexation du contenu javascript, mais il est toujours plus sûr et beaucoup plus efficace de pouvoir lui fournir tout le contenu lors de la première requête vers l'URL principale. Si votre site web dépend fortement du trafic des moteurs de recherche, une approche découplée peut ne pas être la meilleure solution.

Vous devez également prendre en compte d'autres services. Par exemple, pour que le contenu soit facilement partageable via Facebook et Twitter, chaque contenu doit avoir une URL distincte et, ce qui est également important, doit retourner les données de base accessibles sans javascript. Pour l'instant, Facebook et Twitter, lorsque vous partagez un lien, préparent l'aperçu en consultant le lien sans activer javascript. Le titre, l'image et les informations de description doivent donc être disponibles sans besoin d'activer javascript.

Solutions :

Partageabilité - retour des informations de métadonnées sur les routes

Pour Facebook et Twitter, il suffit de retourner une petite partie du contenu du site sur chaque route. Cela peut même être fait, et parfois l'est, par un simple script dans un langage côté serveur (en PHP ou python, etc.) qui, en fonction de la route demandée, retourne des métadonnées différentes. Le serveur, au lieu de servir un fichier HTML simple avec une application js, analyse un script et retourne un HTML identique juste avec les méta-tags variant.

SEO  - Rendu côté serveur

Pour des fins de SEO, l'approche ci-dessus peut également être utilisée, mais généralement, une autre méthode est plus efficace. Assembler une page complète avec du contenu nécessite souvent beaucoup de logique, qui doit ensuite également être disponible dans l'application frontend. Écrire la même logique d'assemblage de page à la fois dans un langage côté serveur puis en javascript pour le frontend n'a pas de sens.

La communauté des développeurs a créé des frameworks javascript open source basés sur React, qui permettent la création d'applications javascript qui rendent la page sur le serveur et l'enrichissent ensuite avec une UI élégante dans le frontend. Il y a deux frameworks les plus couramment utilisés :

• Nextjs - https://nextjs.org/
• Gatsbyjs  - https://www.gatsbyjs.org/

Chacun de ces frameworks offre une fonctionnalité similaire et permet de construire des sites web super rapides assemblés dans le backend et fonctionnant de manière très fluide dans le frontend. 

Du point de vue de Drupal, le développement d'un CMS headless est identique pour une application monopage typique.

Perte de certaines fonctionnalités de Drupal

Drupal, tel quel, fournit beaucoup de fonctionnalités. Si Drupal est conservé dans le backend, beaucoup de ces fonctionnalités ne sont plus disponibles. En particulier :

• Gestion des mises en page  - Drupal fournit une gestion de mise en page des pages hautement configurable avec une définition des régions et une capacité à placer des éléments dans diverses parties de la page sans avoir besoin de les coder (par ex. placer une fenêtre de recherche dans l'en-tête ou un menu dans le pied de page). 
• Écrans de gestion des comptes- Drupal fournit l'enregistrement, la connexion, la réinitialisation du mot de passe par défaut. Si nous avons l'intention de permettre aux utilisateurs de s'enregistrer, nous devrons implémenter tous les formulaires et les connecter aux API.
• Aperçu - Si nous créons du contenu dans Drupal, nous, en tant qu'auteur, pouvons le prévisualiser avant qu'il ne soit publié. Dans une configuration headless typique, surtout si le contenu est disponible via de nombreux canaux, l'aperçu de tout n'est pas disponible. Souvent, l'éditeur ajoute du contenu sans en voir le résultat final. Si nécessaire, cela doit être séparément architecturé et créé pour permettre aux éditeurs de prévisualiser leurs créations.

Résumé

Headless Drupal est une approche intéressante pour construire des sites web interactifs riches en fonctionnalités ou construire des hubs de contenu qui alimentent divers sites web et médias consommateurs de contenu. Cela dit, il n'est cependant pas sans inconvénients et une réflexion minutieuse doit être faite avant de choisir cette voie. Espérons que cet article vous a donné suffisamment d'informations pour choisir. Sinon, nous sommes toujours heureux de consulter votre projet Drupal.

Contactez-nous !