The Art of Node - Une introduction à Node.js

NodeSchool.io est une série d'ateliers open source et gratuits qui vous enseigneront les principes de Node.js, et plus encore pour les curieux !

Learn You The Node.js est le cours introductif aux ateliers NodeSchool.io. Il met en scène les principaux cas d'utilisation de Node.js. Il est conçu pour être utilisé directement en ligne de commande.

Installez-le avec npm :

# install
npm install learnyouNode -g

# start the menu
learnyouNode

Voilà le sujet le plus important si vous voulez comprendre comment utiliser Node. On retrouve les callbacks à peu près partout dans Node. Ils n'ont cependant pas été inventés par Node, ils font simplement partie intégrante de JavaScript.

Les Callbacks sont des fonctions qui s'exécutent de manière asynchrone ou plus tard dans le temps. Au lieu de lire le code de haut en bas de manière procédurale, les programmes asynchrones peuvent exécuter différentes fonctions à différents moments. Cet ordre sera défini en fonction de l'ordre et de la vitesse des précédents appels, comme les requêtes HTTP ou bien encore la lecture du système de fichiers.

Cette différence peut entraîner des confusions, car déterminer si une fonction est asynchrone ou non dépend beaucoup de son contexte. Voici un exemple synchrone, ce qui signifie que vous pouvez lire ce code de haut en bas comme un livre :

var myNumber = 1
function addOne() { myNumber++ } // define the function
addOne() // run the function
console.log(myNumber) // logs out 2

Ce code définit une fonction, puis appelle cette fonction, sans attendre quoi que ce soit. Quand la fonction est appelée, elle ajoute immédiatement 1 au nombre. On peut donc s'attendre à ce qu'après l'appel de cette fonction, le nombre soit égal à 2. De manière assez basique donc, le code synchrone s'exécute de haut en bas.

Node en revanche, utilise essentiellement du code asynchrone. Utilisons Node pour lire notre nombre depuis un fichier appelé number.txt :

var fs = require('fs') // require is a special function provided by Node
var myNumber = undefined // we don't know what the number is yet since it is stored in a file

function addOne() {
  fs.readFile('number.txt', function doneReading(err, fileContents) {
    myNumber = parseInt(fileContents)
    myNumber++
  })
}

addOne()

console.log(myNumber) // logs out undefined -- this line gets run before readFile is done

Pourquoi obtenons-nous undefined quand nous affichons le chiffre cette fois-ci ? Dans ce code, nous utilisons la méthode fs.readFile, qui est une méthode asynchrone. Tout ce qui doit parler à un disque dur ou à un réseau aura tendance à être asynchrone. Si leur objectif est simplement d'accéder à la mémoire, ou travailler avec le processeur, alors ils seront synchrones. La raison est que l'I/O est effroyablement lent ! En guise d'illustration, dites-vous que parler avec un disque dur est environ 100 000 fois plus lent qu'une communication avec la mémoire(la RAM).

Quand nous lançons ce programme, toutes ses fonctions sont immédiatement définies, mais elles n'ont pas besoin de s'exécuter immédiatement. C'est un élément fondamental à comprendre en programmation asynchrone. Quand addOne est appelé, il démarre readFile et enchaîne avec le prochain élément prêt à être exécuté. S'il n'y a rien dans la file d'attente, Node attendra les opérations fs/réseau en attente pour terminer, ou il s'arrêtera simplement de tourner et sortira sur la ligne de commande.

Quand readFile aura terminé de lire le fichier (cela peut prendre entre quelques millisecondes et plusieurs minutes, en fonction de la vitesse du disque dur), il lancera la fonction doneReading, puis lui donnera une erreur (s'il y en a une) ainsi que le contenu du fichier.

La raison pour laquelle nous obtenons undefined ci-dessus est qu'il n'existe aucune logique dans notre code pour dire à notre console.log d'attendre que le readFile ait terminé avant de sortir notre chiffre.

Si vous avez du code que vous voulez pouvoir exécuter encore et encore, ou simplement plus tard, la première étape consiste à encapsuler ce code dans une fonction. Ensuite, vous pouvez indiquer à votre fonction le moment où elle devra l'exécuter. Bien évidemment, donner des noms descriptifs et verbeux à vos fonctions aidera grandement.

Les Callbacks ne sont que des fonctions qui s'exécutent plus tard. La clef pour comprendre les Callbacks est de réaliser que vous ne savez pas quand une opération asynchrone sera terminée, mais vous savez où cette opération doit se compléter – la dernière ligne de votre fonction asynchrone ! L'ordre haut en bas de déclaration de vos Callbacks n'a pas d'importance, seule l'encapsulation logique compte. Commencez par découper votre code en fonctions, puis utilisez vos callbacks pour déclarer qu'une fonction requiert qu'une autre se termine.

La méthode fs.readFile fournie par Node est asynchrone et il se trouve qu'elle prend beaucoup de temps pour se terminer. Mettez-vous à sa place : elle doit aller interroger l'OS, qui à son tour doit se renseigner auprès du file système, qui vit sur le disque dur, qui n’est pas forcément lancé à des milliers de tours par minute. Ensuite il doit utiliser un laser pour lire une donnée, puis la renvoyer à travers toutes les strates successives de votre programme JavaScript. Vous donnez donc à readFile une fonction (aussi appelé Callback) qu'il appellera une fois qu'il aura récupéré les données de votre système de fichiers. Il placera les données qu'il a récupérées dans une variable JavaScript et appellera votre Callback avec cette variable. Dans ce cas, la variable est nommée fileContents, car elle a pour valeur le contenu du fichier qui a été lu.

Reprenez l'exemple du restaurant cité au début de ce tutoriel. Très souvent, vous trouverez dans les restaurants des numéros à poser sur votre table pendant que vous patientez. Ces numéros sont comme des Callbacks. Ils indiquent au serveur ce qu'il doit faire une fois que votre sandwich est prêt.

Plaçons maintenant notre console.log dans une fonction et passons-la en Callback.

var fs = require('fs')
var myNumber = undefined

function addOne(callback) {
  fs.readFile('number.txt', function doneReading(err, fileContents) {
    myNumber = parseInt(fileContents)
    myNumber++
    callback()
  })
}

function logMyNumber() {
  console.log(myNumber)
}

addOne(logMyNumber)

La fonction logMyNumber peut désormais être passée en argument qui deviendra la variable de Callback dans la fonction addOne. Une fois que readFile en a terminé, la variable Callback sera invoquée (callback()). Seules les fonctions peuvent être invoquées, donc si vous passez n'importe quoi d'autre qu'une fonction, il en résultera une erreur.

Quand une fonction est invoquée en JavaScript, le code qu'elle renferme est immédiatement exécuté. Dans notre cas, notre console log s'exécutera puisque callback est logMyNumber. Rappelez-vous, le simple fait de define une fonction ne signifie pas qu'elle s'exécutera. Pour ce faire, vous devez invoke une fonction.

Pour aller encore plus loin avec cet exemple, voici une liste chronologique des évènements qui se produisent à l’exécution de ce code :

1. Le code est parsé, ce qui signifie qu'une quelconque erreur syntaxique casserait le programme. Durant cette phase initiale, il y a quatre choses qui sont définies: fs, myNumber, addOne, et logMyNumber. Notez qu'elles sont simplement définies. Aucune fonction n'a encore été invoquée pour le moment ;
2. Quand la dernière ligne de notre programme est exécutée addOne est invoquée, puis est passée dans la fonction logMyNumber comme « callback », ce qui est bien ce que nous demandons quand addOne est terminée. Cela entraîne immédiatement le démarrage de la fonction asynchrone fs.readFile. Cette partie du programme prend un peu de temps à se terminer ;
3. Puisqu'il n'a rien à faire, Node patiente pendant que readFile se termine. S'il y avait une quelconque autre tâche à réaliser, Node serait disponible pour faire le boulot ;
4. readFile se termine et appelle son callback, doneReading, qui à son tour incrémente le nombre et invoque immédiatement la fonction qu'addOne a passée, logMyNumber (son Callback).

La chose la plus troublante quand on programme avec des Callbacks est probablement le fait que les fonctions sont de simples objets, encapsulables dans des variables et que l'on peut passer n'importe où avec des noms différents. Affecter des noms simples et descriptifs à vos variables est primordial pour rendre votre code lisible pour les autres comme pour vous-même. D'une manière générale, si vous voyez une variable comme callback ou cb, vous pouvez partir du principe qu'il s'agit d'une fonction.

Vous avez peut-être entendu les termes de « evented programming » (programmation évènementielle) ou « event loop » (boucle d'évènements). Ils réfèrent à la manière dont readFile est implémentée. Node dispatche d'abord les opérations readFile puis attend que readFile envoie un évènement qu'il a clôturé. Pendant qu'il patiente, Node peut tranquillement s'affairer ailleurs. Pour s'y retrouver, Node maintient une liste de tâches qui ont été dispatchées, mais qui n'ont pas encore reçu de feedback, et boucle dessus indéfiniment jusqu'à ce que l'une d'entre elles soit terminée. Lorsque c’est chose faite, Node invoque les éventuels Callbacks qui lui sont rattachés.

Voilà une version de l'exemple précédent en pseudo-code :

function addOne(thenRunThisFunction) {
  waitAMinuteAsync(function waitedAMinute() {
    thenRunThisFunction()
  })
}

addOne(function thisGetsRunAfterAddOneFinishes() {})

Imaginez que vous ayez trois fonctions asynchrones a, b et c. Chacune d'elles prend environ une minute à être complétée puis lance un Callback (qui se voit passé en premier argument). Si vous vouliez dire à Node : « lance a, puis b une fois que a est terminé, puis c une fois que b est terminé », cela ressemblerait à :

a(function() {
  b(function() {
    c()
  })
})

Quand ce code est exécuté, a démarrera immédiatement, puis une minute plus tard il appellera b, qui une minute plus tard lancera c. Au bout de trois minutes, Node s'arrêtera puisqu'il n'y aura plus rien à faire. Bien évidemment, il existe des méthodes plus élégantes pour écrire le code ci-dessus, mais le but est de montrer que si vous avez du code qui doit attendre un autre code asynchrone pour s'exécuter, alors il faut exprimer cette dépendance en disposant votre code dans une fonction qui sera alors passée comme Callback.

Le design de Node requiert un mode de pensée non linéaire. Considérez donc cette liste d'opérations :

• lire un fichier ;
• traiter ce fichier.

Si vous transformiez cela en pseudo-code vous obtiendriez :

var file = readFile()
processFile(file)

Ce type de code non linéaire (étape par étape, dans l'ordre) n'est pas la manière dont Node fonctionne. Si ce code devait être exécuté, alors readFile et processFile devraient être lancées au même moment. Cela n'aurait aucun sens puisque readFile mettra du temps à se terminer. À la place, vous devez signifier que processFile dépend de readFile. C'est exactement à cela que servent les Callbacks ! Et parce que JavaScript fonctionne ainsi, vous pourrez écrire cette dépendance de plusieurs manières :

var fs = require('fs')
fs.readFile('movie.mp4', finishedReading)

function finishedReading(error, movieData) {
  if (error) return console.error(error)
  // do something with the movieData
}

Mais vous pourriez aussi structurer votre code de cette façon et il fonctionnerait toujours :

var fs = require('fs')

function finishedReading(error, movieData) {
  if (error) return console.error(error)
  // do something with the movieData
}

fs.readFile('movie.mp4', finishedReading)

Ou même comme ceci :

var fs = require('fs')

fs.readFile('movie.mp4', function finishedReading(error, movieData) {
  if (error) return console.error(error)
  // do something with the movieData
})

stream-handbook est un guide, similaire à celui-ci, qui contient des références sur absolument tout ce que vous pouvez avoir besoin de savoir sur les flux.

Imaginez que vous souhaitez convertir un fichier PDF en TXT. Le meilleur moyen est de commencer par chercher npm search pdf :

Et il y a des tonnes de résultats ! npm est relativement populaire, et vous trouverez généralement de multiples solutions potentielles pour vos besoins. Si vous filtrez suffisamment bien vos résultats, vous devriez vous retrouver avec ceci :

• hummus - manipulateur pdf c++ ;
• mimeograph - API d’agglomération d'outils (poppler, tesseract, imagemagick etc.) ;
• pdftotextjs - wrapper autour de pdftotext ;
• pdf-text-extract – un autre wrapper autour de pdftotext ;
• pdf-extract - wrapper autour de pdftotext, pdftk, tesseract, ghostscript ;
• pdfutils - wrapper poppler
• scissors – API haut niveau wrapper de pdftk, ghostscript ;
• textract - wrapper pdftotext
• pdfiijs - pdf à index inversé en utilisant textiijs et poppler ;
• pdf2json - pure js pdf vers json.

Beaucoup de ces modules ont des fonctionnalités similaires, mais présentent des API alternatives. Ils requièrent aussi très souvent des dépendances externes comme apt-get install poppler.

Voici une approche pour interpréter ces différents modules :

• pdf2json est le seul rédigé en pur JavaScript, ce qui signifie qu'il est aussi le plus simple à installer, notamment sur des petites configurations comme un Raspberry Pi ou un Windows ou le code natif n'est pas nécessairement multiplateforme ;
• les modules comme mimeograph, hummus et pdf-extract combinent chacun de multiples modules bas niveau pour exposer une API haut niveau ;
• beaucoup de ces modules semblent reposer sur les outils de commande Unix pdftotext/poppler.

Comparons les différences entre pdftotextjs et pdf-text-extract, tous deux étant fondés sur l'utilitaire pdftotext.

Tous deux possèdent :

• des mises à jour récentes ;
• des liens vers des dépôts Github (indispensable !) ;
• des fichiers README ;
• une bonne popularité ;
• une licence libre (tout le monde peut les utiliser librement).

En ne regardant que le package.json et les statistiques du module, il est difficile de se faire une bonne idée du meilleur choix possible. Comparons les fichiers README :

Les deux possèdent des descriptions simples, des instructions d'installation, des badges CI, des exemples clairs pour lancer les tests. Fantastique ! Mais lequel devons-nous utiliser ? Comparons le code :

pdftotextjs contient environ 110 lignes de code, contre 40 pour pdf-text-extract, mais les deux peuvent essentiellement se réduire à cette ligne :

var child = shell.exec('pdftotext ' + self.options.additional.join(' '));

Est-ce que cela en rend un meilleur que l'autre ? Difficile à dire ! Il est indispensable de lire le code pour tirer vos propres conclusions. Si vous trouvez un module qui vous plaît, lancez npm star modulename pour donner votre feedback à npm.

npm diffère de la plupart des gestionnaires de paquets par sa capacité à installer des modules dans des répertoires contenus à l’intérieur de modules déjà existants. Même si vous n'y voyez pas encore d'intérêt, c'est là la clef du succès de npm.

Beaucoup de gestionnaires de paquets installent les choses de manière globale. Par exemple, si vous lancez apt-get install couchdb sur Debian Linux, il essayera d'installer la dernière version stable de CouchDB. Si vous essayez d'installer CouchDB en tant que dépendance d'un autre logiciel, et que ce logiciel nécessite une version antérieure de CouchDB, vous devrez désinstaller la version la plus récente de CouchDB puis installer la version historique. Vous ne pouvez donc pas avoir deux versions de CouchDB en parallèle, car Debian ne sait installer les modules qu'à un endroit.

Et il n'y a pas que Debian qui fait cela. La plupart des gestionnaires de paquets des langages de programmation fonctionnent ainsi. Pour résoudre ce problème, des environnements virtuels ont été développés comme virtualenv pour Python ou bundler pour Ruby. Ceux-ci découpent votre environnement en plusieurs environnements virtuels, un pour chaque projet. Toutefois, à l’intérieur de chacun de ces environnements, tout reste installé de manière globale. Les environnements virtuels n'adressent donc pas une réponse satisfaisante à notre problème et augmentent qui plus est le niveau de complexité de notre installation.

Avec npm, l'installation de modules globaux est contre nature. De la même manière que vous ne devriez pas utiliser de variable globale dans vos programmes JavaScript, vous ne devriez pas installer de modules globaux (à moins que vous ayez besoin d'un module avec un exécutable binaire dans votre PATH global, ce qui est loin d'être systématiquement le cas – nous en reparlerons).

7-2-1. Comment fonctionne require▲

Quand vous faites appel à require('some_module') voilà ce qui se passe dans Node :

1. Si un fichier qui s'appelle some_module.js existe dans le dossier courant, Node le lancera ;
2. Autrement, Node recherchera un dossier nommé Node_modules dans le répertoire en cours, contenant un fichier some_module à l’intérieur ;
3. S’il ne trouve toujours pas, il montera d'un niveau et répétera l'opération 2.

Ce cycle se répétera jusqu'à ce que Node atteigne le dossier root du système de fichiers. À ce moment, il continuera sa recherche dans les répertoires de modules globaux (comme /usr/local/Node_modules sur Mac OS). Enfin, s'il ne trouve toujours rien, il enverra une erreur.

Pour illustrer ceci, voilà un exemple :

Quand le dossier de travail en cours est subsubfolder et que require('foo') est appelé, Node va chercher un dossier subsubsubfolder/Node_modules. Dans le cas présent, sa recherche sera infructueuse, car le répertoire y est nommé par erreur my_modules. Node va donc remonter d'un répertoire et recommencer son opération, ce qui signifie qu'il cherchera alors subfolder_B/Node_modules qui n'existera toujours pas. Enfin, la troisième tentative passera puisque folder/Node_modules existe bel et bien et possède un répertoire nommé foo en son sein. Si foo n'y était pas, Node aurait continué sa recherche jusqu'aux répertoires globaux.

Notez que s'il est appelé depuis subfolder_B, Node ne trouvera jamais subfolder_A/Node_modules, car il ne peut voir folder/Node_modules que dans sa phase de remontée de l'arborescence.

Un des atouts de l'approche de npm est que les modules peuvent installer leurs dépendances à des endroits spécifiques à leur version. Dans ce cas, le module foo est plutôt populaire – il y en a trois copies, chacune à l’intérieur de son dossier parent. Une explication pourrait être que chaque module parent requiert une version différente de foo, par exemple « folder » qui requiert foo@0.0.1, subfolder_A de foo@0.2.1, etc.

Maintenant, voilà ce qui se produit si nous corrigeons notre problème de nom en remplaçant my_modules par son nom valide Node_modules :

Pour tester quel module est véritablement chargé par Node, vous pouvez utiliser require.resolve('some_module') qui vous montrera le chemin d'accès du module que Node trouve dans sa remontée de l'arborescence. require.resolve est particulièrement utile pour vérifier que le module que vous pensez être chargé l'est véritablement – parfois il y aura une autre version du même module qui sera plus proche de votre répertoire de travail actuel.

Maintenant que vous savez trouver un module et le require, vous pouvez écrire vos propres modules.

7-3-1. Le module le plus simple du monde▲

La légèreté des modules de Node est radicale. En voici l'un des plus simples possibles :

 

Sélectionnez

package.json:
{
  "name": "number-one",
  "version": "1.0.0"
}
index.js:
module.exports = 1

Par défaut, Node essaie de lancer module/index.js quand il lit require('module'). Aucun autre nom de fichier ne fonctionnera à moins que vous ne spécifiiez au champ main de package.json de pointer dessus.

Placez les deux fichiers dans un dossier nommé number-one (l'id dans package.json doit matcher un nom de dossier) et vous aurez un module Node fonctionnel.

En appelant la fonction require('number-one') vous retournez la valeur qui est « set » dans module.exports

Un moyen encore plus rapide de créer un module serait de lancer les commandes Shell suivantes :

 

Sélectionnez

mkdir my_module
cd my_module
git init
git remote add git@github.com:yourusername/my_module.git
npm init

La commande npm init créera automatiquement un package.json valide pour vous. Si vous lancez un dépôt git existant, il définira tout aussi automatiquement package.json à l’intérieur.

7-3-2. Ajout de dépendances▲

npm install --save request

{
  "id": "number-one",
  "version": "1.0.0",
  "dependencies": {
    "request": "~2.22.0"
  }
}

npm est victime d'un vice de pensée assez fréquent. Node faisant partie de son nom, il est courant de penser qu'il ne gère que des modules JS côté serveur, ce qui est absolument faux ! npm signifie « Node Packaged Module », c'est-à-dire des modules que Node package pour vous. Ces modules peuvent être n'importe quoi. Ce ne sont que des répertoires ou des fichiers encapsulés dans des fichiers .tar.gz et un fichier nommé package.json qui explicite la version du module ainsi que la liste de toutes ses dépendances (ainsi que leurs propres versions de modules pour que seules les versions connues pour fonctionner avec notre module ne soient installées automatiquement). Les dépendances ne sont que des modules, qui peuvent eux-mêmes avoir des dépendances, et ainsi de suite.

browserify est un utilitaire écrit en Node qui tente de traduire n'importe quel module Node en code lisible par un navigateur. Bien que beaucoup de modules soient compatibles, tous ne le sont pas (les navigateurs ne peuvent par exemple pas héberger un serveur HTTP).

Pour essayer npm en navigateur, vous pouvez utiliser RequireBin, qui est une application que j'ai réalisée et qui tire profit de Browserify-CDN. Elle utilise browserify en interne et renvoie la sortie à travers HTTP (en lieu et place de la ligne de commande communément utilisée par browserify).

Essayez maintenant de mettre ce code dans RequireBin et lancez le bouton de preview :

var reverse = require('ascii-art-reverse')

// makes a visible HTML console
require('console-log').show(true)

var coolbear =
  "    ('-^-/')  \n" +
  "    `o__o' ]  \n" +
  "    (_Y_) _/  \n" +
  "  _..`--'-.`, \n" +
  " (__)_,--(__) \n" +
  "     7:   ; 1 \n" +
  "   _/,`-.-' : \n" +
  "  (_,)-~~(_,) \n"

setInterval(function() { console.log(coolbear) }, 1000)

setTimeout(function() {
  setInterval(function() { console.log(reverse(coolbear)) }, 1000)
}, 500)

Ou testez un exemple plus complexe (vous êtes libre de changer le code pour voir ce qu'il produit) :

Node n'est fondamentalement conçu que pour gérer les I/O à travers le système de fichiers et les réseaux, et laisse les fonctionnalités plus fantaisistes aux modules tiers. Voici quelques exemples de choses qui dépassent le périmètre d'action de Node.

8-1-1. Frameworks Web▲

8-1-2. Syntaxe du langage▲

8-1-3. Niveau d'abstraction du langage▲

fs.readFile('movie.mp4')
  .then(function(data) {
    // do stuff with data
  })
  .error(function(error) {
    // handle error
  })

fs.readFile('movie.mp4', function(err, data) {
  // handle error, do stuff with data
})

8-1-4. Threads/fibers/non-event-based concurrency solutions▲