Introduction

Depuis maintenant plusieurs années, des entreprises de toutes tailles adoptent de plus en plus NodeJS dans leur processus de modernisation. La volonté de se diriger sur une architecture micro-services augmentant considérablement le nombre d’instances d’applications à déployer, et donc la charge à faire porter sur le SI, NodeJS est le candidat idéal car extrêmement léger à exécuter, et offrant des performances redoutables sur ses concurrents lorsqu’il s’agit d’effectuer des traitements asynchrones, comme des manipulations de base de données ou encore des appels à d’autres services, base de l’architecture orientée micro-services tant convoitée.

Cependant, NodeJS ne vient pas sans son barda de défauts. Les plus connus et les plus cités sont :

  • La gestion de dépendances est lourde, il est aisé en NodeJS d’avoir dans un projet avec une dépendance sur une version d’un paquet, et d’avoir également une autre dépendance qui dépend de ce paquet mais dans une autre version que celle dont nous avons besoin
  • Une API qui n’assure pas toujours la compatibilité avec les anciennes versions lors d’évolutions
  • Une librairie de packages tellement grande, proposant des paquets parfois peu maintenus qui peuvent mettre en péril la maintenabilité d’une application
  • Les applications NodeJS ont tous les droits, aucune limitation de permissions n’est appliquée par défaut. On peut toujours les sécuriser avec des outils externes, mais cela demande du travail supplémentaire

 

Deno et ses avantages sur NodeJS

Deno est un runtime Javascript et Typescript nouvelle génération, le successeur promis de NodeJS. Initié par le créateur de NodeJS il y a maintenant presque deux ans, et en développement très intensif depuis, il nous promet de résoudre une grande partie des problèmes que posait NodeJS.

 

Le premier problème, probablement le plus grand, est celui des dépendances. Dans un projet NodeJS, on avait un package.json, définissant l’ensemble des modules nécessaires à lancer notre application. NPM (pour Node Package Manager), nous permettait la gestion et la récupération de ces dépendances avant de lancer notre application. Le résultat ? Un dossier node_modules de souvent plusieurs centaines de Mégas pour quelques Kilos de code applicatif….

Deno propose une solution simple au problème. Le premier acte est de supprimer le dossier node_modules, ainsi que le package.json. Les dépendances sont désormais gérées directement dans les fichiers de code, sous forme d’imports, récupérées par Deno au moment du lancement de l’application, et sont stockées, versionnées, en cache, indéfiniment. Le résultat est la possibilité pour une application de dépendre de plusieurs versions d’un module sans problème, ainsi que la réduction considérable du poids de votre environnement de développement JS sur votre poste.

 

Le deuxième problème, celui de la sécurité. Le runtime NodeJS n’embarque pas de système de vérification de permissions sur les applications. Si je lance un fichier JS qui a besoin de faire des modifications sur mon disque dur, je n’ai rien de plus à faire qu’à le lancer. Pareil pour le réseau, et toutes les ressources de l’hôte. Le problème est rapidement identifiable, et même si les systèmes modernes présentent des outils de sécurisation avancée (SELinux par exemple), cela reste à configurer pour chaque application, un travail monstrueux pour une entreprise.

Deno quant à lui propose un système de sécurisation moderne basé sur une autorisation explicite de l’application à faire des actions. Vous voulez lancer une application qui a besoin d’accéder au disque dur ? Au réseau ? Voire même à une interface réseau et/ou un port particulier ? Vous devrez préciser les autorisations de votre application au moment de son lancement avec un ensemble de paramètres –allow-xxxx dans la commande de lancement.

 

Le troisième problème est celui de la compatibilité avec les versions antérieures de NodeJS. En effet, la librairie standard livrée avec NodeJS étant sujette à de nombreuses modifications, il arrivait parfois que vous souhaitiez migrer votre application sur la dernière version de NodeJS afin de profiter des dernières nouveautés, mais que votre application refuse de fonctionner correctement sur cette nouvelle version. Vous deviez alors entamer des travaux de modernisation de l’application, travaux parfois coûteux.

Deno propose une librairie standard très étayée, nous venant tout droit de la librairie standard de Go. Cette librairie, ainsi que le runtime de Deno, devrait être plus stable et assurer une meilleure rétrocompatibilité que son homologue de NodeJS.

 

Pour le petit bonus, Deno supporte nativement Typescript, permettant ainsi aux développeurs friands de Typescript, comme moi, de ne plus avoir à systématiquement rajouter à son application les paquets inerrants au développement Typescript, ainsi qu’une meilleure intégration native avec les outils de testing / IDE.

 

Deno et NodeJS dans l’avenir

Deno est un runtime encore jeune, trop jeune pour que les entreprises l’adoptent en masse. Est-ce que son noyau est vraiment stable ? Va-t-il tenir ses promesses ? Va-t-il revenir en arrière comme les débuts de NodeJS, exemple fait des Promises, introduites plus tard ?

Autant de questions qui poussent les entreprises à, aujourd’hui du moins, ne pas s’intéresser à ce nouveau Runtime.

Je suis pourtant convaincu que Deno remplacera NodeJS un jour. Avec un runtime plus stable, plus performant, une gestion de dépendances mieux ficelée, Deno a tout pour plaire aux développeurs autant qu’aux entreprises. Laissons-lui le temps de conquérir le cœur de plus de développeurs, de faire son chemin de l’œuf au serveur de production.