Le découplage progressif avec Drupal 8... Le site de la RTM.

Wednesday 8 April 2020

Discutons d'un exemple de découplage progressif avec Drupal 8 à l'occasion de la mise en production du site de la RTM en janvier 2020... Le retour d'expérience de Ludovic, qui connait tous les détails du projet :)

Le découplage progressif avec Drupal 8, VueJS et PhalconPhp

Nouveautés du site

Drupal 8

C'est une évidence aujourd'hui et il était temps ! La précédente version du site avait été réalisée avec le vénérable et aujourd'hui tout à fait obsolète Drupal 6.X.

Cela faisait déjà plus de deux ans que nous avions des sueurs froides à chaque annonce de la Drupal Security Team, mais c'est fait le nouveau site de la RTM est propulsé par Drupal 8.8. Il sera donc tout à fait éligible à la montée en version simplifiée vers Drupal 9.X.

Les avancées de Drupal 8 seront surtout manifestes pour les administrateurs du site et nous vous invitons à (re)lire notre série sur les nouveautés apportée par la version actuelle du CMS Drupal.

Nous allons pouvoir arrêter de tancer l'équipe projet et la RTM sur le fait de mettre à jour le site et commencer sereinement notre service de maintenance préventive.

Responsive et unifié

Encore un enfonçage en règle de porte ouverte en cette année 2020 !

L'ancien site de la RTM n'était pas responsive, ce qui très malheureusement et très rapidement après son lancement commençait à ne plus être au fait des standards du web. Le site disposait toutefois d'une version mobile allégée disponible sur m.rtm.fr... Bien pratique pour les utilisateurs occasionnels qui ne voulaient pas forcément installer l'application mobile de la RTM. Mais cela l'était beaucoup moins pour les mainteneurs forcés de répliquer sans cesse tout changement.

Aussi ce système nous a donné du fil à retordre pour la gestion du cache. A chaque sortie d'un nouveau smartphone avec un User Agent non reconnu jusque-là, Il arrivait alors que la version mobile soit mise en cache pour les terminaux de bureau et vice-versa.

Aujourd'hui le nouveau site de la RTM n'est disponible qu'en une seule et unique version responsive. Il est entièrement accessible sur un terminal mobile en version complète.

Un Site Editorial / Des application métiers

Le précédent site était devenu au fil du temps un joyeux "fourre-tout" mélangeant sans vergogne :

  • Du contenu éditorial ;
  • Des actualités ;
  • La gestion des lignes et des arrêts (topologie) ;
  • Les horaires théoriques et temps réels ;
  • L'information voyageur (alertes trafic).

Puis se sont ajoutés :

  • L'abonnement au Passe Permanent;
  • Le paiement des PV ;
  • L'abonnement au service du Vélo ;
  • et j'en oublie sans doutes...

Et oui, tout ceci pour un simple CMS ! Alors certes, on peut faire beaucoup de choses avec Drupal (surtout en version 8.X) mais tout regrouper et avoir une approche monolithique n'était pas la bonne solution.

  • La RTM disposait déjà d'un service en charge de la topologie et il devait effectuer une double saisie ;
  • Le service en charge de l'information voyageur avait déjà son propre logiciel de saisie pour les panneaux d'affichage en station et il devait effectuer une double saisie ;
  • Le service en charge des PV avait déjà...
  • Le service en charge des abonnements...
  • etc.

Le site était devenu un goulot d'étranglement auquel plusieurs services n'ayant d'ailleurs peu de sensibilité web devaient se connecter pour faire de la re-saisie. Au delà de cet état de fait, la logique CMS de Drupal 6 n'était pas toujours appropriée pour les informations à gérer, ce qui rajoutait à l'inconfort de certains utilisateurs. Le nouveau site se devait donc d'y remédier.

Il a été décidé dès la phase de lancement de séparer la partie purement éditoriale de la partie métier :

  1. Le site Drupal 8 : chasse gardée du service communication de la RTM ;
  2. Communication via webservices avec les autres outils de la RTM s'ils existent ;
  3. Une application métier hors Drupal lorsque le service n'existait pas.

Découplage à tous les étages - Nous avons travaillé en utilisant une technique dite de "découplage progressif".

Drupal 8

Notre CMS de prédilection a été utilisé pour les pages d'informations, la FAQ, les actualités et malheureusement les tarifs (nous y reviendrons). Les seuls administrateurs sont les membres du service communication et informatique de la RTM. Il n'y a rien d'autre ici à faire que de gérer du contenu (ça tombe bien pour un CMS), plus de lignes de métro à ajouter, d'arrêts de bus à renseigner ou d'alertes trafic à saisir 2 fois !

VueJS

Les autres pages du site (itinéraires, horaires, MaRTM, PV, Passe Permanent) sont également des pages Drupal mais qui utilisent un framework javascript : VueJS.

Ces pages ne sont pas administrables en back-office (ou alors un simple bloc permettant de rédiger un en-tête informatif), elles n'en ont pas besoin. Les données affichées ne sont pas extraites du CMS Drupal et de sa base de données, mais proviennent de sources externes, administrées ailleurs par les services compétents.

Le site web n'est ici que dans une logique d'affichage et non dans une logique métier recréée de manière factice. Cette liaison est réalisée au travers de webservices exposant plusieurs APIs.

Des APIs - Il y en a beaucoup !

Comme évoqué plus haut, certaines APIs étaient déjà en place (itinéraires, temps-réel), mais nous sommes partis des dernières versions, plus performantes que celles utilisées sur le site précédent. D'autres ont été adaptées par nos soins sur la base d'outils externes et enfin certaines ont été entièrement développées en fonction des besoins. 

Une application métier (Phalcon)

La question s'est rapidement posée dès le début du projet de faire un choix technologique pour toute la partie "métier". Initialement nous serions naturellement partis vers Symfony, compagnon naturel de Drupal depuis la version 8. Mais nous avions de gros impératifs sur le plan de la performance et du temps réel (voir la partie sur le Hub).

Nous avons donc revu ce choix en faveur d'un autre framework de développement PHP : Phalcon. Il s’agit également d’un framework MVC comme tant d’autres mais il a la particularité d’être très rapide.

Nous aurions pu choisir d’autres solutions réputées pour leur rapidité comme Go ou NodeJS (et pourquoi pas Phœnix) mais Phalcon avait l’énorme avantage de rester dans l’écosystème PHP, un peu moins d’audace certes mais moins de risques avec l’équipe en interne.

Phalcon nous a servi :

  • de proxy pour les APIs externes (afin de ne pas les exposer directement au public) ;
  • pour la rédaction des scripts à même de traiter les sources XMLs fournies quotidiennement par la RTM pour la topologie (voir plus loin) et d’en faire une API ;
  • pour l’interface avec la solution d’alertes trafic et aussi pour la transformer en une API REST consommée par le site ;
  • d’interface pour les agents RTM afin qu’ils puissent traiter vos paiements PV, abonnements au passe permanent, etc.
  • Enfin les comptes utilisateurs / usagers MaRTM ne sont pas dans Drupal mais bien dans Phalcon et exposés via une API en interne.

Ce que vous ne saviez pas...

Ce projet de refonte du site a commencé en 2016 et il n’était pas encore question justement de paiement de PV en lignes, d'abonnements au Passe permanent. Et on ne pouvait pas attendre le mois de janvier 2020 quand ces sujets ont été évoqués à mi-parcours. Il fallait donc que cela soit disponible sur l'ancien site, alors en production.

Allait-on tout refaire ? Et bien non ! (Suspense de très courte durée)

En réalité la partie Phalcon a été mise en place sur Drupal 6 en premier lieu, toujours avec VueJS et une API REST (et ça n’était pas gagné avec Drupal 6...) De manière transparente, les utilisateurs du site Drupal 6 ont été également importés dès cette période.

Nous n’avons donc eu qu’à adapter la partie VueJS, profiter des nouveautés de Drupal 8 et adapter les interfaces à la nouvelle charte graphique. Et au moment de la mise en production cette stratégie a payé car nous n’avons pas eu de grosses frayeurs au moment de la transition.

Un site performant

Le site Drupal 6 avait souffert, notamment lors des grèves (cas exceptionnels d'explosion du trafic sur une très courte durée). Imaginez la moitié de Marseille se connectant sur une très courte période (entre 6 et 8h) au site internet pour savoir quel ligne prendre ou ne pas prendre.

Il y a donc eu dès le départ du projet une volonté claire (et de fortes attentes de la part de la RTM) d’avoir un site capable de subir de très forts pics d’affluence sans tomber dans les pommes. Ici le choix d’une architecture découplée offrait quelques avantages :

  • Drupal n’étant en charge que de l’aspect éditorial, et 100% anonyme (tout le monde voit les mêmes informations), il devenait donc possible de mettre entièrement www.rtm.fr en cache statique avec une durée raisonnable. Varnish étant capable de servir des milliers de requêtes par minutes sans lever un sourcil.
  • Quand aux partis dynamiques (vos favoris, vos abonnements, vos PVs...), elles ne sont pas servies sur le même domaine et relèvent de Phalcon via des appels JS asynchrones (Ajax).
  • Pour le moment rien n’est mis en cache côté API / Phalcon mais en cas de gros pépins on pourrait assez facilement le mettre en place sur les parties info trafic et augmenter encore un peu plus la résilience.

Adieu donc aux configurations Varnish compliquées, aux problèmes d’invalidation du cache (bon il y en aura toujours, on le sait mais nous avons bien réduit le périmètre exposé), aux user agents inconnus aux bataillons, etc. etc. Nous surveillons toujours les jours de grève générale, mais jusqu’ici notre sommeil et celui de la RTM est préservé !

Le Hub

Sous cette dénomination très innocente se cache un autre « gros chantier » de cette refonte. La RTM s'est conformé aux standards reconnus en matière de transport. La régie en a profité pour uniformiser et regrouper des outils internes jusque-là épars et spécifiques. Elle a par conséquent adopté l'utilisation des normes...

  • NETEX (Network Exchange - format de référence européen pour échanger des données d’offre théorique du transport collectif) ;
  • SIRI (Service Interface for Realtime Information - protocole pour l'échange d'informations, en temps réel, sur les réseaux de transport en commun.)

Je vous laisse vous perdre quelques instants dans la documentation... Vous êtes toujours là ?

Nous avons donc dû nous accoster à ces nouveaux services internes fournissant des informations à l’aide de ces standards. Au delà de la difficulté technique, le soucis principal que nous avons rencontré était que ces normes exposent énormément de données (la longueur du quai, le type de bus, à soufflet, à rallonge, l’âge de la fille du contrôleur etc.) Données brutes qui souvent ne font pas sens pour l’usager final. Nous avons donc du, trier, sélectionner et surtout ré-injecter une logique « usager et commerciale » là où il n’y avait que des considérations industrielles utiles à la bonne marche du réseau.

Sans trop rentrer dans les détails mais pour vous donner un exemple, la norme NETEX n’a pas la notion de ligne commerciale au sens de la 24s ou de la 98. Il n’y a que des bus qui parcourent certains arrêts pour un jour donné. A vous (enfin surtout nous) de reconstruire une information intelligible à partir de ces données purement techniques.

A ce jour tout n’est pas parfait, nous avons du redescendre de nos grands chevaux et adopter certains compromis. L’offre commerciale est toujours extraite d’outils anciens, recoupés avec la norme NETEX par exemple. Mais le fait d’avoir opté pour le découplage progressif va nous permettre petit à petit de faire le ménage côté métier, sans à chaque fois reprendre l’affichage sur le site. En tant que client du réseau RTM, vous ne savez pas d’où proviennent les informations sur les horaires, les arrêts et c’est très bien comme cela !

The good, the bad and the ugly 

Et bien il est là ce nouveau site ! A l’heure où je rédige cet article j’ai toujours du mal à y croire ! Je m’attends toujours à tomber sur l’ancien et vérifie à deux fois ma barre URL sur mon navigateur. Mais non je suis bien sur le bon, sur mon smartphone par dessus le marché.

Il se passe en moyenne moins d’une minute entre le moment où un agent RTM en charge de l’information voyageur saisi une alerte et le moment où elle apparaîtra dans votre poche. Tout dépend du moment où vous avez affiché la page, qui se rafraichît en tâche de fond chaque minute. Avec un peu de malchance il se passera 2 minutes.

Est-ce que tout est rose pour autant ? Non !

L’offre tarifaire est toujours gérée côté Drupal et c’est une grosse entorse à notre projet de départ. Il y a énormément de cas possibles, de « facettes » et surtout nous sommes à nouveau dans un cas de saisie multiple. 

Les favoris que vous créez sur le site ne sont pas récupérés sur l’application mobile et vice-versa. C’est bien dommage car nous disposons d’une API pour cela dont nous sommes encore malheureusement les seuls consommateurs.

Il y a encore des outils legacy qui sont utilisés et qui ne répondent pas aux normes du Hub.

Mais rien n’est figé et définitif avec l’architecture retenue et ça c’est une bonne nouvelle.

Et si c’était à refaire ?

C’est facile d’arriver à la fin et de jouer les mouches du coche mais prêtons-nous à un petit exercice de développement web fiction.

Le gros chantier du Hub s’est révélé être la partie la plus longue à mettre en place (beaucoup de prestataires dans la boucles, qui s’attendent les uns les autres et forcément cela prend du temps). Le projet Hub évoqué dès le départ a pas mal évolué en termes de possibilités et jusqu’à la livraison nous avons travaillé en « mode bouchon » sur la base de suppositions initiales. 

Nous nous sommes adaptés, ce n’est pas le problème mais d’un point de vue UI/UX c’était plus compliqué. Nous avions arrêté certains choix et difficile de revenir en arrière au fur et à mesure des évolutions.

Maintenant que tout fonctionne et que nous savons parfaitement ce qu’il est possible de faire ou pas, quelles informations on peut extraire du Hub, à quelle fréquence les afficher etc. C’est là que nous aurions du faire un travail UX/UI. Mais ce n’était pas possible en début de projet.

Enfin si c’était à refaire et bien je découplerai totalement la partie front-end avec ReactJS par exemple. Drupal ne servant que d’API pour la partie éditoriale, et Phalcon pour le reste. Là nous aurions pu encore réaliser de beaux gains de performance, aller plus loin vers une PWA et tailler des croupières à l'application mobile (mais je m’emporte).

Enfin là aussi ce serait tout à fait possible. Je m’interroge encore sur la possibilité d’intégrer des formulaires créés via le Back-Office Drupal dans un front-end 100% JS, mais on devrait pouvoir trouver une solution. Ce serait je pense le dernier point bloquant.

Peut-être pour la version 2 ?...

Ludovic Coullet - @lcoullet
Un grand merci aux équipes de la RTM pour ce dur labeur... Michel et Marina se reconnaîtront, mais tous les autres aussi !
Un énorme merci à l'équipe projet ici... Lara en Lead Développeuse en cheffe, Rouaida sur le frontend, Nicolas et Phalcon, Ahmad, Carole, Ryad, Elie...

Le site : https://www.rtm.fr
Mise en production : 13/01/2020.

Pour aller plus loin :