Node JS Tutorial Français pour Débutant - Cours complet 8h [2022]

Une formation complète de plus de sept heures est présentée, visant à amener les participants du niveau débutant à la capacité de déployer une API REST fonctionnelle avec une base de données sur Internet. La maîtrise préalable du langage JavaScript constitue un prérequis essentiel pour suivre ce parcours de développement backend.

L'instructeur, Simon, partage son expérience de formateur auprès d'ingénieurs sur les technologies JavaScript modernes. L'objectif principal de cette chaîne est de démystifier le développement d'applications web complètes, considérées comme des logiciels fonctionnant directement dans un navigateur. Une partie du contenu avancé est disponible moyennant un lien en description.

Soyez persévérant ne lâchez rien et ça devrait bien se passer.

Node.js est défini comme un environnement permettant l'exécution de code JavaScript côté serveur, par opposition à l'exécution habituelle dans le navigateur. Pour clarifier cette notion, il est nécessaire de comprendre ce qu'est un environnement d'exécution en informatique : le lieu où le code devient un produit utilisable.

Chaque navigateur intègre son propre moteur JavaScript invisible pour interpréter le code. Par exemple, Internet Explorer utilise Chakra, Mozilla utilise SpiderMonkey, et Chrome utilise le moteur V8. Cette disparité explique pourquoi le même code JavaScript peut fonctionner différemment selon le navigateur utilisé par l'utilisateur final.

Node.js, créé pour exécuter JavaScript hors navigateur, intègre directement le moteur JavaScript le plus performant de l'époque : V8, rendu open source par Google. Ainsi, l'environnement serveur (Node.js + V8) et l'environnement web (Navigateur + Moteur spécifique) partagent le même langage d'exécution, bien que les consoles d'exécution diffèrent.

Le succès de Node.js repose sur plusieurs atouts par rapport aux environnements serveurs traditionnels comme PHP ou Java. L'utilisation du JavaScript, langage le plus répandu, unifie les compétences de l'équipe, simplifiant les ressources et la communication entre développeurs frontend et backend. De plus, Node.js est extrêmement rapide grâce au moteur V8 et à son architecture non bloquante, le rendant idéal pour les applications temps réel.

L'installation de Node.js nécessite de choisir entre la version LTS (Long Term Support), recommandée pour sa stabilité et sa viabilité à long terme, et la version actuelle, qui intègre les dernières fonctionnalités mais peut encore subir des ajustements. Il est conseillé de privilégier la version LTS pour le démarrage d'un nouveau projet.

L'installation de Node.js inclut automatiquement NPM (Node Package Manager), essentiel pour gérer les dépendances. Il est impératif de vérifier que Node.js et NPM sont correctement installés en exécutant respectivement les commandes node -v et npm -v. Pour l'édition de code, des IDE comme Visual Studio Code sont fortement recommandés pour leur support du JavaScript.

Le démarrage d'un projet commence par la création d'un dossier et d'un fichier d'entrée, souvent nommé app.js ou server.js. L'initialisation du projet se formalise par la création du fichier package.json via la commande npm init. Ce fichier décrit le projet et liste ses dépendances.

Le fichier package.json a au moins deux missions principales : donner une description rapide à votre projet et lister toutes les dépendances de votre application.

L'exécution du script initial se fait avec la commande node app.js. Il est également possible de définir des scripts personnalisés, comme npm run start, qui exécute node app.js, simplifiant ainsi les commandes répétitives.

Express.js, le framework le plus populaire pour créer des API REST avec Node.js, est installé via NPM. L'option --save assure que cette librairie est explicitement ajoutée à la section dependencies du fichier package.json, garantissant son installation lors du déploiement futur.

La construction d'un point de terminaison dans une API REST avec Express repose sur l'équation : app.[méthode http]([chemin], [fonction gestionnaire]). Le cœur d'Express réside dans la définition de ces routes, où la fonction gestionnaire reçoit les objets req (requête) et res (réponse).

Le code minimal pour définir une route GET sur la racine (/) utilise la méthode res.send() pour retourner un message au client. Pour démarrer le serveur et écouter les requêtes sur un port défini (ici, 3000), la méthode app.listen() est employée.

Le terme GET que l'on retrouve au début de la ligne va prendre en paramètre deux éléments : premièrement le chemin de la requête, deuxièmement une fonction qui fournit une réponse au client.

Le développement est ralenti par la nécessité de stopper et relancer la commande npm run start après chaque modification de code. Nodemon est un paquet externe installé comme dépendance de développement (--save-dev) qui surveille les fichiers et redémarre automatiquement le serveur Express lors de changements, accélérant considérablement le cycle de développement.

Une réponse HTTP valide dans une API REST doit comporter plusieurs éléments cruciaux : les données demandées, le format de ces données (idéalement JSON), le type MIME (spécifiant application/json), et surtout, un code de statut HTTP indiquant le résultat de l'opération (ex: 200 pour succès, 404 pour ressource non trouvée).

Pour garantir que les données sont envoyées au format JSON avec le type MIME correct, la méthode res.json() d'Express est préférée à res.send(). Cette méthode prend un objet JavaScript en argument et gère automatiquement la sérialisation en JSON et l'ajout de l'en-tête Content-Type.

On ne pourra jamais vous reprocher d'être trop précis concernant la qualité et la fiabilité des réponses renvoyées par l'API.

Afin d'améliorer la lisibilité et la cohérence des réponses, un module utilitaire est créé pour encapsuler les données dans une structure JSON standardisée, incluant un message explicatif en plus des données brutes. L'utilisation des fonctionnalités ES6 permet de rendre ce module extrêmement concis, fusionnant propriétés et valeurs si elles portent le même nom.

Les middlewares sont des fonctions JavaScript capables d'interagir avec les requêtes entrantes et sortantes de l'API REST avant qu'elles n'atteignent les points de terminaison finaux. Ils reçoivent les objets req, res et une fonction next() qui, lorsqu'elle est appelée, transfère le contrôle au middleware suivant dans la chaîne de traitement.

Un middleware personnalisé est créé pour logger l'URL de chaque requête entrante dans le terminal du serveur. Bien que fonctionnel, il est préférable d'utiliser des solutions existantes et éprouvées. Le paquet Morgan est installé comme dépendance de développement pour fournir un logging plus abouti et coloré des requêtes.

La puissance des middlewares réside dans leur capacité à être combinés en une chaîne de traitement. L'ordre d'appel via app.use() est crucial, car il détermine la séquence des traitements appliqués. L'appel à next() est obligatoire pour chaque fonction de traitement afin d'éviter que la requête ne reste bloquée.

L'objectif est d'implémenter les opérations CRUD (Create, Read, Update, Delete) sur les ressources Pokémon. L'ajout d'un nouveau Pokémon nécessite une requête HTTP de type POST sur l'URL de la collection (/api/pokemons), transportant les données du nouveau Pokémon au format JSON.

Un défi majeur lors de l'implémentation de POST est la génération d'un identifiant unique. Puisque la base de données n'est pas encore impliquée, une méthode utilitaire est développée dans le module lpr.js. Cette méthode calcule le maximum des IDs existants et y ajoute un, garantissant ainsi l'unicité locale.

C'est à la base de données de déterminer les identifiants uniques puisque elle seule a accès à l'ensemble des pokémons existants.

Lors de l'envoi de données POST via des outils comme Insomnia, le corps de la requête est reçu comme une chaîne de caractères brute par HTTP. Pour accéder aux propriétés des données, il est impératif de parser cette chaîne en objet JavaScript. Le middleware body-parser (ou l'équivalent Express) est introduit pour gérer cette conversion automatiquement.

La gestion des erreurs est divisée entre erreurs techniques (liées à la connexion DB, 500) et erreurs métier (spécifiques aux règles de l'application, comme un nombre de types invalide). Pour éviter d'interroger inutilement la base de données, les validateurs JavaScript sont préférés aux contraintes SQL pour les vérifications côté application.

L'intégration d'une base de données est nécessaire pour la persistance des données. L'installation de XAMPP fournit un environnement local incluant le serveur web Apache, la base de données MariaDB et l'interface de visualisation phpMyAdmin. Cependant, l'interaction directe avec phpMyAdmin est déconseillée pour les développeurs backend.

L'ORM (Object Relational Mapping) est une technique puissante qui masque la complexité du langage de requête SQL. Il permet d'interagir avec la base de données en manipulant des objets JavaScript, offrant une abstraction qui facilite le changement de système de base de données (MariaDB, PostgreSQL, etc.) sans réécrire les requêtes.

Sequelize est sélectionné comme ORM pour Node.js, car il est entièrement basé sur les Promesses JavaScript, gérant efficacement les traitements asynchrones. Pour que Sequelize puisse communiquer avec MariaDB (installé via XAMPP), le driver spécifique mysql2 doit être installé comme dépendance du projet.

La configuration de la connexion se fait dans sequelize.js, nécessitant les informations de connexion (nom de la DB, utilisateur, mot de passe, hôte) et le dialecte du driver. Une fois la connexion testée et la base de données pokédex créée via phpMyAdmin, la synchronisation des modèles Sequelize avec la base de données est lancée via sequelize.sync({ force: true }).

Le concept fondamental de Sequelize est le Modèle, qui est une abstraction JavaScript représentant une table dans la base de données sous-jacente. Un modèle Pokémon est déclaré dans src/models/pokemon.js, définissant ses propriétés (nom, HP, dégâts, etc.) avec leurs types de données et leurs configurations (clé primaire, nullité).

La méthode sequelize.define() crée le modèle. Elle prend le nom du modèle (qui sera pluriel pour la table, ex: pokemons), la description des propriétés, et des options globales. Les propriétés id et createdAt sont configurées pour gérer l'unicité et l'horodatage automatiquement, remplaçant ainsi la logique manuelle précédente.

Il est vraiment la bienvenue d'utiliser un ORM, car on peut interagir avec notre base de données sans connaître le langage de requête SQL.

Le fichier app.js devient surchargé en mélangeant l'initialisation du serveur, la connexion DB et la définition des routes. Une nouvelle architecture est mise en place : le fichier sequelize.js gère la connexion et l'exportation des modèles, tandis que chaque point de terminaison CRUD est déplacé dans son propre module dans le dossier src/routes.

La gestion des erreurs est cruciale pour la qualité d'une API REST. Les erreurs sont divisées entre erreurs de programmation (que l'on corrige localement) et erreurs opérationnelles (survenant lors de l'interaction client, comme des données invalides ou une ressource inexistante). Il est vital de retourner des codes de statut HTTP précis (400, 404, 500) plutôt que des erreurs génériques 500.

Express gère nativement les routes non trouvées avec un code 404, mais ce comportement par défaut manque de personnalisation. Un middleware spécifique doit être ajouté après toutes les déclarations de routes dans app.js. Ce middleware intercepte les requêtes non traitées et renvoie explicitement une réponse avec le statut 404.

Les appels à la base de données via Sequelize retournent des promesses. Il est nécessaire d'ajouter un bloc .catch() pour intercepter les échecs de connexion (retournant une erreur 500). Pour les opérations de modification ou suppression, l'utilisation de .then() suivi de .catch() permet de gérer les cas de succès et d'échec séparément.

L'erreur 404 indique que la page demandée n'a pas été trouvé. C'est ce fameux code 404 qu'on peut retrouver un peu partout.

Dans les points de terminaison update et delete, il est préférable de récupérer la ressource avant de la modifier/supprimer (en utilisant findByPk puis update ou destroy). Si la ressource n'est pas trouvée, une erreur 404 est retournée au client, assurant une réponse plus précise qu'une simple erreur 500 générique.

Pour appliquer des règles métier spécifiques qui ne sont pas couvertes par les contraintes SQL (comme vérifier la structure des types Pokémon), les validateurs personnalisés de Sequelize sont utilisés. Ces validateurs s'exécutent côté JavaScript, évitant des requêtes inutiles à la base de données et offrant une réponse plus rapide au client.

Des validateurs intégrés comme isInt et notNull sont appliqués aux champs numériques comme les points de vie. Pour gérer la chaîne vide, le validateur notEmpty est nécessaire, car notNull ne considère pas la chaîne vide comme nulle. Pour les types, un validateur personnalisé isTypesValid est créé pour vérifier que le nombre de types est compris entre 1 et 3, et que chaque type appartient à une liste prédéfinie.

Lorsque Sequelize lève une erreur de validation, il retourne une erreur technique 500 par défaut. Pour améliorer l'expérience utilisateur, il faut intercepter cette erreur dans le bloc .catch() des routes create et update. Si l'erreur est de type validation, le code de statut 400 est renvoyé, et le message spécifique du validateur est transmis au client.

Concernant les contraintes SQL (comme l'unicité du nom d'utilisateur), elles sont définies directement dans le modèle User via Sequelize. Si cette contrainte est enfreinte, Sequelize lève une erreur spécifique (UniqueConstraintError) qui doit être interceptée dans les routes concernées pour retourner un statut 400 avec un message clair, tel que « Le nom est déjà pris ».

Pour offrir une API plus élaborée, il est nécessaire de dépasser la simple récupération de la liste complète ou d'une ressource par ID. Les paramètres de requête (query parameters), ajoutés à la fin de l'URL (ex: ?name=bulbizarre), permettent d'affiner les résultats sans identifier une ressource spécifique, contrairement aux paramètres d'URL.

La recherche exacte par nom est trop restrictive. L'opérateur Op.like de Sequelize est introduit pour effectuer des recherches flexibles. En utilisant le symbole de pourcentage (%) dans la chaîne de recherche, il devient possible de trouver des Pokémon dont le nom contient un terme donné, offrant une meilleure expérience utilisateur.

L'opérateur LIKE de Sequelize permet de rechercher à tel ou tel endroit dans une des propriétés de nos modèles.

Pour optimiser les ressources, la fonctionnalité de limitation des résultats est implémentée en passant une option limit à la méthode Sequelize. De plus, la méthode findAndCountAll est utilisée à la place de findAll. Ceci permet de retourner à la fois la liste limitée des résultats et le nombre total de ressources disponibles en base de données, essentiel pour l'implémentation de la pagination côté frontend.

Le tri alphabétique croissant des résultats est ajouté en utilisant l'option order dans la requête Sequelize, assurant que les listes renvoyées sont toujours ordonnées par nom.

La sécurisation de l'API passe par deux exigences : le chiffrement des mots de passe et la sécurisation des échanges de données après authentification. Le standard JSON Web Token (JWT) est adopté pour gérer l'état d'authentification de manière stateless.

Le module bcrypt est installé pour hacher les mots de passe avant de les stocker en base de données. La méthode hash de bcrypt utilise un nombre de tours (salt rounds) pour augmenter la complexité du hachage. Seul le hachage est stocké, jamais le mot de passe en clair.

Un jeton JWT est généré lors de la connexion réussie, contenant l'ID utilisateur et une date de validité limitée (ex: 24 heures). Ce jeton est créé en utilisant la méthode sign du module jsonwebtoken, nécessitant une clé secrète externe pour le cryptage. Ensuite, un middleware d'authentification (auth.js) est créé pour vérifier la présence et la validité de ce jeton dans l'en-tête Authorization: Bearer [token] de chaque requête protégée.

Le middleware d'authentification est appliqué sélectivement aux routes nécessitant une protection (CRUD Pokémon), tout en laissant la route de connexion (/login) accessible publiquement.

Le déploiement en production implique de rendre l'API accessible sur le web, nécessitant l'hébergement du serveur Node.js et de la base de données sur une plateforme distante. Heroku est choisi pour sa gratuité initiale et son intégration avec les outils de développement modernes.

Le déploiement sur Heroku nécessite l'installation de Git pour le versionnage et de l'utilitaire Heroku CLI. Les variables d'environnement, accessibles via process.env, sont fondamentales pour adapter les configurations locales (port 3000) aux paramètres de production (port dynamique attribué par Heroku via process.env.PORT).

Un add-on Heroku (JawsDB Maria) est ajouté pour provisionner une base de données distante. Le fichier sequelize.js est modifié pour lire les identifiants de connexion de production à partir des variables d'environnement Heroku (URL de la DB). Il est crucial de retirer l'option force: true de sequelize.sync() pour éviter la suppression des données utilisateur à chaque redémarrage.

Le déploiement final s'effectue via les commandes Git et Heroku CLI, initialisant le dépôt et poussant le code vers le serveur distant. Un dernier point de terminaison public (/) est ajouté pour vérifier immédiatement que le serveur est en ligne.

L'étape finale consiste à connecter une application frontend (Native JS, React, Angular, Vue) à l'API REST déployée. La communication entre le frontend (hébergé sur une origine) et le backend (API) est soumise à la politique de sécurité des navigateurs, notamment la Same-Origin Policy.

Pour autoriser les requêtes cross-origin, le middleware cors est installé et utilisé dans app.js. Par défaut, il autorise la plupart des méthodes HTTP (GET, POST, PUT, DELETE) provenant de n'importe quelle origine, permettant ainsi aux applications frontend de communiquer avec l'API.

L'en-tête Access-Control-Allow-Origin est essentielle à la mise en place de la norme CORS et également la sécurité des ressources.

Les applications frontend doivent suivre un ordre chronologique : 1. Authentification (POST sur /login) pour obtenir le JWT. 2. Utilisation du jeton JWT dans l'en-tête Authorization pour accéder aux routes protégées (GET, POST, PUT, DELETE sur les Pokémon). Les requêtes sont effectuées en utilisant les API natives du navigateur (Fetch API) ou des librairies comme Axios (pour React/Vue) ou HttpClient (pour Angular).