Un article qui parle des timeout en Node.js et de la manière dont ils peuvent être la cause de memory leak même en utilisant clearTimeout.
L'objet Timeout conserve un contexte qui vient de la closure utilisée lors de la déclaration et il conserve aussi les références en provenance de AsyncLocalStorage si un contexte ASL est présent.
Bref, il vaut mieux set la variable à null une fois que l'on a clear le timeout.
Si on créé un binaire avec Node.js et qu'il contient du code malveillant alors ça passe tous les heuristiques de détection de malwares
Un article critique sur Bun.
Pas mal de bashing un peu gratuit et de demi vérité:
- performances: tout ce qui est lancé en local avec Bun est instant vs plusieurs secondes avec une stack Typescript standard
- pas de version manager: Bun vient d'être release et il y a litéralement 3 versions donc pas vraiment besoin, be patient ^^
- moins de backward compat que Node: en même temps on attends pas la même chose de Bun, et au moins les features sortent :)
Bref en tout cas je ne pense pas que Bun puisse un jour remplacer Node côté serveur car il y fallut plusieurs années pour que l'industrie fasse confiance à Node et que Node se montre suffisamment mature.
Par contre en local il n'y a rien à dire, bosser dans l'écosystème actuel c'est juste HORRIBLE entre les bundler, les builders, les compilers et les fichiers de config de la mort j'étais à la limite de craquer et heureusement Bun vient régler tout ça.
Pas de tsconfig.json, pas de webpack.config.js, pas de ts-node, pas de jest.
It just works ©
En plus bonus: c'est instantané de lancer un script ou de run +100 tests unitaires
Bun est sorti en version 1.0 et ça s'annonce très prometteur.
Finit les prises de tête de l'écosystème Node.js, ça règle tous les problèmes de toolchain de run Typescript, de build en tout genre, de test runner, de module mjs/esm, de require vs import, de package manager en fournissant un seul outil qui just works
Même pas besoin de "risquer" une utilisation en prod, juste le fait de l'utiliser comme toolchain backend fait gagner en productivité.
Très bon article qui récapitule l'utilisation des streams avec l'API fetch incluse dans Node.js 18.
Un système de restriction des permissions est actuellement en cours d'ajout à Node.js.
Ce système permet de restreindre les possibilités du programme d'agir sur le système, notamment:
- système de fichier en lecture/ecriture
- exécuter de nouveaux programmes
- démarrer un worker_thread Node.js
C'est le même système utilisé par Deno pour augmenter la sécurité des applications lancés avec le runtime.
Un article sur l'écriture de module Ecmascript (.mjs) pour une utilisation par Node.js et le browser avec l'utilisation de TypeScript.
Un article intéressant sur les avantages de Deno.
Il y a de nombreux avantages en DX, notamment le support Typescript directement par Deno mais surtout je découvre un avantage non négligeable en terme de sécurité de la supply chain.
Les scripts (comme les entrées de scripts dans le package.json en Node.js) de Deno sont lancés dans un shell isolé spécial (deno_task_shell) et n'ont accès qu'a leur input, ce qui les empêche d'aller farfouiller sur le système (ce genre de truc https://arstechnica.com/information-technology/2022/03/sabotage-code-added-to-popular-npm-package-wiped-files-in-russia-and-belarus/)
L'approche des dépendances via URL est aussi intéressante, on est capable de charger du code depuis une URL tout en respectant des versions, des checksum, etc.
Un serveur FTP entièrement en Node.js.
Il est très simple d'utilisation et très pratique car il abstrait le filesystem. Il est donc possible de lui fournir une classe qui fait autre chose qu'écrire et lire sur le disque.
Par exemple, il est possible de surcharger les méthodes pour écrire et lire dans un bucket S3.
C'est parfait pour s'interfacer avec tous les vieux systèmes qui communiquent encore via FTP.
Je l'utilise en tant que gateway FTP -> HTTP: les fichiers uploadés sont envoyés sur une route d'API
Une explication très clair du fonctionnement des executions asynchrones avec Node.js.
La plupart des opérations de type I/O (lire un fichier, faire une requête http, etc) sont réalisées en parallèle du reste du code dans une pool de thread gérée par la libuv.
Cela permet de ne pas bloquer le thread principal en attendant le retour d'une requête HTTP (qui est très long comparé à executer du code ou récupérer une donnée en RAM)
(Merci Ludo pour le partage)
Un repo Github ou j'ai rassemblé pas mal de ressources à propos du fonctionnement des moteurs Javascript (principalement v8)
C'est toujours bien de comprendre comment est executé le code que l'on écrit, pour le debuguer plus efficacement mais aussi pour l'optimiser quand on en a besoin !
Au programme:
- Hidden Classes
- Inline Cache
- Closures
- Function Polymorphisme et Mégamorphisme
- Interpreteur et Compilateur spéculatif
- Micro Benchmark
Certains articles sont assez complexes mais en règle général ça reste abordable.
Un système de queing entièrement basé sur Redis.
Ils proposent toutes les fonctionnalités dont on a besoin:
- multi-queue producers et consumers
- garantie du delivery unique
- expiration des messages
- rate limiting
Les bons conseils pour créer une image de prod avec Node.js.
En bref:
- Utilisez une version LTS avec Debian slim pour réduire la surface d'attaque
- Ne faites pas de
npm installmaisnpm cipour utiliser un ensemble de dépendances stable - Évitez les images alpines car des problèmes peuvent apparaître à ce musl (substitut de la libc)
C'est toujours bien de voir émerger d'autres runtime car cela amène de nouvelles idées et concepts.
Par contre il ne faut pas se voiler la face, il y a très peu de chances que Deno ou Bun puissent remplacer Node.js.
L'industrie a mis des années avant de faire confiance à Node.js et aujourd'hui je vois difficilement les entreprises se tourner vers un nouveau runtime simplement pour des histoires de design ou quelques % de perfs en plus sachant que le coût d'adoption à l'échelle industriel est très élevé.
Pino est vraiment un super logger, en plus de ses excellentes performances, il permet de
- cacher automatiquement des valeurs dans les objets (comme les jeton d'authentification par exemple)
- créer des sous logger par module
- écrire les logs dans des destinations différentes en fonction des niveaux
Les log sont très souvent une partie critique de l'application car écrire des une sortie est assez consommateur (chez Kuzzle, on s'est rendu compte que nos access log ralentissaient le backend outre mesure.
Il faut aussi faire attention à ce que l'on veut loguer et trouver un équilibre sur la quantité car on peut facilement remplir des tera octets de logs.
Dans l'idéal, il faut construire un système permettant de changer dynamiquement le niveau de log pour activer le mode debug lorsqu'on en a besoin, et l'arrêter ensuite.
Un exemple d'utilisation des Protocol Buffers en Node.js.
L'exemple utilise l'excellente lib Protobuf.js qu'on utilise aussi dans le coeur de Kuzzle pour la communication entre les noeuds du cluster ;-)
J'en parlait ici aussi https://links.aschen.tech/shaare/R6dzhw
Deno annoncent quelques changements avec notamment le support des packages JS en provenance de NPM!
Ils annoncent aussi qu'ils souhaitent être le moteur JS le plus rapide.
Je ne serais pas surpris que cela soit poussé par la sortie de Bun.js qui a de très bonnes performances, supporte le typescript et les packages NPM
Un excellent tutoriel sur les Workers Thread en Node.js pour faire du multi-threading.
Digital Ocean font toujours du très bon contenu je trouve 👍
On commence à voir des tests des performances de Bun par rapport à Node.js.
Pour l'instant il manque encore trop de compatibilité à Bun avec les lib Node.js pour pouvoir aller très loin (pas de child_process) par exemple.
Dans cet article, l'auteur note un gain sensible de performances avec Bun.
Excellent guide dont je recommande la lecture à tout développeur Node.js ;-)
Mon top: