Journal refonte mobilizon instances

Posté par  . Licence CC By‑SA.
Étiquettes :
23
9
juil.
2025

Sommaire

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.

  • # abstractions

    Posté par  . Évalué à 3 (+1/-0).

    Petite digressions sur les dépendances.

    Bien souvent, les frameworks / bibliothèques apportent des abstractions qui ont tendance à rendre difficile la compréhension du fonctionnement du code de l'application: macro, décorateurs, introspection, asynchrone/tread, callback, you name it.

    Ce n'est pas le cas de SQLPage car le schéma est simple et constant:

    • recevoir le contenu de la requête sous forme de variables
    • faire des opérations d'écriture dans la DB (optionnel)
    • faire des fetch/exec pour interroger des systèmes externes (optionnel)
    • selectionner un composant et ses propriétés (Top-level parameters)
    • selectionner les données pour alimenter le composant (Row-level parameters)

    Ici, pas de magie noire et la documentation est limpide.

  • # merci

    Posté par  (site web personnel) . Évalué à 3 (+1/-0).

    Merci beaucoup d'avoir pris le temps d'écrire ce retour d'expérience.
    Avoir mesuré le temps et les lignes de codes, et pouvoir comparer les chiffres avec une version dans un autre langage est très instructif.

    Comment étaient réparties les 4h passées sur la création du tableau et des graphiques ? Est-ce que vous pensez que l'on pourrait améliorer SQLPage ou les pages de documentations pour réduire encore ce temps ?

    • [^] # Re: merci

      Posté par  . Évalué à 4 (+2/-0).

      Avant tout, je ne considère pas que 4h soit beaucoup car je ne pense pas être très rapide. Je ne me souviens pas exactement comment ce sont répartie ces 4h.

      Je sais que je commence par travailler ma requête de restitution des données dans sqlitebrowser. Puis je la mets dans la page web.

      Je sais aussi que je fais pas mal d'itérations: est-ce que je fais une page séparé pour le formulaire ? Quels icônes dans le menu ? Et si j'ajoutais ceci ? Et si je retirais cela ?

      En tout cas, pour moi la doc est vraiment un point fort avec la partie référence des paramètres puis les exemples prêts à l'emploi, c'est top.

      En y repensant, ce qui me prend peut être plus de temps que nécessaire, c'est de choisir le composant dans la liste :
      une liste ou un tableau ; un hero, un text, une alerte, un HTML ou un empty_state pour l'écran de confirmation d'ajout.

      Et du coup, je me dis, en plus du titre, de l’icône et de la description du composant, pourquoi ne pas avoir une petite vignette du rendu visuel du composant ; cela permettrait de choisir visuellement au lieu de se faire une idée à partir du texte. Et de les faire défiler plus rapidement.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.