Article très intéressant et détaillé sur le diagnostic mémoire avec NodeJS.
C'est bien de diagnostiquer, mais ce serait encore mieux de ne pas avoir à le faire et c'est peut-être la seule chose qui manquerait à cet article.

Hors librairie tierce bugguée, si vous avez une fuite mémoire, c'est vraisemblablement un souci dans le design de votre code. Une variable globale ou closure difficile à suivre qui mute à des endroits inattendus... Un design simple (KISS) pourrait éviter ces heures de debuggage compliqué, et oui c'est dur de faire simple tout en répondant au problème. Des paradigmes (programmation fonctionnelle, immutabilité...) peuvent aider, mais chaque solution doit être adaptée au problème et à l'équipe aussi. Bien sûr parfois on doit utiliser avec précaution certaines API comme setInterval, le code qui gère le handler doit être le plus isolé possible.

(c'est là que Benoit arrive ses gros sabots "si tu veux apprendre à faire du code propre solide durable, je t'invite à regarder le cursus artisan développeur etc ...." :-D :-D :-D )

Corollaire: sauf si vous avez une thèse en cache et du temps à perdre, ne réinventez pas la roue, utilisez une librairie de cache supportée et éprouvée.

Des gros sabots, moi ?
C'est pas très gentil... 😢

Mais sinon, en effet, tu peu aller jeter un oeil au cursus... 😅

Mais si c'est affectueux. C'est juste que c'est le moment où, dans le podcast, tu montres la pertinence d'aller voir le cursus 😉

@Anh-Vu Tran Effectivement les fuites mémoires proviennent la plupart du temps d'un souci dans le design de notre code ou d'une librairie tierce mal conçu. C'est pourquoi j'explique les principales causes de ces fuites mémoires pour justement les éviter. Après il n'est pas toujours évident de s'en apercevoir d'où le fait de savoir comment diagnostiquer son application ;)