Hotwire et ViewComponent sont dans un bateau… Épisode 3 : pourquoi ?

Parce que la SPA est réellement tombée à l’eau. Après plus de cinq ans de développement et exploitation agiles d’un projet Rails API + EmberJS, nous avons décidé d’abandonner le cadriciel JavaScript pour revenir à une application fullstack Rails. Mais comment faire sans renoncer aux interfaces dynamiques et rechargements partiels qui plaisent tant à nos utilisatrices et utilisateurs ? Retour sur 609 jours de réusinage.

Mais avant, un peu de contexte : pourquoi partir sur une SPA en premier lieu malgré des années d’expérience en fullstack Rails ? Un peu pour découvrir le paradigme qui perçait à l’époque, et surtout pour satisfaire aux besoins d’utilisation hors-ligne. En effet, Filaé est une application amenée à être utilisée en zone blanche, sans données cellulaires, comme les cellules de garde-à-vue ou les talus les plus reculés de la forêt de Rambouillet par exemple. Une application Rails seule ne pouvait rendre ce service, alors qu’une PWA en JavaScript oui.

Un dolmen bien ancré

Dolmen signifie « table de pierre » : un bloc de pierre horizontal formant un plateau, sur deux blocs verticaux formant les pieds. Dans notre cas, notre dolmen logiciel reposait sur deux menhirs particulièrement solides :

1. une application Rails, dans l’écosystème Ruby que nous connaissons très bien ;
2. le vaste espace de communication entre client et serveur, sous la forme d’une API JSON conventionnelle.

Habitué aux alignements verticaux, il nous fallait désormais composer avec l’horizontalité du plateau, pour servir tout cela à nos utilisatrices et utilisateurs : une application EmberJS, dans l’écosystème NodeJS que nous devions apprivoiser.

Un petit mot concernant le choix de EmberJS. Il s’agissait d’un choix de philosophie plus que de fonctionnalités offertes par les différents cadriciels JavaScript. Nous aurions pu construire cette SPA avec React par exemple, et nous avons même tenté Elm… Mais imaginez JavaScript on Rails, et vous avez EmberJS : du fullstack SPA development, avec routage des URL vers des contrôleurs qui récupèrent leurs données avec un ORM sur une JSON:API, le tout aiguillé par des conventions de nommage et assisté par des générateurs de fichier en ligne de commande… Bref, JavaScript on Rails¹.

Intégrer un nouvel écosystème entier dans notre équipe de deux personnes n’était pas une mince affaire. Nous connaissions évidemment déjà JavaScript, et suivions les versions de NodeJS grâce (ou à cause) de l’asset pipeline de Rails notamment. Mais désormais, c’était tout un nouveau pan de gestion de dépendances qui tombait dans notre escarcelle : versions de NodeJS, EmberJS, bibliothèques EmberJS… Et à la longue, nous avons fini par décrocher. Nous avons bien tenté de faire les montées de version EmberJS, et notamment l’arrivée des éditions et leur première mouture Octane, mais le mode best effort a ses limites². Le plateau de notre dolmen commençait à vaciller… Et les fonctionnalités spécifiquement hors-ligne n’étaient toujours pas en haut de pile, quatre ans après le lancement de ce projet agile.

Avant que ce dolmen ne forme notre tumulus, nous avons décidé d’un commun accord de nous concentrer sur la partie Rails, la plus critique d’un point de vue sécurité, et d’abandonner la SPA pour revenir à un simple monolithe taillé pour l’énergie que nous pouvions y consacrer.

Supprimer la SPA supprimait aussi le besoin d’une API JSON documentée. Nous avons eu une bonne expérience de développement avec Pact et ses tests auto-documentants auto-hébergés avec Pact Broker. Cela avait également un coût de mise en place et de maintenance, mais la transparence apportée avait beaucoup de valeur.

Un bon vieux menhir, mais avec ornements

Le chantier était de taille (de pierre ?) : réécrire toute l’IHM de Filaé en Rails, côté serveur. Ceci dit, nous étions (et nos utilisatrices et utilisateurs aussi) bien habitués aux affichages dynamiques offerts par la navigation côté navigateur, sans rechargement complet de page comme on en a l’habitude côté serveur. Nous partions donc de notre menhir déjà en place, et rajoutions de quoi véhiculer élégamment de l’information, un peu à l’image des pétroglyphes. Nous avions alors besoin de nouveaux outils.

Nous n’avons pas eu besoin d’aller chercher très loin : accompagnant notre monolithe habituel se trouvait désormais Hotwire, avec ses briques Turbo et Stimulus. La première nous a permis de maîtriser plus finement la dynamique de nos pages et de la navigation, avec du morphisme de DOM et du chargement partiel et asynchrone. La deuxième brique apportait la réactivité aux événements-utilisateurs sans avoir à écrire de JavaScript ou presque. Adoptant l’approche #NoBuild, nous avons même supprimé toute dépendance à NodeJS dans le projet !

Au milieu des autres projets, il nous aura fallu plus de six cents jours calendaires pour mener à bien ce vaste chantier. Nous en avons profité pour améliorer considérablement notre harnais de test et par la même occasion notre couverture de code. Nous avons aussi pris le parti d’améliorer quelques fonctionnalités en passant, outrepassant le cadre du simple réusinage iso-fonctionnel ; mais quand on peut faire plaisir…

Aujourd’hui, Filaé ne présente plus aucun cadriciel obsolète se laissant éroder par les assauts du temps à défaut d’énergie disponible. Les montées de versions sont moins nombreuses, mieux maîtrisées, plus fréquentes et sûres.

Des pétroglyphes aux bas-reliefs

Un nouveau projet nous a permis de mettre à l’épreuve ces pratiques depuis une feuille blanche. Nous en avons tiré de nombreux enseignements qui nous ont mené à ViewComponent pour limiter la duplication de code et de magic strings (entre autres avantages). Nous vous renvoyons aux épisodes 1 et 2 de cette série pour plus de détails.

Après avoir cédé aux chants de sirènes beaucoup trop énergivores, nous sommes revenus à bon port. Nous allons poursuivre nos explorations, pour offrir de nouvelles capacités techniques et fonctionnelles, mais toujours dans le giron de notre environnement proche, comme Hotwire Native.

Construisons des pratiques à la hauteur de notre équipage, capable de livrer nos réalisations rapidement, en toute sérénité et pour longtemps.