Ritchie Dagonia : ma stack de développeur back-end, expliquée
Je suis Ritchie Dagonia, 46 ans, développeur web back-end installé à Amsterdam. Voici les outils que j'utilise tous les jours, et surtout pourquoi. Pour chacun, j'ai aussi noté ce que je lui reproche : après plusieurs années avec un outil, on connaît ses défauts mieux que ses qualités, et c'est justement ce qui rend le choix honnête.
JavaScript et TypeScript, sur Node.js
Pourquoi je l'utilise
Un seul langage du navigateur au serveur, un écosystème immense, et un modèle asynchrone qui colle bien aux API qui passent leur temps à attendre une base de données ou un service tiers. TypeScript ajoute la rigueur qui manquait : les types sont ma première couche de documentation, celle qui ne ment jamais.
Ce que je lui reproche
L'écosystème bouge trop vite et trop souvent. Un projet laissé six mois sans mise à jour devient une séance d'archéologie. Et le typage, aussi bon soit-il, disparaît à l'exécution : il faut valider les données en entrée quoi qu'il arrive.
Un framework HTTP léger, orienté schémas
Pourquoi je l'utilise
Il fait peu de choses et les fait bien : routage, validation par schéma, système de greffons. Il ne m'impose pas d'architecture, ce qui me laisse organiser le code par domaine métier plutôt que par couche technique. La validation intégrée des entrées et des sorties m'épargne beaucoup de code ennuyeux, et elle produit la documentation de l'API presque gratuitement.
Ce que je lui reproche
La liberté a un prix : chaque équipe réinvente sa structure de projet, et il faut des conventions écrites dès le premier jour. La documentation suppose aussi que l'on connaît déjà l'écosystème, ce qui rend l'arrivée d'un débutant un peu rude.
PostgreSQL
Pourquoi je l'utilise
Fiable, prévisible, extrêmement bien documenté. Les transactions font ce qu'elles promettent, les contraintes empêchent les données incohérentes d'entrer, et le type JSON permet d'assouplir le modèle sans renoncer au relationnel. Je fais confiance à cette base depuis longtemps et elle ne m'a jamais surpris en mal.
Ce que je lui reproche
Les plans d'exécution demandent un vrai apprentissage avant d'être lisibles, et une migration de schéma sur une grosse table reste un moment délicat. Le nombre de connexions est limité, ce qui oblige à ajouter un gestionnaire de connexions dès qu'on multiplie les instances de l'application.
Redis et une bibliothèque de files de tâches
Pourquoi je l'utilise
Tout ce qui n'a pas besoin de réponse immédiate part dans une file : courriels, exports, tâches planifiées, recalculs. L'API répond vite, le travail se fait en arrière-plan, et les échecs sont rejoués automatiquement. C'est la brique qui rend le reste du système calme.
Ce que je lui reproche
Les tâches doivent être idempotentes, et c'est plus difficile qu'il n'y paraît. Et une file qui se remplit sans que personne ne la regarde est une bombe à retardement : il faut la surveiller aussi sérieusement que la base de données.
Des tests d'intégration contre une vraie base
Pourquoi je l'utilise
Je teste surtout au niveau des routes, avec une vraie base de données dans un conteneur jetable, lancée par un lanceur de tests moderne. C'est un peu plus lent que des tests unitaires purs, mais cela attrape les vrais problèmes : requêtes SQL fausses, contraintes oubliées, transactions mal fermées. Les tests unitaires restent réservés à la logique métier pure.
Ce que je lui reproche
La suite complète prend du temps, et chaque nouveau membre de l'équipe doit d'abord faire fonctionner l'environnement de test sur sa machine. Les tests d'intégration sont aussi plus fragiles quand le schéma bouge : une migration peut en casser des dizaines d'un coup.
Conteneurs, intégration continue et un hébergeur cloud
Pourquoi je l'utilise
Chaque service est empaqueté dans une image de conteneur, construite par l'intégration continue à chaque fusion sur la branche principale, puis déployée chez un hébergeur cloud. Le même artefact tourne sur ma machine, en recette et en production. C'est ennuyeux et répétable, exactement ce que je veux d'une mise en production.
Ce que je lui reproche
La couche d'orchestration ajoute une complexité que les petits projets ne méritent pas. Et la facture d'un hébergeur cloud se lit difficilement : il faut la surveiller comme une file de traitement, sinon elle grossit en silence.
Terminal, Git, un éditeur de texte et des conteneurs
Pourquoi je les utilise
Un terminal et quelques alias font l'essentiel. Git est ma mémoire de travail : petites branches, historique propre, messages de commit qui racontent pourquoi. Les conteneurs me donnent un environnement identique pour chaque projet sans polluer ma machine, et mon éditeur n'a pas changé depuis des années, parce qu'il ne se met pas entre le code et moi.
Ce que je leur reproche
Git a une interface qui trahit son âge : après toutes ces années, je cherche encore certaines commandes. Les conteneurs, eux, consomment beaucoup de ressources sur un ordinateur portable, et le ventilateur me le rappelle chaque après-midi.
Pourquoi cette stack change lentement
Cette boîte à outils évolue peu, et c'est voulu. J'ajoute un outil quand il résout un problème que j'ai réellement rencontré, pas parce qu'il est à la mode. À 46 ans, j'ai vu assez de modes passer pour attendre qu'elles se calment avant de décider.
C'est aussi une question de transmission : une stack stable est une stack que l'on peut expliquer à quelqu'un qui arrive, en une après-midi, avec un tableau blanc. Si je n'y arrive pas, c'est que l'outil est de trop.
Pour le contexte, mon quotidien de développeur et ma vie de Français à Amsterdam sont racontés sur la page d'accueil.