La Ruche
Projet académique en équipe · En développement actif
Le projet
La Ruche est un forum de discussion réservé aux étudiants d'un cégep montréalais. Les discussions vivent dans des groupes : les groupes de domaine pour les cours, créés par l'administration, et les groupes d'intérêt proposés par les étudiants, qui restent en attente jusqu'à ce qu'un administrateur les approuve. Les membres publient, commentent et signalent du contenu, et chaque groupe a ses propres modérateurs et sa propre liste de bannis.
Deux équipes de quatre le construisent : une API REST FastAPI dont le fichier openapi.yml est le contrat contre lequel chaque réponse est testée, et un client Android en Kotlin selon MVP. Un site web et une application d'administration sont prévus sur la même API. L'application Android tourne encore sur des données simulées; la brancher sur l'API est la prochaine étape.
Ma contribution
Côté API, la collection des utilisateurs de bout en bout (création, consultation, filtres, modification, suppression), les tests de bout en bout des groupes et des publications, l'outil qui vérifie chaque réponse contre le contrat OpenAPI, et la mise en place de Docker et de l'intégration continue. J'ai aussi rédigé le plan de refactorisation du sprint 3. Côté Android, les écrans de publication, de nouvelle publication, de profil et des groupes rejoints, avec leurs présentateurs testés contre de fausses vues.
Le plus difficile
Le plus difficile a été la visibilité. Une même publication peut être affichée, masquée ou donner un 404 selon qui la demande : un groupe en attente ou refusé n'est visible que par son créateur et les administrateurs, un groupe supprimé que par les administrateurs, une publication supprimée que par son auteur, les modérateurs du groupe et les administrateurs. Chaque règle doit tenir sur toutes les routes qui mènent au contenu, routes imbriquées comprises, et la plupart de mes correctifs dans l'API visaient une route qui en laissait passer une, comme une publication d'un groupe supprimé encore servie.
L'inscription avait sa propre condition de course. FastAPI exécute les routes synchrones dans un pool de fils, donc deux inscriptions simultanées pouvaient toutes les deux passer la vérification d'unicité du pseudo ou du courriel. La vérification et l'écriture se font maintenant sous un même verrou, et le hachage du mot de passe, qui est lent, est fait avant de le prendre.
Ce que je changerais
Ce verrou ne protège qu'un seul processus qui garde ses données en mémoire. Avec MariaDB au sprint 3, l'unicité doit reposer sur une contrainte UNIQUE, pas sur le code applicatif. Les règles de visibilité sont aussi réécrites route par route au lieu de vivre dans une seule fonction, ce qui explique que les correctifs soient arrivés une route à la fois.
