Passer un traitement en asynchrone sans plan d'action, c'est pas une solution. C'est un somnifère.
Si t'en abuses, tu vas t'endormir au volant.
J'ai vu ce scénario encore et encore : un appel est lent, la UI galère, et quelqu'un dit "on le met en asynchrone, on corrigera plus tard". Ticket fermé, tout le monde respire, et moi je soupire.
Spoiler : il n'y aura pas de "plus tard".
Parce qu'une fois que le symptôme a disparu de l'écran, il disparaît de la to-do. En science cognitive, ça s'appelle le biais de substitution.
La question difficile "pourquoi c'est lent ?" est remplacée par une question simpliste "comment contourner la lenteur ?". Et on passe à autre chose, sincèrement convaincu d'avoir réglé la situation.
Le vrai problème ne bouge pas, lui. Sauf que maintenant il se cache derrière une queue, des mécanismes de retry, et un broker qui a besoin de son propre monitoring.
Un appel synchrone lent, c'est visible, c'est mesurable, c'est chiant. C'est pour ça qu'il se fait corriger. Un appel asynchrone lent, c'est silencieux. Le silence en prod, c'est rarement bon signe.
Et c'est sans compter l'expérience client déplorable !
Quand le traitement est asynchrone, ta clientèle ignore si sa transaction a réussi ou non. Toi-même t'en sais rien et ça se voit. Ou alors tu lui mens, ce qui est pire.
J'ai vu ça sur certains e-commerces. Tu valides ta commande, on te dit "Commande en cours de préparation", et toi tu pars aux champignons en toute décontraction. Deux heures plus tard, rejet faute de stock.
Comme souvent le garde-fou est tellement basique que j'ai un peu honte d'en parler : avant de valider le passage en async, on se demande sérieusement "moi client, est-ce que j'ouvre un autre onglet ?"
Si la réponse est autre chose qu'un grand non, t'as pas un problème d'architecture, t'as la flemme.
Publié à l'origine sur LinkedIn.
Voir le post sur LinkedIn →