- Création : 2022-09-14
- Dernière mise à jour : 2023-07-17
- Personnes impliquées : Mathieu Marchois, Florimond Manca
- Statut : Accepté
Dans le cadre du projet DiaLog, nous devons choisir un environnement technique sur lequel on peut se reposer pour numériser un arrêté de circulation et le diffuser auprès des calculateurs d'itinéraires via une API.
Contraintes
- Doit être compatible avec une démarche d'éco-conception de service numérique (questionner le besoin, réduire l'impact sur les terminaux, etc).
- Le langage doit disposer d'un système de typage statique.
- Le langage doit disposer d'un framework web full-stack (qui permet de travailler avec la base de données comme des vues HTML).
Nous avons choisi d'utiliser PostgreSQL en version 14 pour les raisons suivantes :
- Robuste, stable et open-source
- Performant avec un large volume de données
- L'extension PostGIS permet de l'utiliser comme une base de données SIG en ajoutant le support d'objets géographiques.
Nous avons choisi d'utiliser PHP en version 8 et Symfony en version 6 (à la date de création de ce document). Le raisonnement détaillé est évoqué ci-dessous.
Concernant le frontend, nous avons choisi une approche hybride de type "HTML with sprinkles of JS" (HTML saupoudré de JS).
En effet, le degré d'interactivité envisagé pour DiaLog étant limité (pages web, liens et formulaires), il n'a pas été jugé pertinent d'adopter dès le début un framework JS SPA (React, SvelteKit, etc).
L'essentiel du frontend est donc géré avec Symfony lui-même, via des templates Twig (équivalent de Jinja2 en Python).
Les éléments d'interactivté sont gérés via Turbo (mise à jour sélective de l'interface via des fragments HTML échangés entre le navigateur et le serveur), et Stimulus (interactivité côté client).
Cette approche devrait contribuer à l'écoconception du service numérique, ainsi qu'à son accessibilité pour les utilisateurs munis d'un équipement informatique contraint (matériel vieillissant, réseau ADSL...).
- Une base technique PHP/Symfony/PostgreSQL est mise en place.
- La documentation indique des ressources pour démarrer en PHP/Symfony, préférentiellement à destination d'utilisateurs de Python/Django ou Node.js.
Nous (Mathieu et Florimond) avons démarré le projet en octobre 2022 et nous étions familiers avec les langages suivants :
- Python (Florimond) ;
- JavaScript/Node.js (les deux) ;
- PHP (Mathieu).
Python est un langage très connu dans l'écosystème BetaGouv. Néanmoins, l'écosystème Python manque d'un framework web qui soit complet (qui inclue des fonctionnalités essentielles de sécurité, de cache, etc) et suffisamment souple pour s'accommoder d'une architecture de type Architecture Hexagonale qui favorise la maintenabilité. Django est sans doute le plus complet, mais il est très opinionated : il est difficile d'adopter une autre architecture sans se battre contre le framework.
Concernant le JS, en toute sincérité, nous souffrions de JS Fatigue. Exemple : il faut intégrer TypeScript et la complexité de la transpilation pour bénéficier d'un typage statique, tandis que ce dernier est désormais possible nativement en Python ou PHP.
Concernant PHP, à notre sens il souffre d'idées préconçues qui ne semblent plus applicables aujourd'hui. Sa performance semble largement suffisante grâce à des améliorations comme le JIT (just in time) compiler en version 8. Le language lui-même s'est amélioré en corrigeant les incohérences des débuts. Cela explique certainement pourquoi il s'agit encore d'un langage parmi les plus utilisés (voir sondages JetBrains 2021).
Côté framework, Symfony a le même statut dans la communauté PHP que Django dans la communauté Python. C'est l'un des frameworks PHP les plus utilisés. Il dispose d'un écosystème très complet et, point différenciant par rapport à Django, d'une vaste communauté francophone. Il fut en effet créé par SensioLabs en 2005 et a été téléchargé plus d'un milliard de fois.
Nous avons donc jugé que pour des personnes déjà à l'aise avec Python et Django, comme cela est courant au sein de BetaGouv, la barrière à l'entrée était suffisamment faible pour reprendre un projet en PHP/Symfony.
Le choix de ne pas recourir à un framework JS SPA provient aussi d'une volonté de réduire la complexité de la stack frontend. Les évolutions récentes des frameworks SPA (server-side component rendering, rehydration et autres) ne nous ont pas convaincu de leur pertinence pour notre cas d'usage de site métier avec peu d'interactivité et géré par une petite équipe. Il nous a semblé plus adapté de repartir d'une base HTML.
À la différence d'une architecture "Multi-page app" (MPA) historique, où chaque navigation déclenchait un rechargement complet de la page, des éléments d'interactivité visant à améliorer l'expérience utilisateur (UX) sont possibles grâce à Turbo et Stimulus.
- Turbo fournit des outils pour mettre à jour certaines zones de la page à partir de fragments HTML renvoyés par le serveur. En pratique, il intercepte les navigations natives du navigateur (liens, formulaires) et interprète la réponse du serveur pour mettre à jour la page de façon sélective. N.B. : Il n'y a donc pas d'API JSON entre le serveur et le navigateur : le serveur et le navigateur échangent du HTML tout-fait.
- Stimulus est une librairie JavaScript qui permet d'ajouter des comportements interactifs à des éléments de la page (exemples : afficher une modale, autocompléter un champ de recherche, ...).
Note : d'autres outils similaires existent. Par exemple htmx est similaire à Turbo ; Catalyst est similaire à Stimulus. Turbo et Stimulus ont été choisis pour leur intégration native à Symfony via le projet "Symfony UX".
Cette approche constitue un entre-deux entre les MPA (tout-serveur) et les SPA (tout-client). Elle est déjà utilisée à l'échelle. Par exemple, c'est l'approche adoptée par GitHub (cf les éléments <turbo-frame> dans le code source HTML de ses pages).
Nous nous appuyons sur les standards du Web (HTTP, HTML, CSS, JS) et leurs développements récents. Par exemple, les modales sont gérées via l'élément natif <dialog>. L'appui sur les standards devrait favoriser la durabilité et la portabilité du service.
Cette approche réduit aussi en principe (évaluations à faire) la charge sur les terminaux utilisateurs, en réduisant considérablement la quantité de JavaScript nécessaire. Cela contribue donc à l'écoconception du service numérique, ainsi qu'à l'accessibilité du service à des utilisateurs dont la qualité de connexion et d'équipement est variable (exemple : petites communes rurales avec ordinateur ancienne génération et réseau ADSL).