Jérémy Buget 🇫🇷 🇪🇺 · @[email protected]

ah non ! On avait dit qu'on ne parlait pas de Bruno ! 😂 youtube.com/watch?v=HuhtdBv5… Et sinon, à titre perso, j'ai mon instance @hoppscotch_io qui fait trop bien le taff.

PS : ce thread est exactement ce pourquoi j'ai imaginé et construit #threadr. Écrire du contenu qui vise à la qualité (de là à l'atteindre…) et le partager au plus grand nombre. 🤞 Pourvu que la publication fonctionne, même pour un thread de 50 messages… (au pire, vive PG!)

Chaque Job ajouté dans BullMQ (depuis le code), est stocké dans Redis. À ce propos, la commande Redis `MONITOR` est bien pratique pour vérifier la connexion de l'appli avec la DB et pour comprendre / déboguer en cas de problème.

💡 Pour le dashboard des jobs, j'utilise le projet "bullmq-dashboard-runnable" qui permet de lancer une instance du projet bull-board en une ligne de commande `npx`. github.com/pavel-voronin/bul…

💡 Techniquement, j'ai décidé de passer par une 3ème brique externe, BullMQ, un gestionnaire de Queues & Jobs. Pour fonctionner, BullMQ a besoin de Redis. C'est ainsi qu'on se retrouve avec un 3ème type de base (après MinIO et PG).

4️⃣ Nous voilà au dernier chantier important de ces 4 dernières semaines : la planification de publication ! En vrai, celui-là s'est révélé plus long que difficile. Maintenant, je maîtrise Nuxt / Vue, ce qui me permet d'aller plus vite et d'esquiver les gros pièges.

😵‍💫 On en vient à la partie la plus difficile du chantier, celle qui m'a le plus pris la tête, et qui n'a rien à voir avec la data, mais avec… le front-end. J'ai profité de travailler sur la persistence de données pour ajouter la liste des (résumés de) threads, sur le côté.

💡 J'ai décidé de partir sur un combo BDD relationnelle + champs JSONB, sur PostgreSQL. Reste à savoir comment connecter et exploiter le tout dans le code. Ainsi que les migrations de schéma. Pour cela, j'ai sorti mon meilleur Prisma.

💡 En ce qui concerne le design (stocker chaque Versions ou Drafts sous la forme d'un document complet au format JSONB), je suis très content du résultat, qui va très facilemetn me permettre de gérer un historique des modifications. Vive le Ctrl+Z !!!

J'entends l'argument du stockage au format fichier bien pratique et la légèreté du truc, mais aussi simple que soit #threadr à l'heure actuelle, je me sens beaucoup plus serein avec PG que SQLite pour le futur. Ce chantier m'a demandé de faire des choix forts. PG en est un.

Une base document type MongoDB ou même clé-valeur type Redis pourrait faire l'affaire. Mais j'ai en tête de gérer plus que des Threads dans #threadr. J'envisage de gérer des Settings, voire à terme des Users. Bref,je pressens que je vais avoir besoin de relationnel prochainement.