Node.js

Apprendre par la pratique

Thomas Parisot

• Éditeur: Eyrolles
• Année: 2018
• Imprimer l'ISBN: 9782212139938
• ISBN de l'eBook: 9782212442731
• Édition: 1
• Sujet: Informatique
• Sujet: Programmation en JavaScript

Plus de 500 exemples pour apprendre en pratiquant

La plate-forme Node.js est passée du statut d'OVNI à celui d'incontournable. En 2018, elle fait fonctionner des applications web, de l'outillage front-end, de la distribution de fichiers pair-à-pair, des objets connectés et la NASA l'utilise même pour analyser les données télémétriques de ses sondes spatiales.

L'intention de cet ouvrage est d'être votre base de départ pour comprendre ce qu'il se passe dans cet écosystème en perpétuel mouvement. Il devrait vous permettre de faire des choix techniques durables et de vous rendre opérationnelle sur LA plate-forme JavaScript, le langage le plus populaire du monde selon GitHub.

Nous allons parcourir ensemble l'écosystème Node.js en partant de son historique et de sa gouvernance jusqu'au déploiement en continu de nos applications. Nous (re)partirons sur des bases solides de JavaScript pour ensuite découvrir petit à petit le potentiel des modules Node.js. Ces connaissances sont les fondations pour explorer la conception, le développement et le déploiement d'applications web, d'utilitaires en lignes de commandes et d'applications front-end modernes. Une sélection variée de modules complémentaires vous permettra d'y voir plus clair parmi les centaines de milliers de contributions de la communauté Node.js.

Plusieurs centaines d'exemples ponctuent l'ouvrage pour mieux cerner les concepts et leurs résultats. Ils sont exécutables dans un terminal grâce à un module npm ou dans un navigateur web grâce à une surcouche interactive.

À qui cet ouvrage s'adresse-t-il ?

• Aux développeurs et développeuses qui veulent se reconvertir depuis un autre langage de programmation comme Péri, PHP ou Ruby
• Aux développeurs et développeuses qui cherchent à tirer parti de l'outillage npm front-end
• À toute personne autodidacte et désireuse de renforcer ses compétences en programmation web

1

Histoire, écosystème et gouvernance

Faisons le point sur ce qu’est Node pour mieux comprendre les discussions qui animent la communauté et d’où vient cette plate-forme qui fait tant parler d’elle.

•Bref historique

•Les raisons du succès

•Pourquoi éviter Node

•Pourquoi choisir Node

•L’écosystème des acteurs

•Gouvernance du projet

Node.js est-il un langage de programmation ? Node.js est-il un framework JavaScript ? Qu’en restera-t-il une fois la frénésie retombée ? Ce chapitre permet de comprendre pourquoi Node a émergé et comment. Surtout, il vous permettra de comprendre les choix techniques à l’origine des fondations de Node et ce que l’utiliser peut vous apporter, que ce soit dans un contexte personnel ou professionnel.

Node.js : un environnement d’exécution JavaScript

Node.js n’est pas un langage de programmation. Ce n’est pas non plus un framework JavaScript. Node.js est un environnement d’exécution JavaScript.

La différence entre ces trois désignations peut sembler subtile, futile voire inutile, mais le terme « environnement » est la véritable nature de Node.

Exécuter du JavaScript côté serveur n’est pas une révolution. Netscape Enterprise Server s’y est déjà essayé au début des années 1990, juste après son introduction dans le navigateur web Netscape Navigator.

En 1997, la société Netscape s’est attelée à créer Rhino (https://www.mozilla.org/rhino/), un environnement d’exécution JavaScript tournant sous Java et disponible sous licence libre. C’était un des projets liés à la réécriture de Netscape Navigator en Java. Si la société a depuis fermé ses portes, Rhino a entraîné l’émergence de projets utiles aux développeurs web.

Entre-temps, le langage JavaScript évolue, le Web 2.0 émerge des cendres de la première bulle Internet et d’autres initiatives voient le jour dans les années 2000 comme APE (Ajax Push Engine, http://ape-project.org/). Elles mettent également en œuvre JavaScript côté serveur. JavaScript était surtout un choix logique de partage de code entre client et serveur pour Comet, le précurseur des WebSockets.

GLOSSAIRE Comet

Comet est un terme regroupant les différentes tentatives techniques permettant à un serveur web d’envoyer des données à un client sans que celui-ci ne les ait demandées initialement.

Parmi ces techniques, on retrouve le long polling, consistant à conserver une connexion Ajax ouverte pendant la durée de vie d’une page web.

GLOSSAIRE WebSockets

WebSockets est un protocole basé sur TCP.

Il maintient une connexion HTTP active entre un client et un serveur et y fait transiter les données de manière bidirectionnelle.

Ce protocole sera probablement rendu obsolète par HTTP/2, le successeur de HTTP/1.1. HTTP/2 a été lancé par Google sous le nom de protocole SPDY (prononcer speedy).

Cas d’utilisation modernes de Rhino

Rhino est toujours utile dès qu’un projet Java implique du JavaScript.

Google l’utilise comme environnement d’exécution de ses https://gsuite-developers.googleblog.com/2012/11/using-open-source-libraries-in-apps.html. Ces scripts sont destinés à développer des extensions et des interactions supplémentaires pour les documents Google Drive.

Rhino est également employé dans YUI Compressor (https://yui.github.io/yuicompressor/), un optimiseur CSS et JavaScript créé par Yahoo, désormais surpassé par Closure Compiler (https://developers.google.com/closure/compiler/) et UglifyJS (https://npmjs.com/uglify-js). Ce dernier est écrit en JavaScript et repose sur Node. La boucle est bouclée.

Node représente un environnement d’exécution (runtime), un ensemble d’API JavaScript ainsi qu’une machine virtuelle (VM) JavaScript performante (parseur, interpréteur et compilateur) capable d’accéder à des ressources système telles que des fichiers (filesystem) ou des connexions réseau (sockets).

Typiquement, une personne développant en Node écrit du code se basant sur les API à disposition. Ce code est lu par le runtime Node, qui le transmet à la VM JavaScript. Enfin, cette dernière traduit le programme en langage machine (bytecode) avant que le programme soit effectivement exécuté par le processeur.

Pour comprendre comment Node a opté pour cette approche, retournons en 2009, lorsque son créateur Ryan Dahl cherche à résoudre élégamment un problème de performance de programmation.

Bref historique

En 2006, Ryan Dahl est un étudiant américain en troisième année de doctorat de mathématiques. Son but initial était de devenir professeur dans cette matière, mais il prend la décision de ne pas terminer sa thèse et d’entreprendre un voyage au Chili.

Alors qu’il cherche à effectuer des petits boulots, il y rencontre une autre personne développant des sites web. Ruby on Rails connaît un succès grandissant et attire son attention. Alors que Ryan envisage d’utiliser Rails, il découvre avec horreur la lenteur du framework et cherche à en découvrir les causes.

Ryan débute alors sa quête des applications web performantes et découvre Mongrel, un serveur HTTP écrit en Ruby. Il est séduit par deux choses :

•la possibilité d’inclure un serveur HTTP comme bibliothèque applicative ;

•la simplicité de fonctionnement : recevoir une requête HTTP et décider soi-même de la réponse à apporter.

La quête initiale le dirige alors vers la possibilité de créer un serveur web non bloquant ; en d’autres termes, un serveur capable, dans un même processus, de traiter d’autres requêtes en attendant de renvoyer la réponse initiale.

Nous sommes alors en 2008 et le site de partage de photos Flickr innove avec un nouveau système de téléversement d’images : une barre de progression représentant le statut du téléversement remplace alors la page figée – effet inhérent à l’envoi de fichiers depuis un formulaire HTML.

C’est le déclic pour Ryan : bien que Mongrel ait déjà un plug-in pour cette fonctionnalité, il souhaite simplifier davantage le travail pour les développeurs. Il reproduit le mécanisme avec succès en C. Les développeurs web jugeant la solution trop complexe, Ryan tente la même approche avec d’autres langages, comme Python, Lua ou même Haskell. Il se heurte au sempiternel problème des ressources bloquantes des différents interpréteurs.

Figure 1–1 Interface du service Flickr après et avant l’introduction du téléversement progressif

LIEN Annonce du nouveau Flickr Uploadr

L’équipe d’ingénierie de Flickr explique dans un article (https:/...

Table des matières

• Couverture
• Le résumé et la biographie auteur
• Page de titre
• Copyright
• Avant-propos
• Table des matières
• Chapitre 1 : Histoire, écosystème et gouvernance
• Chapitre 2 : Installer, mettre à jour et développer
• Chapitre 3 : Jouer avec JavaScript
• Chapitre 4 : Jouer avec Node.js
• Chapitre 5 : Jouer avec npm
• Chapitre 6 : Déployer notre code
• Chapitre 7 : Créer une application web
• Chapitre 8 : Créer un outil en ligne de commandes
• Chapitre 9 : Créer une application front-end
• Annexe : Sélection de modules npm
• Index