refonte mobilizon instances

Sommaire

Pourquoi
- Les raisons
Design
- exploration
- Stack
Productivité
- Temps
- Lignes de code
Futur

Ce journal raconte la ré-écriture de l'outil Mobilizon Instances suite au passage de témoin entre Framasoft et Kaihuri.

Mobilizon Instances est outil satellite de Mobilizon, l'outil de gestion d'événements pour le Fediverse. Il s'agit du catalogue des instances que les utilisateurs ont bien voulu référencer (optin). Cela permet aux nouveaux venus de trouver une instance qui pourrait correspondre à leurs goûts.

Mobilizon Instances récolte aussi des données statistiques sur ces instances, quotidiennement, afin de les exposer.

Pourquoi

Mais cet outil existe, tourne et son code est publié, pourquoi vouloir le ré-écrire, me direz vous ?

Soyons honnête : parce que j'en ai envie ! Mais cette envie est quand même motivée par certaines raisons liées à la maintenabilité et à l'évolutivité. Car je serai probablement le seul à y toucher. Les contributeurs sont toujours bienvenus mais nous préférons concentrer les efforts sur le produit principale.

Les raisons

Nodejs 8 ; le code n'a pas été retouché depuis des années et quand j'ai essayé de le faire tourner localement, je n'y suis pas arrivé. Soit je passe du temps à le mettre à niveau, soit j’investis ce temps dans autre chose
Nodejs ; je n'aime pas écrire du JS/TS, encore moins en backend. Je vois l'intérêt d'un framework web quand on a un front chiadé ; nous utilisons vuejs pour Mobilizon. Ici, le cas me paraît suffisamment simple pour s'en passer. Pour le backend, j'aime beaucoup Elixir ou Python, un peu Go, un jour peut être Rust.
Sqlpage ; j'ai déjà eu deux bonnes expériences avec SQLPage sur des projets perso. Quand on peut se permettre de rester proche des données et qu'on aime pas le frontend, c'est assez idéale. Je voulais mettre à profit cet avantage pour le cas présent.

Quand je parle de bonne expérience, je parle autant des fonctionnalités de l'outil que de sa superbe documentation et de sa bienveillante communauté. Je ne crois pas être seul.

Design

Le besoin est simple : deux écrans de consultation (liste, statistiques), un formulaire pour la proposition de nouvelle instance, et une tâche planifiée pour collecter et mettre à jour les données statistiques.

exploration

L'auteur de sqlpage est toujours disponible pour une discussion sur son produit, pour peu qu'on lui amène un cas d'usage concret.

Et cette discussion confirme mon intuition : sqlpage ne gère pas et n'a pas vocation à gérer des tâches planifiées.
J'ai donc un petit dilemme: si je dois écrire une bonne partie du logiciel avec une autre solution, pourquoi ne pas l'écrire entièrement avec cette autre solution.

Je me lance un court moment dans l'écriture du premier écran - liste des instances - en python+fastapi+pypug. Pypug en particulier, est très sympa quand on préfère une représentation à la Yaml plutôt qu'à la XML. Nous utilisons Pug dans le Mobilizon Importer.

Mais je ne trouve pas la foi d'écrire tout le code nécessaire à la simple représentation du contenu d'une table SQLite dans un tableau HTML : template avec itération, route web, DAO pour lire les données ; alors que je sais que SQLPage le fait en quelques lignes.

Stack

J'ai choisi:

Sqlpage pour les pages web
SQLite pour la base de données
Python+scrapy pour la collecte des informations
Crond (alpine) pour l'ordonnancement des tâches
s6 pour la gestion des services
healthcheck.io pour l'observabilité
le tout empaqueté dans une image docker

Productivité

Temps

J'ai donc balancé tout ça dans un LLM et deux minutes plus tard … Non, je n'ai pas fait ça.

Mais, une fois n'est pas coutume, j'ai comptabilisé le temps que j'y ai passé. Je voulais me prouver que je ne passais pas plus de temps sur une ré-écriture que sur une remise à niveau.

Cela donne:

design (1h) : le choix de la stack, le mise en place du projet, l’exploration
import data (4h) : j'ai perdu trop de temps sur des données Json, se méfier de -> versus ->> en SQL
écrans (4h) : efficace, avec les composants table et chart, sans surprise
tâche planifiée (4h) : scrapy est top, vraiment peu de code à écrire, sans surprise
packaging (3h) : peaufiner un dockerfile prend toujours un peu de temps car il faut tester
déploiement (1h) : idem pour un docker compose
optimisation (4h) : la vue statistiques était trop lente à mon goût, j'ai refactoré

Au total 21h, réparties sur une semaine et demie. Vous me direz ce que vous en pensez. Moi je trouve cela très correct.

Lignes de code

Autre indicateur qui m'intéressait, la quantité de code dans l'optique, le moins à maintenir, le mieux. Ça veut dire déléguer une partie de la complexité aux dépendances ; c'est le but.

vue : 93 lignes de SQL
job : 157 lignes de python, dont 41 liée à la migration de système
glu : 119 lignes de shell, dont 49 liée à la migration de système

Soit 369 lignes de code, 279 si l'on ne prend pas en compte le code nécessaire à la transition depuis le système existant. À comparer aux 1737 lignes de code actuelle.

Ce chiffre est à prendre avec des pincettes car minimiser la quantité de code est un objectif qui me tient à cœur mais qui n'est pas forcément partagé. Et il manque encore des choses, qui vont venir faire augmenter ce chiffre.

J'attribue ces bons résultats - temps passé et quantité de code - au choix de la stack et à la bonne connaissance que j’en ai.

La stack prend en charge une bonne partie du travail à faire : Sqlpage pour la gestion des routes et la production du HTML+CSS+JS. Scrapy pour la gestion du parallélisme, du protocole HTTP et des ré-essais. Sans oublier s6 pour la gestion des services au sein du container.

Futur

Cette version réécrite va tourner quelques temps en parallèle de la version en production, avant une éventuelle bascule.

La vue liste mérite entre temps d'être peaufinée, avec probablement l'ajout d'un peu de styles.
Je dois aussi travailler sur le nettoyage des instances fantômes et optout, géré les défauts de réponse.

À ce stade, j'ai trouvé l'exercice très plaisant.

Hep! pas si vite ! et le code alors ?

Il est consultable ici.