On va parler un peu de Prim, la plateforme d'Île de France Mobilités pour diffuser en #opendata les données des transports de la région, tous modes confondus (fer, tram, métro, bus). https://t.co/0ejQUkg1xr https://t.co/Nl079OnkWY

Cet été, la plateforme a subi une migration d'hébergement (le bandeau orange dans la page précédente) de la section "données temps réel", j'y reviens plus loin (c'est pour ça que je fais ce fil, en fait).

La plateforme contient toute une palanquée de jeux de données sur les horaires, arrêts, gares, zones d'arrêts/correspondance etc. C'est très compliqué car une zone d'arrêt inclure plein de modes de transport, correspondances, des quais de différentes lignes/directions, etc.

IDFM (Île de France Mobilités) s'occupe d'agréger tout ça entre les différents opérateurs de transport de la région et c'est du boulot car ils sont *nombreux* (surtout les bus) (https://prim.iledefrance-mobilites.fr/content/files/2022/07/MAJ-Documentation-fonctionnelle-PRIM-11-juillet-2022-5.pdf) https://t.co/13wuTF4c2a

Du coup on a une API temps réel qui diffuse tout en 1 point, c'est assez pratique même si le format (Siri, un dérivé de XML avec conversion en Json) est assez compliqué (la joie des modèles de données d'informatique de gestion + gestion par comité + convertisseurs automatiques).

Le charme de l'API c'est qu'elle donne à quelques secondes près les estimations des horaires de passage ferrés des trains/métros/tramways en gare. La SNCF dispose d'informations similaires pour tous ses trains mais elles ne sont pas publiques (hors Transilien).

L'API est d'accès libre sur création de compte, avec des quotas de requête qui permettent de faire des choses raisonnables (je récupère H24 les données de passage de tout le réseau ferré de la région, et avec un algo pas trop débile ça passe dans le quota gratuit).

Il y a plein d'autres choses intéressantes comme un calculateur d'itinéraires de transport, utilisé par des apps (notamment l'app IDFM je pense), mais je ne m'en sers pas.

Maintenant arrivons-en à l'API temps réel. Celle-ci comporte 2 modes, le mode "par arrêt" donnant l'information fraîche pour 1 gare (ou quai) donné, et le mode "requête globale" qui donne toute la région (tous modes) en 1 bloc très gros, et qui n'est pas aussi fraîche.

La requête globale est en fait manifestement un truc prémouliné, rafraîchi toutes les 2-3 minutes environ, vs quelques secondes pour l'API "par arrêt". De plus la requête globale semble comporter des trous (des trains RER B sud y restent invisibles).

La requête globale comme la requête "par arrêt" (dite unitaire en parlance IDFM) sont gérées par les mêmes serveurs frontaux. Ce sont eux sur lesquels le déménagement est le plus visible.

L'ancien système avait des points d'entrée en http://traffic.api.iledefrance-mobilites.fr, hébergé sur AWS (Amazon). Le nouveau est sur http://prim.iledefrance-mobilites.fr, même nom que le site web précité, hébergé sur Azure (Microsoft).

En fait, que font les frontaux ? Pas grand chose, ils servent juste de réflecteurs de données pour rediffuser "en masse" et aussi vite que possible les données collectées et moulinées par ailleurs.

Typiquement le jeu de données tient largement en mémoire d'une machine moderne, les requêtes sont simples, donc le frontal n'a qu'à tenir sa table à jour depuis le collecteur et renvoyer une réponse prémâchée à toute requête de l'utilisateur, après authentification.

En plus de ça il faut un "routeur d'URL" en frontal pour diriger les requêtes soit sur le site web, soit sur le serveur d'API, puisque tout est sur le même nom DNS. Pourquoi pas mais c'est étonnant d'avoir une architecture qui introduit un SPOF sur ce routeur d'URL.

Ensuite la migration. Elle a été ouverte au public le 18 juillet, et les utilisateurs ont 2 mois (jusqu'à la mi-septembre) pour réécrire leur code. Si IDFM doit payer à la fois des serveurs AWS et Azure pendant la transition, je comprends qu'on en limite la durée.

Mais par contre, ce que je comprends moins bien c'est : pourquoi les réflecteurs sur AWS et Azure ? La techno du réflecteur est assez simple, le scaling probablement limité (pas besoin de centaines de serveurs a priori), donc pas besoin de techno propriétaire spécifique AWS/MS ?