Et si on utilisait Drupal uniquement comme Backend ?
Le monde du développement web est de plus en plus compliqué avec des nouvelles technologies qui sortent toutes les semaines quasiment. Ceci est un billet avant tout de réflexion, qui traite des notions de frontend et de backend, de Drupal, de webservices, de méthodes de travail. Comment est-ce qu’on pourrait faire mieux ? Est-ce qu’on peut coupler la facilité de Drupal et les performances, par exemple, d’AngularJS ?
Backend et Frontend
On va commencer par une petite explication préliminaire simplifiée sur les notions de frontend et de backend.
Par backend, on entend le ou les systèmes permettant de traiter, de récupérer et de sauvegarder des informations dans une base de données. Il n’y a souvent pas d’interface prévue pour l’humain dans ce cas, mais la sortie est adaptée pour le frontend.
Par frontend, on entend le fait d’afficher ces mêmes données à un utilisateur d’un site, mais aussi de lui permettre d’intéragir avec. Il est possible d’avoir un frontend pour ajouter du contenu. C’est le frontend qui va faire l’interface entre le backend et l’utilisateur.
Backend et Frontend dans Drupal
Dans Drupal 7, on a tendance à parler de l’admin comme étant le backend : un autre thème, une autre interface, utilisée par les responsables du site pour administrer le site. Le frontend sera utile aux visiteurs du site, car c’est là qu’ils verront le thème “corporate”, les blocs de navigation, le contenu mis en forme et, par exemple, la possibilité d’ajouter des commentaires.
Techniquement, Drupal est construit d’une manière à ne pas séparer complétement le backend et le frontend. Les nuances se situent dans le thème et dans les modules. Les templates (.tpl.php) ainsi que les traditionnels fichiers CSS et JS font partie du frontend, et le backend se situerait dans le fichiers .module - avec ses inclusions - ou dans le fichier template.php dans le cas d’un thème. C’est pas très clair ? Voilà exactement où je veux en venir. Le développement frontend et le développement backend sont deux spécialisations différentes qui ne sont pas séparées complétement dans Drupal.
Ben et Lucie
Dans la suite, notre développeur frontend s’appelle Ben, et notre développeuse backend Lucie.
Ben s’occupe de l’interface, il discute avec les designers pour faire une intégration graphique propre en ordre en utilisant Sass et Less s’il en a la possibilité. Il gére les tailles de fenêtres, et fait du responsive design car il connait les viewport sizes des périphériques mobiles. Il se spécialise dans des framework javascript et connait par coeur les spécifications des navigateurs. Il discute tous les jours avec Lucie pour obtenir les données dans un format qu’il pourra utiliser. Voici un super article (EN) qui met un peu à plat ce que représente Ben fait de nos jours.
Lucie pour sa part aime les algorithmes, sait que MariaDB est un fork de MySQL, connait les avantages de PostgreSQL et est en train de se dire que CouchDB, c’est vachement bien en fait. Elle a étudié le Java et le PHP mais découvre le Javascript coté serveur. Elle utilise des systèmes d’abstraction pour faire des requêtes vers des bases de données, mais en fait pour certaines choses bien précises c’est peut-être mieux de faire sans. Elle déteste le CSS et dit que c’est un truc pour artiste, parce qu’elle, son résultat, elle aime le fournir en JSON dans un service REST (ça sera expliqué par la suite).
La problématique Drupal
Un développeur Drupal est quelqu’un qu’on pourrait qualifier, dans un certain sens, de développeur Full Stack. C’est à dire qu’il fait à la fois du backend et du frontend. Les développeurs Full Stack ne sont parfois pas très bien vus dans la communauté des développeurs car selon certains, ils connaissent trop de choses pour être efficaces dans un domaine bien précis. Mais bon, ceci n’est point le débat. Il est certes possible de faire travailler Ben et Lucie dans le même projet: Ben code ses templates et dans le même dossier, Lucie va programmer la logique dans les fichiers .modules et .inc. C’est théoriquement possible, mais pas du tout efficace, le code de l’un est trop dépendant du code de l’autre, et les deux doivent connaitre Drupal.
Les webservices
Cette dépendance entre le backend et le frontend est bien connue dans le développement web et n’est pas uniquement problématique avec Drupal. Dès qu’on veut construire quelque chose de bien spécifique et de professionnel, il faut commencer à séparer et à organiser son code, et à développer des méthodologies de travail.
La problématique été résolue en partie notamment avec l’apparition des webservices. Il s’agit de méthodes permettant de faire transiter des données d’un système à un autre, d’un serveur à un autre. Le service REST, à la mode aujourd’hui, permet de créer, d’accéder, de modifier et de supprimer des ressources via des requêtes HTTP. Bien souvent, c’est le format JSON (Javascript Object Notation) qui sera utilisé pour transmettre les données afin de simplifier la vie de Ben, qui connait bien le Javascript et pourra utiliser ses données telles quelles sans les modifier.
L’accès au service REST se fera par une URL et un verbe parmi les suivants : POST (ajouter), GET (obtenir), PUT (modifier), DELETE (supprimer). Ils correspondant à l’acronyme
On aura donc Ben et Lucie, en communication sur leurs besoins respectifs bien sûr, mais travaillant de manière autonome sur leurs propres projets. Ils sont indépendants technologiquement, et ça, c’est vraiment trop bien.
Et avec Drupal ?
Comment rendre indépendants Ben et Lucie sur un projet Drupal ? La solution que j’avance ici serait d’utiliser Drupal comme backend uniquement pour l’authentification, la gestion de contenu (types de contenu, taxonomie, etc.), l’administration en général, et d’utiliser… Drupal Services : https://www.drupal.org/project/services. Ce qui est trop beau, c’est que c’est déjà inclus dans Drupal 8 !
Ben sera donc libre d’utiliser le framework de son choix, de créer un frontend digne de ce nom pour ses utilisateurs, complétement indépendant de Drupal. Les administrateurs et les éditeurs de contenu auraient toujours une interface Drupal, parce que bon, c’est tout de même un des points forts de cet outil à mon avis : la gestion du contenu. Lucie n’aura pas à faire de templating ni de CSS, car l’administration de Drupal est déjà faite. Elle n’aura à priori qu’à coder ses modules en toute tranquilité et à exposer le contenu au service REST.
Aller encore plus loin
Les grandes questions qui se posent maintenant sont de savoir si c’est pertinent, si ça a déjà été fait pour des gros projets, ou si le module Services de Drupal n’est fait que pour être utilisé accessoirement à des fins complémentaires.
Cette approche permet une séparation des rôles tout en gardant Drupal comme outil de gestion de contenu. On gagne du temps avec Drupal sur certains types de projet, c’est un fait, malheureusement il n’est pas toujours aisé d’avoir un site très performant car Drupal, dans sont ensemble et avec tous ses modules (backend et frontend mélangés), n’est pas léger. Le concept de ne garder que le meilleur de Drupal et d’utiliser d’autres outils comme Backbone.js ou AngularJS comme frontend permet non seulement d’avoir une interface utilisateur moderne mais également indépendante des compétences Drupal du développeur, et de ce fait, le code est également beaucoup plus maintenable et transposable dans le cas où on déciderait de changer de backend pour une quelconque raison.
Pour certains projets, on pourrait même aller plus loin : Non content des performances de traitement de Drupal, un développeur PHP pourrait greffer un framework de son choix (Laravel, Symfony?) sur la base de données crée par Drupal et créer un service REST lui-même.
Les administrateurs du site entrent du contenu dans Drupal, auraient accès à du site building standard, avec la gestion des types de contenu, de la taxonomie, des utilisateurs. Une fois le contenu dans une base de données, un framework complétement différent (même pas forcément en PHP) prend le relais et expose cette dernière dans un service REST créé sur mesure en fonction des besoins du frontend.
Une complication que je pourrais voir de prime abord est la gestion des ACL, mais rien n’est impossible… La discussion est ouverte.
