Effect : tour d'horizon du « Reliable TypeScript » | ignorance on display
Le point de départ d’Effect est un constat sur les signatures TypeScript. [...] La signature dit (a: number, b: number) => number. C’est faux : cette fonction peut lancer une exception, et rien dans le type ne le révèle. Le compilateur ne forcera jamais un appelant à gérer ce cas.
Ça m'évoque la grosse déception en arrivant de Python où l'on peut catch en cascade toutes les erreurs par leur type. La gestion d'erreurs dans mon code TS est au mieux laborieuse, au pire désastreuse.
const robust = program.pipe( Effect.timeout("2 seconds"), Effect.retry(Schedule.recurs(3)), );
Une bonne économie de code boilerplate, toujours pénible à écrire. Mais probablement que d'autres solutions existent déjà sans nécessiter Effect. Et la syntaxe est loin d'être lisible (nouvelle pensée pour Python et son lisibilité de pseudo-code).
// Retry sélectif : on ne réessaie que ce qui a un sens d'être réessayé const smart = fetchQuote.pipe( Effect.retry({ schedule: policy, while: (error) => error._tag === "NetworkError", // pas les erreurs 4xx }), ); Le retry sélectif illustre bien la synergie avec les erreurs typées : parce que le canal d’erreur est une union discriminée, la condition while est vérifiée par le compilateur. Réessayer une erreur de validation n’a aucun sens ; avec des erreurs unknown, cette distinction se fait à coups de instanceof fragiles.
Cool, gros helper pour gérer les dépendances externes. On rejoint petit à petit l'exécution durable.
Dans l'ensemble je trouve ça intéressant, mais il y a un gros effort de modélisation / structuration à faire en amont. On n'invente pas toutes les politiques d'exécution au fur et à mesure. L'effort doit être justifié par des exigences business (transactions bancaires, exécution de processus coûteux, pipeline data).
Effect veut posséder votre control flow. Une fonction qui retourne un Effect ne peut être consommée idiomatiquement que par du code Effect ; l’unité d’adoption réaliste est le service entier, pas la fonction.
Évidemment, oui.
Restent les inconvénients de confort : stack traces moins directes (le runtime s’intercale, même si les spans compensent), types d’erreur de compilation parfois monstrueux, et une dépendance forte à un écosystème unique — un framework au sens fort, pas une bibliothèque qu’on retire en une journée.
Mauvais stack trace acceptable à partir du moment où les erreurs sont beaucoup mieux gérées dans le code et à la compilation. Choix fort tout de même.
En pratique, Effect se justifie quand trois conditions se cumulent : un backend (ou un domaine métier) complexe à longue durée de vie, où la fiabilité vaut de l’argent ; une équipe stable prête à investir plusieurs semaines d’apprentissage ; et un périmètre où l’adoption peut être entière (un service, un module complet). Il ne se justifie pas pour un script, un prototype, une équipe à fort turnover, ou un projet dont la valeur vit dans des intégrations npm profondes (ORM, middlewares) qu’il faudrait ponter une à une — le cas Harbor.
Ou un projet from scratch codé uniquement par IA. d'où le marketing autour des outils de CodeGen.
Extraits cités issus de ce lien visité le , crédits: Claude