Drupal
26/05/2021

Retour d'expérience - Méthode et réflexions pour choisir entre un découplage total ou progressif avec Drupal

Image illustrant les bureaux de bluedrop.fr à Marseille
Plus que le choix du framework javascript que vous allez utiliser, la grande question, pour les équipes projets, est de choisir la meilleure solution entre le découplage total ou progressif. Chaque solution dispose bien entendu d'avantages et d'inconvénients...

Le projet - La conception et le développement d'une plateforme de e-learning

Le projet sera mis en production début juin 2021. Il s'agit d'un site d'apprentissage destiné aux étudiants de médecine. Il prépare les étudiants au concours et examens, à travers plusieurs parcours de formation et de contrôle des connaissances. L'essentiel des parcours et fonctionnalités sont par conséquent accessibles aux utilisateurs connectés, souvent en mobilité et se présentent sous la forme d'interface de travail (QCM, questionnaires, contrôle des connaissances, corrections, interactions avec les enseignants.) La pile technique, qui s'appuie sur Drupal, doit cependant garantir flexibilité, performance et adaptabilité au niveau des interfaces. Nous nous sommes naturellement tournés vers un développement frontend avec React. Toute la question était de mesurer, avec les administrateurs et contributeurs du site, le positionnement du "curseur" de ce découplage... Jusqu'où aller dans le découplage étant entendu que les fonctionnalités et évolutions risquent d'être nombreuses et impactantes. Nous partageons ici l'essentiel de notre cheminement collectif.

L'étude du découplage progressif ou partiel

Le découplage progressif permet de conserver et profiter de la qualité du CMS Drupal pour générer certaines pages ou contenus. Il convient à ce stade de faire le recensement de l'intégralité des pages / types de contenu pour définir ceux qui seront générés par Drupal et les autres, générés en javascript (avec React dans notre exemple). 

L'avantage principal du découplage partiel est par conséquent de conserver le bénéfice des points forts de Drupal, notamment en ce qui concerne : 

  • La gestions des erreurs ;
  • La gestion des utilisateurs ;
  • La sécurité ;
  • Les optimisations pour le SEO ;
  • Le respect des contraintes d'accessibilité ;
  • Le in-place editor ;
  • etc. 

Ainsi, le rendu de vos interfaces sera généré par des méthodes mixtes et vous permettra de profiter de la puissance du CMS Drupal et des avantages du service ReactJS pour certaines pages. Toute la difficulté est alors d'aboutir à la liste idéale des pages consommées par React. Nous allons voir, ci-dessous, que cette architecture peut être mise en place de 2 façons...

1ère solution de découplage partiel

Le site Drupal est utilisé à la fois pour le backend et frontend.
L'utilisation du backoffice Drupal sera priorisée pour administrer les comptes des utilisateurs, leurs permissions, les pages, les contenus et les données.
L'utilisation de Twig pour les pages 100% Drupal et de Twig/React pour les pages "métier" ou fonctionnellement importantes, nécessitant interactivité et performance.
La gestion des URL's demeure l'affaire du CMS Drupal.

Drupal génère :

  • L'espace d'administration (backend) ;
  • Les pages 100% Drupal (avec le moteur de templates Twig) ;
  • Les pages comprenant seulement certains blocs React ; 
  • Les pages Drupal vides composées de blocs et d’éléments faisant appels à React pour la construction (100% React sur une page générée par Drupal).

2ème solution de découplage partiel

Le site Drupal est utilisé à la fois pour le backend et frontend, comme dans la 1ère solution.
L'utilisation du Backoffice Drupal est priorisée pour administrer les comptes des utilisateurs, leurs permissions, les pages, les contenus et données.
L'utilisation de Twig pour les pages 100% Drupal.
L'utilisation de JSX pour les pages 100% React.
La gestion des URLs est administrée dans React.
Un flux JSON assure l'échange de données entre le backend Drupal et React.

  • Drupal génère :
    • Le backend ;
    • Les pages 100% Drupal / Twig.
  • React génère :
    • La gestion des URLs ;
    • Les pages 100% React / JSX.

La possibililité du découplage total

Le découplage total permet de rendre indépendant toute la partie frontend de Drupal et de n'utiliser le CMS uniquement pour la gestion des utilisateurs, des modules et du contenu. L'utilisation total de React pour les interfaces participe à une meilleure performance d'affichage, une plus grande fluidité de lecture. React permet également de générer une progressive web app (PWA)

Les avantages du découplage total :

  • Il permet la stricte séparation des données de leur présentation ;
  • Il permet de paralléliser les développements : les développeurs frontend se concentrent uniquement sur le rendu des interfaces. Les développeurs backend fourniront une application RESTful API ;
  • Il permet la diffusion du contenu sur plusieurs plateformes différentes (web, mobile, objets connectés) ;
  • Il assure une expérience utilisateur enrichie : le contenu est adapté au terminal et à la cible utilisés.

Les inconvénients du découplage total :

  • Il est impossible de manipuler des configurations de l'interface par l'intermédiaire du backoffice Drupal (ex - l'ordre des tris d'une vue) ;
  • Il est impossible de prévisualiser le contenu avant la publication dans l'espace d'administration de Drupal ;
  • Il est impossible de disposer du système de notification des erreurs et des warnings sur l'interface ;
  • Cette architecture ne supporte pas le système de cache avancé proposé par Drupal.

Pour résumer :

  • Drupal n'est utilisé que pour le backend ;
  • Gestion des URLs est traitée par React ;
  • Utilisation de JSX pour les pages 100% React ;
  • Le contenu est alimenté par un flux JSON.

La possibilité d'adresser une PWA

Les PWA se chargent comme des pages web ou des sites web ordinaires, mais peuvent offrir à l'utilisateur des fonctionnalités d'interaction avec les terminaux mobiles (l'affichage des contenus hors ligne, les notifications, l'interaction à l'appareil photo ou à la géolocalisation de l'appareil). L'utilisateur pourra disposer d'un raccourci sur son écran et lancer l'applicatif sans passer par le navigateur web.

Intérêt de la PWA :

  • Le site devient installable sur les appareils mobiles. Cette invitation d'installation est déclenchée lorsqu'un visiteur accède au site classique ;
  • Il est possible d'utiliser des Service Workers pour la mise en cache et l'utilisation du site web hors ligne ;
  • L'utilisateur est libre de s'abonner aux notifications ; 
  • Les notifications peuvent être adressées aux utilisateurs abonnés lors du déclenchement de tâches spécifiques ;
  • L'administrateur du site peut envoyer des notifications génériques à tous les utilisateurs abonnés ;
  • L'administrateur du site peut voir les utilisateurs abonnés (identifiant de l'utilisateur et point final de l’abonnement).

Les tests réalisés

Pour statuer sur l'architecture adéquate, et après avoir présenté les différentes solutions au comité de projet (avec la liste et les implications des pages consommables par React), nous avons testé toutes ces architectures. Nous avons choisi un découplage partiel avec un thème twig enrichi d'applications react pour toute la partie consacrée au compte des utilisateurs (messagerie, cours, historique, statistiques, boutique, cours en direct). La partie anonyme est elle administrée à 100% par Drupal.

Nous avons par conséquent tranché pour un découplage partiel tel que décrit dans la solution n°1 du présent article.
Le résultat est consultable dans quelques jours...