Découverte de Deno, le futur successeur de Node.js

Table des matières

Découverte de Deno, le futur successeur de Node.js

Le 13 mai 2020, Ryan Dahl le concepteur de Node.js a annoncé la sortie en version 1.0 de Deno après 2 ans de développement. J’attendais avec impatience la release stable pour pouvoir le tester et me faire un avis sur ce nouveau-né très prometteur. Et c’est chose faîte, je me suis amusé un peu avec un soir et je peux vous faire un petit retour sur lui.

Comment Deno est-il né ?

Même si Deno ça donne Node à l’envers, ce n’est pas juste un simple fork de Node.js comme ça l’a été au départ entre MySQL et MariaDB. Alors au final, pourquoi le fondateur de Node.js a-t-il voulu créer Deno ?

Pour répondre et pallier aux problèmes de conception de Node.js tout simplement. Pour rappel, Node.js a été créé en 2009 et l’on produit des fichiers JS pour nos applications. Le JavaScript depuis 2009 a considérablement changé et évolué surtout en 2015 avec l’arrivée d’ES6 qui a révolutionné JavaScript. Et il y a eu entre temps l’arrivée de Typescript qui rendu plus qualitatif la production de code JavaScript.

Bref, tant de choses qui ont poussé Ryan Dahl dans l’optique de créer un nouveau Node.js tout neuf. En fait, c’est plus profond que cela, car au fil du temps Ryan Dahl a partagé 3 problèmes de conceptions majeures :

• un système de modules mal conçu, avec une distribution centralisée
• un grand nombre d’API héritées qui doivent être prises en charge
• un manque de sécurité

Ryan Dahl promet que Deno va résoudre ses 3 problèmes.

Quelques informations sur Deno

Pour information, Deno a été écrit en Rust, mais surtout il est construit sur le moteur JavaScript V8. Pour rappel, V8 a notamment introduit la compilation directe du code JavaScript en code machine natif avant de l’exécuter. Car avant, le navigateur devait en premier lieu l’interpréter ce qui augmentait considérablement le temps d’exécution.

Deno est un nouveau runtime pour exécuter JavaScript et TypeScript en dehors du navigateur (comme Node.js). D’ailleurs sur ce point, je ne comprends pas pourquoi ils ont laissé la possibilité de pouvoir produire du JavaScript classique (entendez par là les fichiers en .js). Je trouve qu’il aurait dû se maintenir à uniquement Typescript et de pas donner la possibilité des 2.

Je me suis amusé à le tester quelques heures pour créer une REST API et il est vrai que Deno répond à ses 3 problématiques et je vais vous expliquer en détail pourquoi.

Adieu le gestionnaire NPM

J’ai une mauvaise nouvelle pour vous si vous adorez le gestionnaire de package de NPM parce que Deno ne l’utilise pas. Son mot d’ordre c’est d’avoir des modules de qualités et de manière décentralisée.

Cela veut dire que techniquement un module Deno peut provenir de n’importe où. Ils peuvent être hébergés sur Github ou sur toute autre chose. Leur utilisation est semblable à ce qui se fait en Typescript avec le mot-clé « import », mais au lieu de spécifier un nom de package comme sur npm vous allez devoir spécifier une URL où se trouve le module (si vous avez fait du Go s’est sensiblement la même chose).

Voici un exemple d’import Deno pour obtenir un middleware de serveur HTTP incluant un router :

import { Application } from ‘https://deno.land/x/oak/mod.ts’

Cela implique donc que le dossier de votre projet ne contiendra aucun dossier avec des modules téléchargés dedans contrairement aux fameux node_modules. En fait c’est Deno qui va se charger de télécharger pour mettre en cache le module de manière centralisée sur votre ordinateur. 3 avantages à cela :

• Vous n’avez qu’à les mettre en cache une fois pour pouvoir les utiliser par la suite sans Internet
• La centralisation des modules à un seul endroit sur votre ordinateur permet de gagner de l’espace disque et donc en efficacité
• Les modules sont sous forme de code uniquement. Il n’y a pas de séquence de build et vous ne téléchargez que le code pour l’utiliser dans votre projet; c’est donc beaucoup plus léger.

Actuellement sur le site de Deno, il existe 2 ensembles de modules : les modules standards et les modules tiers. Vous l’aurez compris les modules standards sont gérés et développés par l’équipe de Deno et les modules tiers par la communauté.

Si jamais vous voulez développer un module tiers pour Deno, il faudra respecter 2 choses primordiales : respecter les standards de qualité de Deno et demander un ajout de votre module ici.

Une meilleure sécurité pour mieux paramétrer son application

C’est pour moi le deuxième point le plus important de Deno : la sécurité de votre application. Par défaut, Deno n’a accès à rien sur votre machine. C’est à vous de spécifier ce dont vous avez accès par rapport au module que vous souhaitez utiliser. Si vous oubliez d’activer une sécurité pour l’un de vos imports, Deno vous le dira via le CLI :

Ce qui est pas mal en plus c’est que vous pouvez préciser la configuration des flags. Vous pouvez donner l’accès en lecture qu’à un dossier précis par exemple. Pareil pour l’écriture vous pouvez filtrer l’accessibilité à un domaine.

Bref, vous pouvez configurer aux petits oignons votre application pour qu’elle soit la plus secure possible et vous éviter des soucis par la même occasion.

Donc même si l’option existe, par pitié, n’utilisez pas le flag —allow-all car ce serait contre-productif et ça ne vous rendra pas service.

Il faut quand même noter un point un peu casse-pied dans ce mécanisme. C’est la ligne de commande à rallonge avec tous les flags qui seraient à améliorer.

Je vous donne un exemple simple : j’ai réalisé une petite API Rest pour tester la bête. J’ai juste utilisé le middleware pour avoir un serveur HTTP avec un router. Je géré mes bières (fallait bien trouver un thème :-)) dans un bête tableau pour commencer.

Mon application tournait avec cette commande et ces flags :

deno run --allow-env --allow-net app.ts

Bon je me suis dit on va peut être tester un module tiers et j’ai donc choisi le module MongoDB pour pouvoir vraiment stocker les données. J’ai fait une pierre deux coups comme ça !

J’ai donc utilisé cette ligne pour utiliser le module :

import { init, MongoClient } from "https://deno.land/x/mongo@v0.6.0/mod.ts";

Sauf pour MongoDB, il faut ouvrir et paramétrer pas mal de sécurité. Ce qui donne la ligne suivante pour faire tourner de nouveau l’application :

deno run --allow-env --allow-net --unstable --allow-read --allow-write --allow-plugin app.ts

Vous avez remarqué ?  On est passé de 2 à 5 flags juste pour un module. Je trouve l’utilisation un peu lourde, car c’est comme utiliser docker en ligne de commande si vous connaissez. C’est pas très lisible et pas très gérable tout cela !

Ce point doit être selon moi amélioré et je ne suis pas le seul dans ce cas à penser ça puisqu’il y a déjà des propositions en passant par des fichiers de config.

Ce que je pense de Deno

Après quelques heures d’utilisations, Deno respecte bien ce qu’a promis son créateur. Je le trouve très léger et performant pour ce que j’ai pu faire avec. Bon c’est vrai ce n’est pas grand-chose, mais quand même.

J’avais peur que l’on ne puisse pas faire grand-chose même en version 1.0 vu que le projet ne veut plus de NPM. Mais je me rends compte que les modules standards et tiers sont déjà largement suffisants pour faire pas mal de choses.

Et ce qui est plaisant, c’est que les modules sont légers et ne prennent pas de places. On ne se retrouve pas avec un dossier énorme de modules dans son projet.

Je n’ai pas creusé le sujet pour le moment, mais le fait d’utiliser des imports qui pointent sur des URL ne vous permettra pas d’avoir nativement dans votre IDE une autocomplétion comme on l’aime si bien. Mais je pense qu’il est possible de pallier ça en ajoutant des extensions dans son IDE.

D’ailleurs si vous utilisez VS Code, Deno recommande d’installer une extension pour supporter l’autocomplétion de Deno.

Si on connaît Node.js, Express et Typescript, on n’est pas perdu et on prend vite ses marques. Ce que je n’aime pas c’est de pouvoir produire des fichiers Typescript et Javascript au sein du même projet. Ils auraient dû selon mon avis imposer Typescript et ne pas permettre le JavaScript comme on l’a connu.

Peut-on déjà l’utiliser pour une application de production ?

Je pense que pour un petit projet qui ne présente pas beaucoup d’interaction et qui est peu complexe peu faire l’affaire. Il est assuré que c’est le tout début de ce runtime et qu’il va fortement évoluer dans l’avenir pour enrichir son panel de fonctionnalités.

Réalisant bien souvent des projets de très haute envergure, je ne pense pas que je l’utiliserais pour le moment sur un nouveau projet, mais ce qui est sûr c’est que ce sera mon alternative à Node.js quand le projet aura mûri.

En cadeau, je vous mets le lien de mon dépôt Github où j’ai fait mes tests avec Deno histoire de voir à quoi ça ressemble ou de vous inspirer pour faire vos propres tests : https://github.com/GaetanCottrez/deno-rest-api-beer.

Bien entendu, vous devrez tout d’abord installer Deno pour utiliser mon projet