Créer une application web

Nous l’avons dit : une requête HTTP envoyée vers un hôte reçoit une réponse. Cet hôte doit au préalable avoir installé et démarré un serveur HTTP qui écoute ces demandes.

Le script d’exemple server/start.js répond à ce besoin. Une fois démarré, il est joignable à l’adresse localhost:4000. Il affichera alors les en-têtes des requêtes et de leurs réponses :

Nous avons composé les fondations minimales pour créer une application web en mesure d’accepter des requêtes et de répondre quelque chose d’arbitraire certes mais compréhensible par un navigateur web.

Pourquoi avoir démarré le serveur sur le port 4000 dans l’exemple précédent ? C’est un choix arbitraire de ma part : nous pouvons démarrer un serveur HTTP sur n’importe quel port tant qu’il est libre et supérieur ou égal à 1000. Quand on cherche à se connecter à une adresse comme localhost (HTTP) et localhost (HTTPS), la valeur du port vaut implicitement 80 et 443, respectivement.

Le module npm get-port (npmjs.com/get-port) retourne un numéro de port parmi ceux disponibles sur le système d’exploitation.

Pour vous en rendre compte, démarrez le script server/start.js pour utiliser le port 4000 et démarrez ensuite server/port.js.

Nous avons vu qu’une URL est un identifiant qui se décompose en plusieurs parties grâce au module url (chapitre 4). Une d’elles est le chemin d’accès à une ressource.
Par exemple, le chemin de l’URL localhost:4000/coucou est /coucou.

Les deux seules ressources mises à disposition sur localhost:4000 sont accessibles avec les chemins / et /coucou. Aucun autre chemin n’aboutira.

C’est d’ailleurs un problème puisque, en réalité, nous n’envoyons pas de réponse pour un chemin inconnu. Et c’est à nous de gérer ce cas de figure :

La prise en compte d’une ressource inconnue de notre application fait émerger un nouveau concept : le statut de la réponse. Ce statut est un code numérique qui donne des indications sur la ressource retournée. Dans ce cas de figure, le statut 404 de la réponse indique au client de ne pas considérer le contenu comme celui qui était demandé.
Par défaut et sauf mention contraire, le statut est 200.

Les statuts HTTP sont importants dans la création d’applications web. Leur code permet de vérifier que le client et le serveur se sont bien compris.
Si une page d’erreur est affichée avec un statut 200, le client sera dans l’impossibilité de deviner qu’il ne s’agit pas du contenu attendu.

Une application web devient vite compliquée à gérer si nous devons lister tous les chemins possibles. C’est à ce moment qu’entre en jeu le routing, une technique pour décrire des chemins d’accès au lieu de s’embourber dans une longue liste de if …​ else.

Nous utilisons le module npm find-my-way (npmjs.com/find-my-way) pour transformer l’exemple path/request-url.js en quelque chose de plus modulaire :

Les routeurs commencent à vraiment nous faire gagner du temps lorsqu’il s’agit d’extraire des informations utiles depuis le chemin et de les gérer dynamiquement :

Dirigez-vous vers localhost:4000/hello/word pour voir le résultat s’afficher. Changez le dernier segment du chemin pour observer le changement.

Ce mécanisme est utile pour relier un identifiant à un enregistrement précis en base de données, par exemple. Il se complète avec les arguments d’URL pour véhiculer des éléments optionnels – nous y reviendrons plus loin.

Enfin, les routeurs contextualisent les actions à effectuer vis-à-vis d’une ressource grâce au verbe HTTP. Ce dernier communique une intention – récupération, mise à jour, suppression. Le routeur organise notre code pour déclencher une action adaptée à la méthode employée :

Les navigateurs web affichent seulement notre route GET car c’est leur fonctionnement par défaut. Ils comprennent le verbe POST pour téléverser des fichiers ou transmettre des formulaires.
Tournons-nous à nouveau vers le programme curl pour observer les différences entre les réponses nos deux verbes HTTP GET et HEAD :

L’utilisation de HEAD renvoie uniquement les en-têtes de réponse et nous économise la génération d’un gabarit. D’un point de vue client, le verbe HEAD aide à inspecter des ressources sans avoir à télécharger le contenu – ce sont autant de kilo ou mégaoctets économisés.

La responsabilité de comprendre ces verbes revient à notre application. C’est donc à nous de leur associer une action pour les prendre en charge.

Les chemins d’accès s’associent aussi à des fichiers statiques. Ainsi, à une URL correspond un fichier placé sur notre disque dur. J’ai placé trois fichiers de différentes natures (texte, image, PDF) pour illustrer les exemples de cette section.

Nous allons commencer par mettre à disposition un seul fichier, quel que soit le chemin demandé :

Ce que cet exemple nous apprend, c’est que l'objet de réponse est aussi un flux d’écriture. Peu importe le volume du fichier, l’envoi se régulera en fonction de la capacité de téléchargement du client et en consommant le minimum de mémoire possible. La lecture sera interrompue si le client annule le téléchargement.

Nous pouvons à présent étendre ce savoir nouvellement acquis en routant un chemin d’accès vers le répertoire qui contient nos fichiers.

Si nous accédons à localhost:4000/files/doc.pdf et localhost:4000/files/screenshot.jpg, nous verrons les deux documents s’afficher dans notre navigateur. Il reste cependant un problème : l’accès à un chemin inconnu fait planter l’application.

Nous constatons que notre approche est un peu trop naïve en regardant les en-têtes de réponse d’un peu plus près :

Nous allons nous baser sur le module npm send (npmjs.com/send) pour améliorer l’exemple précédent et constater par nous-même quels en-têtes sont utiles.

Nous n’avons pas apporté de grands bouleversements, si ce n’est que les fichiers inexistants ne font plus planter l’application et que les en-têtes de réponses sont plus fournis qu’avant :

Parmi les en-têtes les plus importants, nous trouvons Content-Type, Content-Length et Last-Modified. Ils aident le client à interpréter ou représenter le contenu de manière optimale, à informer de la taille du contenu (utile à l’animation de la barre de téléchargement du navigateur web) et à distinguer l’ancienneté du fichier.

Les arguments d’une URL servent à affiner le contexte d’affichage d’une ressource donnée. Ces options servent par exemple à paginer du contenu ou spécifier une dimension, un filtre d’affichage ou encore une expression de recherche. En clair, elles servent à influencer la représentation d’une ressource ou information.

Par défaut, les arguments sont représentés de manière textuelle avec le chemin d’accès, dans l’attribut request.url :

Nous voyons s’afficher /test?cle=valeur&option en nous rendant à l’adresse localhost:4000/test?cle=valeur&option. Ce n’est pas utilisable en l’état.

Le module url (chapitre 4) entre en jeu. En plus de déstructurer une URL entière, il sait aussi décomposer les options et les transformer en un objet utilisable côté Node :

Cette fois, nous voyons s’afficher {"cle": "valeur", "option": ""} dans notre navigateur lorsque nous nous rendons sur localhost:4000/test?cle=valeur&option. C’est tout ce qu’il nous fallait pour l’utiliser dans notre application.

Lorsque nous ne précisons pas la méthode employée, les outils et logiciels utilisent par défaut la méthode GET. Elle est associée à une récupération de données sans transmettre autre chose que des en-têtes et un chemin d’accès.

Il y a des cas où nous avons besoin d’envoyer des données, pour les stocker ou pour demander à créer un enregistrement. Dans ce cas, nous utilisons la méthode POST et nous transmettons les informations d’une manière différente.

Le serveur suivant affichera deux choses à chaque requête reçue : l’en-tête Content-Type et le corps du message transmis par la requête.

La commande curl règle le nom et la valeur d’un champ de formulaire avec l’option -d. Nous pouvons ainsi transmettre des données avec la méthode POST à notre serveur :

C’est vraiment l’équivalent d’un classique formulaire HTML.

Lorsque la page HTML est ouverte dans un navigateur et qu’on appuie sur le bouton Transmettre, les mêmes informations qu’avec la commande curl s’affichent.

Il se trouve que Node aussi sait envoyer des informations de formulaire avec le module http (chapitre 4).

Nous retrouvons l’en-tête Content-Type dans l’affichage du script post/server.js. Le contenu du message envoyé ressemble beaucoup à des arguments d’URL encodés avec encodeURIComponent().

Comme dans les sections précédentes, nous devons décoder une chaîne de caractères pour en extraire sa signification et en faire quelque chose en ECMAScript.

Nous pourrions utiliser la fonction parse() du module Node querystring pour décoder le contenu de cette chaîne, mais nous allons plutôt faire appel au module npm co-body (npmjs.com/co-body). Ce module décode plusieurs types de requêtes POST, illustrés dans d’autres exemples de cette même section.

Il nous suffit d’exécuter à nouveau le script post/send.js pour observer la différence et constater que nous pouvons désormais interpréter les données d’un formulaire.

Le fichier post/send.js se simplifie si on utilise le module npm superagent (npmjs.com/superagent). Je le trouve simple d’utilisation et il fonctionne avec des promesses, des formulaires et les téléversements de fichiers.

À ce stade-là, nous avons fait le nécessaire pour interpréter le contenu d’un formulaire sans pièce jointe. Notre serveur est même prêt à recevoir des données transmises en dehors d’un formulaire, au format JSON :

Nous constatons que la valeur de l’en-tête Content-Type change pour devenir application/json. Là aussi, le module co-body nous est utile, car il s’adapte au type des données entrantes et les décode de manière transparente.

Il existe un dernier type d’encodage de données que nous pouvons nous attendre à recevoir. Ce sont les formulaires dits multipart.

Le serveur va pourtant afficher une erreur du type :

Ce type d’encodage de données est plus complexe à gérer. Il va nous falloir passer à une autre stratégie, incontournable pour gérer le téléversement de fichiers.

Le téléversement de fichier implique un peu plus de travail qu’un simple formulaire car la structure des données envoyées diffère mais aussi, surtout, parce que la réception et la gestion des fichiers demandent encore plus d’attention.

Voyons par nous-même à quoi ressemble une requête qui contient une pièce jointe.

Ce serveur affiche le contenu d’une requête entrante. La requête suivante illustre le téléversement d’un fichier avec le programme curl. Notez que, cette fois-ci, nous utilisons l’option -F et que la valeur est préfixée avec le caractère @, suivi du chemin d’accès au fichier en question.

Cette commande est équivalente à l’envoi du formulaire HTML suivant :

La structure du corps de message d’une requête multipart/form-data envoyée avec la commande curl ou un formulaire HTML ressemble ce qui suit :

Il nous faudrait écrire davantage que 20 lignes de code si nous devions nous-même interpréter un contenu de requête qui contient des pièces jointes. C’est suffisamment compliqué à programmer de manière robuste pour que le module co-body vu dans la section précédente ne s’en charge pas et recommande le module formidable (npmjs.com/formidable). C’est exactement ce que nous allons faire pour outiller un nouveau serveur.

Nous sommes en mesure de recevoir des pièces jointes depuis un formulaire. Le module fs (chapitre 4) propose le nécessaire pour déplacer le fichier ailleurs sur le système ou pour en lire le contenu et le stocker ailleurs – sur un service de stockage distant (Amazon S3, par exemple).

Je recommande deux approches à appliquer avant même de faire quoi que ce soit avec une pièce jointe fraîchement téléversée :

Ces opérations risquent de prendre du temps – de quelques secondes à plusieurs minutes dans le cas de fichiers volumineux. Au lieu de faire attendre l’utilisateur devant son écran, je recommande de faire appel à un mécanisme de file d’attente pour traiter l’effort indépendamment, en fonction des capacités de calcul disponibles.

Enfin, quand vous avez fini d’utiliser la pièce jointe – ou si vous ne l’utilisez pas – pensez aussi à la supprimer du répertoire temporaire. Le disque dur du serveur pourrait manquer d’espace si plusieurs fichiers volumineux étaient déposés en peu de temps.

Un cookie est une information partagée entre un client et un serveur pour une durée limitée dans le temps. Le client transmet les cookies au serveur afin que ce dernier contextualise la demande – un identifiant utilisateur, des préférences ou autre. Un cookie créé par le domaine example.com est envoyé seulement lors d’une visite à example.com – sous-domaines inclus.

Ce mécanisme est aujourd’hui tristement célèbre pour son détournement par les industries de la publicité, du marketing et de la revente de données.

Nous pouvons observer la création du cookie en nous rendant sur localhost:4000 avec un navigateur, puis en ouvrant les outils de développement.

Les cookies sont transmis du client au serveur à chaque requête.

Nous avons récupéré la valeur de l’en-tête contenant le cookie. Nous devons faire un effort supplémentaire pour transformer cette valeur textuelle en une structure ECMAScript qui fait sens pour notre application.

Nous allons nous aider pour cela du module npm cookie (npmjs.com/cookie). Il sait interpréter le contenu d’un en-tête HTTP et il sait également faire l’inverse, transformer une structure ECMAScript vers du texte utilisable dans l’en-tête de réponse Set-Cookie.

La méthode response.setHeader() accepte un tableau pour créer plusieurs cookies en même temps :

Cet exemple est aussi l’occasion de compléter les cookies avec des directives, qui modifient leur durée de vie et leur visibilité.

Cela s’observe en lançant à nouveau le script cookies/parse.js :

L’accès à localhost:4000 affiche quelque chose comme {"compteur":"1","language":"fr"} tandis que localhost:4000/admin affiche un cookie supplémentaire – {"is_admin":"1","compteur":"1","language":"fr"}.

Nous savons maintenant garder le lien avec nos utilisateurs. Nous utiliserons d’ailleurs les cookies pour maintenir une session avec un framework web.

Les gabarits de présentation (ou templates) répondent à deux problèmes : séparer le code applicatif (le fond) de la présentation (la forme) et aussi structurer la complexité visuelle avec des composants réutilisables.

Nous allons nous pencher sur le module nunjucks (npmjs.com/nunjucks). Je l’apprécie pour son élégance et pour son caractère extensible. Il existe d'autres modules de présentation bien sûr et je vous invite à choisir celui qui vous parle le plus, quitte à en changer par la suite.

J’attends plusieurs choses d’un système de gabarits : itérer facilement sur des collections (tableaux, objets), appliquer des filtres, inclure des portions de présentation et imbriquer ma page dans un modèle de présentation – une sorte de décoration qui contient des choses que je veux garder hors du gabarit (comme le menu principal ou les balises <meta>).

Dans la suite de cette section, nous allons créer une présentation à partir d’une liste de modules npm contenue dans un fichier JSON. L’image suivante illustre très bien ce que nous cherchons à atteindre.

Dans cet exemple, nous répondons la même chose, peu importe le chemin demandé au serveur. Nous pourrions tout à fait ajouter un routeur afin de répondre avec un gabarit différent pour chacune des routes. Nous verrons aussi dans la section “Organiser une application” qu’un des buts des frameworks est d’apporter ce genre de cohérence.

Côté serveur, nous prenons une structure qui ne change pas (le gabarit) et nous la combinons avec une structure qui change (les données) pour générer un rendu HTML adapté au client à l’origine de la requête.

Le gabarit se concentre sur la transformation de données. Il faut au préalable avoir réuni et structuré les données nécessaires à l’affichage. Nous avons la possibilité de fragmenter notre code de sorte que chaque gabarit contienne uniquement ce qui dépend de sa responsabilité.

Nous retrouvons ces principes de fonctionnement dans d’autres langages, à quelques variations près.

Intéressons-nous maintenant au gabarit parent, layout.njk :

Ce gabarit sert de “décoration”, en englobant puis injectant son contenu de manière précise et contrôlée. Nous sommes en mesure de hiérarchiser l’organisation de la présentation et de choisir comment imbriquer les gabarits entre eux.

Nous détaillons des exemples de rendu de gabarit en annexe A.

Vous avez modifié un des exemples de ce chapitre pendant qu’il était en cours d’exécution et vous avez remarqué que résultat ne changeait pas ?

C’est normal : la version du code utilisée par Node est celle qui a été évaluée au lancement du script. Les changements sont pris en compte manuellement, à la prochaine exécution, c’est-à-dire après avoir stoppé et lancé à nouveau le script.

Le module npm exécutable nodemon (npmjs.com/nodemon) relance automatiquement une commande dès qu’il détecte un changement dans le répertoire courant.

La commande précédente relance cookies/parse.js si ce fichier change, si un fichier dans le répertoire cookies/ évolue, mais aussi si un fichier dans les répertoires voisins au répertoire cookies/ est modifié.

L’option --watch restreint ou élargit le champ d’observation. La commande suivante relance le serveur seulement si un fichier JavaScript est modifié dans le répertoire cookies/ :

L’option --ext filtre les fichiers observés en fonction de leur type. La commande suivante relance le serveur si un fichier JavaScript, CSS ou HTML est modifié dans le répertoire courant :

La configuration initiale d'Express définit un serveur HTTP – à la manière de ce que nous faisions avec http.createServer() – et retourne un routeur pour attacher des comportements à des chemins d’accès.

C’est vraiment très proche de ce que nous avons déjà appris à faire dans les sections “Démarrer un serveur HTTP” et “Répondre à un chemin”.

Un des premiers éléments différenciant est le branchement d’extensions. Une fois configurées, ces extensions s’appliquent à chaque requête entrante. Elles ajoutent des capacités de compréhension de la requête (parser des données de formulaire par exemple), de modifier la réponse ou de connecter des gabarits de présentation.

Chaque couche de transformation est appelée un middleware – une fonction intermédiaire entre la requête et la réponse.

Un middleware n’est pas très différent d’une route : c’est une fonction qui a accès à la requête et à la réponse HTTP. Elle n’est pas forcément affectée à une méthode HTTP (app.get(), app.post()) ni à un chemin d’accès.

Dans l’exemple suivant, nous allons connecter plusieurs middlewares grâce aux modules npm helmet (npmjs.com/helmet) et serve-static (npmjs.com/serve-static). Ce dernier est une version embarquée de serve par le module Express.

Le mécanisme de middlewares est minimaliste, et pourtant, il nous permet de brancher des modules dont le seul pré-requis est de comprendre les objets de requête et de réponse HTTP. Les middlewares relient tous les concepts évoqués dans la section “Composer son application web”.

Le module helmet agit seulement sur les en-têtes de réponse. Nous verrons dans la section “Protéger nos applications” quels en-têtes sont essentiels à la sécurité et pourquoi.

Enfin, notons une méthode alternative pour appliquer un middleware : au niveau d’une route, au lieu de toutes les routes – avec app.use(). Pour cela, nous allons transformer l’exemple framework/middleware.js et l’appliquer à une seule route :

Nous verrons que, même si la fonction d’affichage est identique, les routes localhost:4000/ et localhost:4000/rondoudou produisent des résultats différents. Cette dernière n’ayant pas reçu le middleware pokéMiddleware, sa variable response.locals.pokemon n’a pas été définie et elle vaut donc undefined.

La configuration des gabarits de présentation n’est pas très différente de ce que nous avons vu dans la section qui leur est consacrée.

Nous avons de la chance car nunjucks prend en charge toute la configuration d'Express pour nous. La seule différence avec les précédents exemples est l’utilisation de la méthode response.render(). Le premier effet que cela me fait est une sensation de légèreté – nous avons le strict minimum à gérer pour que cela fonctionne.

En comparaison, voici comment Express se configure à la main :

Cette méthode demande davantage de travail. Elle implique aussi d’être suffisamment familier·ère avec Express pour en venir à créer cette fonction de rendu.

Au final, nous pourrions utiliser différents moteurs de gabarits si le besoin se faisait ressentir, pour les exploiter à leur(s) avantage(s). Leur intégration demande un effort minimum et retire tous les aspects de présentation de la configuration du routeur.

La gestion des ressources front-end ne demande pas à changer nos habitudes. Les fichiers CSS, JavaScript et les images sont des fichiers statiques à mettre à disposition via un middleware.

J’ai tendance à exposer les fichiers statiques depuis un répertoire virtuel dédié – ici, /static. Cela rend plus clairement identifiables et évite toute ambiguïté avec les autres routes de l’application. Cela a aussi l’avantage de dissocier les fichiers sources (Sass, Less, etc.) des fichiers compilés.

Dans le chapitre 5, j’explique comment automatiser l’outillage projet. Ces connaissances s’appliquent dans notre cas de figure, sans distinction.
L’extrait suivant de fichier package.json illustre l’organisation des scripts pour démarrer le site en temps normal, pour générer les fichiers compilés et pour le faire en continu dans un contexte de développement.

La première partie est dédiée aux scripts dits “de production” : npm run build génère les fichiers utiles quand le serveur tourne, après avoir lancé npm start.

La seconde partie lance le serveur de développement et la construction des fichiers Sass en continu avec l’option --watch. L’option --source-map s’utilisent dans un contexte de développement pour associer les lignes du fichier compilé aux fichiers sources. Les doubles tirets (--) nous permettent de réutiliser le script build:css en lui passant deux options supplémentaires.

Le middleware statique s’utilise aussi avec des fichiers.

Cette technique est utilisable pour exposer un seul fichier au lieu d’un répertoire entier.

Enfin, le module npm express-minify (npmjs.com/express-minify) est à considérer pour profiter d’une mise en place rapide ou pour prototyper quelque chose en attendant de mettre en place un outillage plus robuste.

Si ce module permet de démarrer plus vite, sans avoir à se familiariser avec les scripts npm ni même avec la commande node-sass, je lui vois deux inconvénients majeurs : les erreurs sont difficiles à déceler et elles risquent de se produire au cas où notre machine de développement est significativement différente du serveur de production (compilateur, installation manquée). Cela représente aussi un gâchis de ressources dans la mesure où ces fichiers ne changent plus une fois mis en ligne ; cela ne justifie pas d’ajouter du temps de compilation à la volée.

En clair, c’est pratique pour dépanner et pour démarrer.

L’utilisation d’une base de données sert à mémoriser des informations entre deux redémarrages de notre application – sinon, ce qui est en mémoire applicative disparaît. Je vous recommande de lire la section “Quel(s) moteur(s) de base(s) de données choisir ?” pour éclairer votre choix.

L’intégration d’une base de données se fait en deux temps :

Nous verrons dans la section “Vers un code réutilisable et testable” qu’un des enjeux est de rendre le fichier de démarrage le plus fin possible.

Nous avons appris à mémoriser des données et à les partager avec un serveur grâce au mécanisme des cookies. Les sessions utilisateur centralisent cette mémoire du côté du serveur. Elles se basent sur un cookie de session pour garder un lien.

Les sessions sont destinées à stocker des données temporaires, liées à une personne. Un utilisateur peut avoir plusieurs sessions – une par appareil par exemple. Chaque session est propre à son environnement immédiat. Elles sont pratiques pour mémoriser des informations liées à un état (connecté·e, déconnecté·e, date de dernière activité).

Tout stockage qui serait permanent relève des préférences utilisateur.

L’extension express-session (npmjs.com/express-session) se charge de ce travail pour nous. Il ajoute un élément request.session qu’il mémorise et récupère à partir d’un identifiant de session difficile à deviner.

La même valeur s’affiche si vous ouvrez un nouvel onglet dans le même navigateur et en vous rendant sur localhost:4000/my-pokemon. Le serveur fait le lien entre votre identifiant de session (stocké en cookie) et les valeurs associées (stockées en mémoire, pour l’instant) grâce à un identifiant unique stocké dans le cookie de session.

Le middleware de session retrouve les informations associées à cet identifiant depuis l’espace de stockage des données de sessions.

Le seul inconvénient à notre exemple est que, si nous stoppons puis relançons le serveur, la page localhost:4000/my-pokemon affiche undefined comme nom de Pokémon. C’est normal : le stockage par défaut étant en mémoire, les données de session sont détruites dès que le processus Node s’interrompt.

Fort heureusement pour nous, ces données se stockent avec la base de données de notre choix. Nous allons utiliser le moteur de base de données SQLite à l’aide du module connect-sqlite3 (npmjs.com/connect-sqlite3) pour illustrer la persistance des données de session.

Cette fois, si nous stoppons le serveur puis le relançons, le gestionnaire de sessions affiche le nom de Pokémon associé à notre identifiant. La persistance a fonctionné !

Consigner les actions (logging en anglais) est une pratique courante en informatique pour créer une mémoire de l’activité d’une application. Ces consignes aident à garder des traces de choses invisibles en surface, d’événements sensibles ou critiques (envoi de mot de passe, création de compte) afin de détecter des anomalies de fréquence.

C’est un endroit idéal pour répertorier les erreurs avec des indications qui aideraient à reproduire le problème. D’ailleurs, l’usage est de tenir un journal d’erreurs séparé du journal des événements afin de retrouver plus facilement ces premières. J’ai tendance à préférer l’installation d’une sonde (section “S’informer des erreurs applicatives” du chapitre 6).

C’est à nous de choisir la granularité des informations enregistrées. Nous sommes responsables de l’anonymat de ces informations et de ne rendre personnel que l’identifiant (numérique ou généré) pour rattacher des informations à un utilisateur si c’est nécessaire – dans le cas de transaction bancaire ou de renvoi de mot de passe par exemple.

Les modules npm pour consigner nos actions fonctionnent comme des console.log() finement configurables : winston (npmjs.com/winston), morgan (npmjs.com/morgan) et bunyan (npmjs.com/bunyan) sont à essayer, pour voir celui qui vous convient le mieux.

Les journaux de sortie se connectent à des logiciels comme rsyslog (rsyslog.com) ou à des services en ligne comme Papertrail (papertrailapp.com), Logstash (elastic.co/products/logstash) et AWS CloudWatch (aws.amazon.com/cloudwatch). Elles vous aident – ou vous demandent de travailler davantage – pour visualiser, orchestrer et déclencher des actions quand des valeurs spécifiques sont rencontrées dans les journaux.

Le défi de lisibilité et de maintenance augmente au fur et à mesure que le volume de code augmente. C’est particulièrement vrai quand le nombre de lignes dépasse un seuil psychologique dans un même fichier – je commence à saturer au-delà de 100 lignes, par exemple. Ce phénomène se renforce quand plusieurs concepts s’entrecroisent visuellement.

La modularisation des routes et de notre application web va nous rendre la vie plus confortable. Nous ouvrons la porte à l’écriture de tests unitaires, à un déplacement plus aisé du code et à une quasi-disparition des variables globales. Nous en profitons pour rendre nos intentions explicites, ce à quoi nous obligent les réflexions de nommage de fichiers et de fonctions.

Nous créons des modules qui retournent des fonctions ou des objets. Nous connectons ensuite ces fonctions aux chemins d’accès du routeur.

Profitons du mécanisme de promesses pour que tout autre module puisse réagir à l’aboutissement de la connexion :

Notons que nous exploitons le mécanisme de cache des modules Node dans cette dernière ligne. Chaque appel au fichier database.js retourne la même promesse. Nous créons ainsi une seule connexion à la base de données même si nous chargeons plusieurs fois ce module.

Je trouve agréable de regrouper ce genre de lignes de code dans un même fichier. Les dépendances aux modules Node et npm deviennent vraiment claires. Je suis moins dérangé par l’organisation visuelle du code – elle aurait ralenti ma lecture du fichier server.js autrement.

Le fichier de routes a vocation à réexporter les fonctions de routage. Je trouve que cette organisation sous forme de catalogue fait énormément gagner en lisibilité lors de l’intégration avec le routeur.

Le dernier morceau est la route elle-même :

Le code de la route est quasi inchangé mais on voit à quel point elle prenait de la place dans le code d’origine. Ce déplacement révèle le positionnement du point d’attention et quels fichiers sont amenés à changer au quotidien. Peu importe l’organisation du vôtre, ce qui compte c’est que cette organisation vous convienne, qu’elle soit communicable aux personnes qui utilisent ce code et que nous puissions en suivre le fil logique.

Je vois toutefois apparaître une zone d’ombre : je ne suis pas satisfait de la connexion à la base de données. C’est la résolution de la promesse dans la route qui me fait dire ça ; elle ne semble pas à sa place.

Faisons une nouvelle itération pour ajuster ce code et tendre vers quelque chose d’un peu plus explicite.

La grande différence ici est l’invocation d’une fonction pour définir la route. C’est le moyen le plus propre pour transmettre une variable en enlevant la dépendance au module database.js dans le script books.js :

L’appel à la fonction require() a disparu. La résolution de la promesse aussi. Notre module est autonome tant qu’il reçoit un objet de base de données en paramètres. Cela le rend nettement plus lisible – le code est désormais uniquement lié à la réception d’une requête HTTP et à l’établissement d’une réponse.

Nous retrouvons le même mécanisme que celui rencontré dans le fichier routes.js.

Au final, le motif qui émerge est celui de l'encapsulation de code dans des fonctions paramétrables. Les paramètres sont les seuls points d’entrée. Les arguments font office de contrat et les fichiers font office de regroupement logique – de fonctions et d’objets.

Nous avons allégé le fichier server.js et rendu lisibles les points importants de l’application : la connexion à la base de données, le rendu d’une route et la configuration de l’application. Ce travail va nous permettre de tester petit à petit les différents éléments de l’application web, par ordre de criticité.

L’écriture de tests unitaires est influencée par et influence l’organisation de notre code en unités réutilisables. Ils accroissent la qualité, la confiance et la prédictibilité d’une éventuelle mise en ligne.

Cette section se déroule dans la continuité de la précédente. Nous allons préparer et mettre en place pas à pas un environnement de test pour vérifier les intentions de notre code.

Les tests unitaires sont destinés à couvrir les différents cas de figure des entrées et des sorties de nos fonctions. Nous testons leurs réactions aux arguments pour vérifier que nous obtenons le résultat attendu. Je teste en priorité le code critique, partagé (en tant que bibliothèque) et qui est au plus proche de l’interface utilisateur.

De quoi a-t-on besoin pour tester routes/books.js ? La fonction qui est exportée par le module dépend d’une connexion établie à une base de données et de deux objets – la requête entrante et la réponse sortante. Nous avons aussi besoin d’écrire des assertions et, dans un premier temps, nous allons utiliser le module dédié de Node.

Le script n’affiche rien de particulier. C’est normal, parce que le test s’est bien passé. Une assertion lance une erreur si elle constate un résultat différent de l’attente.

Nous avons toutefois testé une évidence, que le module retourne une fonction. Ce qui serait plus révélateur serait de tester l’invocation de cette fonction pour vérifier qu’elle produit un résultat prédictible.

Modifions notre fichier de test pour établir une connexion à la base de données. Nous avons une contrainte toutefois : nous devons utiliser une base dont l’emplacement est différent de notre environnement de développement. Le raisonnement est de pouvoir la recréer et la détruire sans craindre de générer des effets secondaires, y compris si nous exécutons les tests sur le serveur de production.

Pour ce faire, commençons par simplifier le fichier src/database.js en supprimant tout chemin d’accès écrit en dur :

Cela ouvre la voie pour nous connecter à une base de données différente dans notre script de tests.

Résultat : la connexion à la base de données réussit et nous sommes en mesure de la transmettre à la fonction de paramétrage de la route.

Le chemin d’accès était exprimé de la manière suivante : /books/:id. Autrement dit, la requête à la base de données dépend d’un objet request.params dont la clé id vaut 1.

C’est ce que nous allons passer à la fonction route. Mais qu’en est-il de la réponse ? Doit-on réécrire un objet qui reproduit l’objet response d'Express ? Je déconseille cette option car elle nous oblige à écrire du code, faillible, et donc à introduire des biais dans nos propres tests.

Les bibliothèques d’interception évitent ce cas de figure. Elles se greffent à du code existant pour observer ses réactions, voire pour les remplacer temporairement, le temps des tests. J’ai l’habitude d’utiliser le module npm sinon.js (npmjs.com/sinon, sinonjs.org/). Il propose tout le nécessaire, est bien documenté et fonctionne aussi bien côté Node que côté navigateurs web.

C’est une chance que le module Express expose directement un objet de réponse sans avoir à attendre qu’une vraie requête HTTP atteigne notre serveur web. Le stub neutralise son action – nous nous contentons d’observer comment la fonction est appelée. L’enjeu est de constater que la connexion à la base de données se passe bien, que la requête retourne bien la ligne attendue et que ses valeurs soient bien transmises en réponse.

Malheureusement pour nous : la base en mémoire n’a aucune donnée. Le test échoue donc. Notre nouvel objectif est de maintenir l’intention du test et de lui ajouter les données nécessaires à son exécution.

C’est la raison d’être des fichiers dits de fixtures. Ces données peuplent une base de données d’enregistrements suffisamment réalistes pour illustrer les différents cas de figure de notre application.

Ce cas est particulièrement adapté à la syntaxe async/await. Ces promesses sont séquentielles et la syntaxe linéarise leur lecture. Le même exemple sans async/await et juste avec les promesses est moins digeste à lire.

Il ne nous reste plus qu’à appeler cette fonction de génération de données depuis notre script de tests :

Le test est concluant ! Et nous n’avons plus de doute que la fonction response.send() est bien appelée avec la valeur issue de la base de données. Le module sinon a été d’une grande aide pour intercepter l’exécution de cette fonction et pour nous faciliter son introspection, après coup.

Pour être exhaustifs, il nous faudrait maintenant tester le deuxième cas de figure, celui où le paramètre id de l’URL fait référence à un enregistrement qui n’existe pas en base de données pour générer une erreur 404.

Dans ce cas, nous avons eu recours à un espion pour observer la méthode response.status() d’Express. Nous avons procédé ainsi car nous n’avions pas à neutraliser son fonctionnement mais seulement à observer la valeur de son argument. Le fait qu’il soit de 404 prouve que la branche de code à l’intérieur de la condition if a bien été visitée.

Je constate un problème dans cette écriture cependant. L’espion et le stub sont créés une seule fois et partagés entre chaque test. Cette pratique entraînera des effets de bord si nous ne prêtons pas attention au déroulé des tests. Ils devraient être remis à zéro entre chaque test.

Les suites de tests sont des outils qui renforcent la cohérence et la structure, notamment pour automatiser l’exécution d’actions avant et après des tests. J’utilise le module npm mocha (npmjs.com/mocha, mochajs.org), par habitude, parce qu’il ne demande aucune configuration et parce qu’il fait le travail à la fois côté Node et côté navigateurs.

Notre script de test comporte désormais ce qu’on appelle une suite de tests, c’est-à-dire, un ensemble de tests qui expriment nos attentes vis-à-vis d’une fonctionnalité – ici, une route d’application web.

Ce découpage a le mérite de clarifier les différents temps de nos tests, à savoir la préparation de l’environnement d’exécution, le nettoyage puis l’exécution des tests.

La suite de tests ne cherche pas à savoir comment nous testons notre code. Son objectif est de capturer les messages d’erreur des assertions qui échouent et de nous les communiquer en contexte.

L’approche Test Driven Development (TDD) est pilotée par les tests. Dans ce contexte, nous écrivons les tests avant même d’avoir écrit notre code. Cela nous force à réfléchir à l’intention et à concevoir le code de manière à ce qu’il soit testable. Qu’on adopte ou non cette méthode, nous gagnons en qualité en faisant échouer les tests, juste pour nous assurer que ce n’est pas un bogue (oui ça arrive) quand ils indiquent que tout est correct.

Maintenant que nos tests sont écrits, nous sommes en mesure de déployer notre application automatiquement, seulement si leur exécution est réussie.

Cette section continue à ajouter de l’automatisation dans notre manière de fonctionner. Elle n’est donc pas spécifique aux frameworks et est tout à fait valide si vous vous constituez votre propre application, brique par brique.

Le déploiement automatique sert principalement à révéler les points de friction. Si nous manquons de confiance dans le déploiement, c’est probablement qu’il y a des nœuds à démêler. L’automatisation du déploiement et la facilité de sa répétabilité nous aident à gommer ces frictions petit à petit. La pression de la mise en production se transforme en incitation au changement.

La fréquence des déploiements révèle les points de congestion. Tout ce qui est trop lent à notre goût est un appel à gommer cette lenteur, à trouver une autre approche pour finalement observer le résultat du déploiement plus rapidement.

L’enjeu des livraisons automatisées est double : d’abord, faciliter le transport du code vers le serveur de production (en cas de bogue, le temps passé concerne seulement la résolution du problème et non la livraison elle-même) et servir de documentation du processus de livraison.

Nous abordons plus en détail les différents mécanismes techniques dans le chapitre 6, que ce soit “à la main”, avec des recettes de déploiement ou par le biais de notre service d’hébergement.

Il y a des environnements où des logiciels comme Apache et Nginx intègrent notre langage de programmation avec des modules : par exemple, PHP avec le mod_php ou Perl avec le mod_cgi. Les requêtes entrantes sont dirigées vers un script que le module interprète et qui retourne une réponse, dynamiquement.

Le script PHP est interprété à chaque requête et toute cette représentation est détruite une fois la réponse envoyée (mémoire, valeurs des variables, configuration). Il faut recourir à un ensemble de modules additionnels pour optimiser ce gâchis de ressources informatiques : cache d’interprétation, cache applicatif, cache de configuration.

Démarrer un serveur HTTP dans le langage de notre application nous éloigne de ce modèle coûteux et nous rapproche d’un fonctionnement plus performant, organisé autour des trois piliers suivants :

Autrement dit, ce modèle réduit le temps de parcours entre une requête entrante et une réponse sortante. Cela a un effet significatif sur le temps d’apparition de l’icône de chargement côté client.

Deux éléments ressortent du modèle de fonctionnement du protocole HTTP : tout est du texte (en-têtes et contenu) et chaque requête est indépendante. Cela revient à dire que chaque requête emporte son contexte avec elle, toutes les informations nécessaires à sa compréhension.

Que se passe-t-il lorsque notre navigateur web ou le programme curl demande à accéder à example.com ?

Dans le cas du programme curl, la réponse est affichée telle quelle, en texte.

Avec un navigateur en revanche, le HTML est interprété. Le navigateur demande les ressources listées dans les différentes balises (img, video, audio) ; l’indicateur de chargement s’arrête quand toutes les ressources ont été demandées et téléchargées.

Le nombre de requêtes et la taille des ressources affectent donc la vitesse de chargement d’une page. Plus il y en a, plus le client doit en demander et plus le serveur multiplie le nombre de réponses. Le temps de téléchargement augmente.

Le module npm jshttp (github.com/jshttp) affiche les en-têtes de réponse comme le programme curl le ferait et détaille le parcours réseau, de la résolution du nom de domaine jusqu’au temps passé à négocier une transaction sécurisée. Nous comprenons ainsi mieux des temps qui sont rendus invisibles et sur lesquels nous pouvons faire des efforts – réduire les temps de transfert ou le temps de réponse de notre application par exemple.

Quand je codais en PHP, nous parlions beaucoup de la pile technique LAMP (Linux, Apache, MySQL et PHP). C’était la combinaison de facto des différents projets. MySQL était la base de données de choix tandis que les Pythonistes et Rubyistes se focalisaient plutôt sur PostgreSQL.

J’ai croisé beaucoup de développeurs et développeuses qui se lançaient dans les bases de données dites “documents” comme MongoDB “parce que les données sont stockées en JSON et donc c’est un choix logique pour Node”.

Je suis fortement en désaccord avec cette dernière affirmation et je pense que la bonne base de données est celle qui tient la route par rapport à Node. Le débit de données entre Node et la base compte davantage, ainsi que la rapidité de la base à exécuter une requête et retourner des résultats (certaines gèrent mieux que d’autres la concurrence d’accès ou les critères de filtrage). Le troisième critère est subjectif : c’est le confort d’utilisation ; PostgreSQL est peut-être plus rapide pour un cas d’usage précis, mais si vous êtes plus à l’aise avec MariaDB ou MySQL, commencez avec la base qui vous parle le plus – ou expérimentez et réservez-vous le droit de changer d’avis après avoir joué avec un nombre représentatif de données.

Je choisis une base de données en fonction de plusieurs critères : la rapidité de lecture, l’intégrité des données, la volumétrie acceptée avant de devoir distribuer les données sur plusieurs machines et enfin, des fonctionnalités spéciales (recherche géographique, type de champ particulier comme le champ JSON de PostgreSQL).

J’utilise souvent SQLite pour prototyper quelque chose de rapide sur ma machine. Je passe ensuite à MySQL ou PostsgreSQL selon le projet – je me sens autonome sur le premier pour l’installation tandis que je préfère un service qui gère tout de bout en bout avec le second.

Je peux être amené à indexer les données dans une base Elasticsearch ou Algolia pour leur donner une autre structure, spécialement optimisée pour la recherche : une lecture très rapide sur des critères variables. Je le fais si un des aspects principaux du projet est de préserver des performances élevées, qui ne soient pas ralenties par l’activité d’une base SQL.

Je complète en général avec Redis pour gérer les files d’attente, des données intermédiaires que je considère comme “jetables”.

S’il est plus simple de tout gérer avec un seul support de stockage, utiliser plusieurs gestionnaires de bases de données dans une même application est quelque chose de tout à fait encouragé pour profiter de leurs caractéristiques.

Il faut prendre des mesures de précaution dès lors que nous utilisons des données saisies par un utilisateur, c’est-à-dire toute variable dont la valeur provient de l’extérieur. Je pense à des données de formulaire, des paramètres d’URL, des chemins d’accès, des fichiers téléversés mais aussi des scripts qui sont injectés dans la page, volontairement ou via un logiciel vérolé installé sur leur ordinateur.

Outre les données arbitraires, il faut toujours s’assurer des permissions. L’utilisateur a-t-il vraiment le droit d’être là ou il est ? Le volume du fichier téléversé est-il vraiment cohérent ?

L’utilisation du mode strict a l’avantage de nous protéger de l’exploitation d’anciennes bizarreries d’ECMAScript. Ce qui doit planter plante au lieu d’être passé sous silence.

Parfois, même les caractères autorisés suffisent à déjouer notre attention. C’est le cas si une variable est utilisée pour composer un chemin avec path.resolve() ou path.join() par exemple. La saisie utilisateur crée un chemin de traverse qui permet d’aller exploiter des données ailleurs sur l’ordinateur.

Un moyen solide de vérifier que nous n’avons pas été dérouté·e en dehors d’un répertoire racine – ici, base_dir – est de vérifier que le chemin final débute bien par le chemin du répertoire racine.

Le principe d’une application web est d’afficher un résultat à partir d’un chemin d’accès et de rester allumée en permanence, sauf exception. Les Lambda sont une approche minimaliste d’application web : il n’y a qu’une seule route, c’est une seule fonction qui retourne un résultat.

L’application s’endort quand elle ne reçoit pas de trafic dans un laps de temps donné. Elle est “réveillée” quand du trafic arrive. La facturation se fait à l’échelle de la seconde et au nombre de requêtes entrantes. Nous en parlons un peu plus en détails dans le chapitre 6.

Ce mécanisme s’adapte à des résultats en réaction à un événement : webhook, notification, erreur, etc.

Le module npm micro (npmjs.com/micro) est un serveur minimaliste qui répond à ce principe de micro-application, prête à être mise en pause à tout instant.

Un service comme AWS Lambda (aws.amazon.com/lambda) pousse le concept encore plus loin. La fonction réagit à un événement interne (notification SQS, quelque chose lié à notre infrastructure, déploiement) ou à un événement externe (via l’API ou un autre service ouvert vers l’extérieur). Elle n’est pas forcément exposée sur le Web.

L’adaptabilité de ce mécanisme permet de créer une API complète en agrégeant plusieurs Lambda derrière un portail d’API comme AWS API Gateway (aws.amazon.com/api-gateway). À une API et une ressource (chemin et méthode HTTP) est associée une ressource AWS, dont les Lambda font partie.