Connecter Node.js à une base MySQL pour fournir des données JSON
Dans l’article précédent, Créer un serveur Node.js local pour servir des fichiers statiques, nous avons mis en place un petit serveur Node capable de distribuer simplement les fichiers d’un dossier : une page HTML, une feuille de style, un script JavaScript. Ce premier serveur avait un objectif volontairement limité : comprendre comment Node peut agir comme un serveur HTTP minimal capable de livrer des fichiers au navigateur.
Dans un projet réel, le serveur ne se limite toutefois presque jamais à ce rôle. Très vite, l’interface d’un site a besoin d’accéder à des données dynamiques : une liste d’articles, des utilisateurs, des messages ou encore des résultats de recherche. Ces informations sont généralement stockées dans une base de données, et le serveur devient alors l’intermédiaire entre cette base et le navigateur.
Dans ce second volet, nous allons donc faire évoluer notre serveur Node afin qu’il puisse interroger une base MySQL et renvoyer ces données à l’application web. L’ensemble des fichiers nécessaires pour suivre les exemples sont disponibles sur ce lien, Node-Server-MySQL.zip.
Initialiser le projet Node
Avant d’installer le connecteur MySQL, il est important de rappeler un point de base : nous travaillons ici dans un projet Node.js, voir Prendre en main Node.js. Cela signifie que le dossier dans lequel nous développons doit normalement contenir un fichier package.json. Ce fichier joue un rôle central dans l’écosystème Node. Il décrit le projet, indique ses dépendances et permet à npm de gérer l’installation des modules nécessaires au fonctionnement de l’application.
Dans beaucoup de cas, ce fichier est déjà présent, notamment si vous avez suivi l’article précédent consacré à la mise en place du serveur Node minimal, puisque le projet a normalement été initialisé à ce moment-là. Mais si ce n’est pas le cas, il suffit de l’initialiser dans le dossier du projet à l’aide de la commande suivante :
npm init -yCette commande crée automatiquement un fichier package.json avec une configuration minimale. Celui-ci pourra ensuite être enrichi au fur et à mesure que le projet évolue. Un fichier package.json simple peut par exemple ressembler à ceci :
{
"name": "node-mysql-server",
"version": "1.0.0",
"description": "Serveur Node connecté à MySQL",
"main": "server.js",
"type": "module",
"scripts": {
"start": "node server.js"
}
}Une fois ce fichier en place, le projet est prêt à accueillir ses premières dépendances, notamment le connecteur MySQL que nous allons installer dans le chapitre suivant.
Un point mérite toutefois d’être anticipé. Dans les exemples de cet article, nous utilisons la syntaxe moderne import / export. Pour que Node l’accepte sans avertissement, la propriété suivante doit être présente dans package.json :
"type": "module"Sans cette indication, Node considère par défaut les fichiers .js comme des modules CommonJS et peut afficher un message indiquant que le type de module n’est pas précisé.
Enfin, lorsqu’on modifie manuellement le fichier package.json, il ne faut pas oublier que le projet contient aussi un fichier package-lock.json. Celui‑ci enregistre les versions exactes des dépendances installées. En pratique, il suffit généralement d’exécuter à nouveau une commande npm (par exemple npm install) pour que ce fichier soit automatiquement synchronisé avec package.json. Cette étape évite les incohérences entre les dépendances déclarées et celles réellement installées dans le projet.
Installer le connecteur MySQL pour Node.js
Contrairement à certains environnements serveur plus anciens, Node.js ne possède pas de connecteur MySQL intégré. Le moteur fournit les outils nécessaires pour créer un serveur, gérer des fichiers ou manipuler le réseau, mais il ne sait pas, par défaut, dialoguer directement avec une base de données MySQL. Pour établir cette communication, nous devons donc installer un module externe qui jouera le rôle d’intermédiaire entre Node et le moteur de base de données.
Dans l’écosystème Node, deux modules sont historiquement utilisés pour cela. Le premier est le module mysql. Il a longtemps été le connecteur de référence et reste encore présent dans de nombreux projets existants. Le second, mysql2, est une évolution plus récente. Il reprend la logique du premier tout en apportant de meilleures performances, une maintenance plus active et une compatibilité plus large avec les fonctionnalités modernes de MySQL. Dans la plupart des projets actuels, c’est donc mysql2 qui est privilégié. L’installation se fait simplement depuis le terminal, dans le dossier du projet :
npm install mysql2Cette commande télécharge le module depuis le registre npm et l’ajoute automatiquement aux dépendances du projet dans le fichier package.json. Depuis plusieurs versions de npm, cette mise à jour se fait sans instruction supplémentaire : il n’est plus nécessaire d’utiliser l’ancienne option --save, autrefois obligatoire pour enregistrer une dépendance dans le projet. À partir de ce moment, Node pourra charger ce connecteur et l’utiliser pour ouvrir une connexion vers une base MySQL, envoyer des requêtes SQL et récupérer les résultats.
Préparer une base de données d’exemple
Pour illustrer la connexion entre Node.js et MySQL, nous allons utiliser une petite base inspirée de l’univers krautrock. L’objectif n’est pas seulement d’avoir quelques lignes de données, mais de disposer d’une structure relationnelle simple, avec deux tables liées entre elles. Nous allons donc créer :
- une table
tab_bandspour les groupes - une table
tab_albumspour les albums
Chaque album sera rattaché à un groupe grâce au champ ch_album_band_id. Si la création d’une base ou la gestion des relations vous est encore peu familière, vous pouvez consulter ces deux articles qui expliquent la démarche pas à pas dans phpMyAdmin, Démarrer avec PHPMyAdmin : Création de votre Première Base de Données et en complément Relier nos tables dans PHPMyAdmin : organiser des données cohérentes. Créons donc une base nommée :
Création de la base et des tables
Avant de connecter notre serveur Node à MySQL, nous allons préparer une petite base de données qui servira de terrain d’expérimentation. L’idée n’est pas de construire un modèle complexe, mais de disposer d’une structure suffisamment claire pour comprendre comment une API peut récupérer des données relationnelles. Nous allons donc créer une base nommée :
krautrock
Dans cette base, nous définirons ensuite deux tables : l’une pour les groupes et l’autre pour les albums. Les fragments SQL qui suivent peuvent être exécutés dans phpMyAdmin ou dans n’importe quel client MySQL afin de mettre en place cette structure.
Création des tables
Prenons quelques instants avant de revenir à l’idée générale. Nous allons créer une structure volontairement très simple, suffisante pour tester notre API. L’important est surtout d’illustrer une relation 1 vers n : un groupe peut avoir plusieurs albums. Les champs sont donc réduits au minimum, afin de rester concentré sur la connexion entre Node.js et MySQL.
Structure de la table des groupes :
CREATE TABLE tab_bands (
ch_band_id INT AUTO_INCREMENT PRIMARY KEY,
ch_band_label VARCHAR(150) NOT NULL,
ch_band_image VARCHAR(255),
ch_band_etat TINYINT DEFAULT 1
);Structure de la table des albums :
CREATE TABLE tab_albums (
ch_album_id INT AUTO_INCREMENT PRIMARY KEY,
ch_album_band_id INT NOT NULL,
ch_album_label VARCHAR(150) NOT NULL,
ch_album_pochette VARCHAR(255),
ch_album_year VARCHAR(4),
ch_album_link VARCHAR(255),
ch_album_etat TINYINT DEFAULT 1,
CONSTRAINT fk_album_band
FOREIGN KEY (ch_album_band_id)
REFERENCES tab_bands(ch_band_id)
);Insertion des données
La structure de la base étant maintenant en place, nous pouvons insérer quelques données. L’objectif reste simplement d’obtenir un petit jeu d’essai qui permettra de vérifier que notre API Node est capable de récupérer des informations depuis MySQL. Nous allons donc ajouter quelques groupes, puis quelques albums. Les albums seront reliés aux groupes grâce au champ ch_album_band_id, ce qui permet d’illustrer la relation 1 groupe → plusieurs albums.
Insertion de quelques groupes
INSERT INTO tab_bands (ch_band_label, ch_band_image) VALUES
('Can','can.jpg'),
('Neu!','neu.jpg'),
('Kraftwerk','kraftwerk.jpg'),
('Faust','faust.jpg');Insertion de quelques albums
INSERT INTO tab_albums (ch_album_band_id, ch_album_label, ch_album_pochette, ch_album_annee, ch_album_link, ch_album_etat) VALUES
(1,'Tago Mago','tago-mago.jpg',1971,'https://www.youtube.com/watch?v=-Ap84WIErmA',1),
(1,'Future Days','future-days.jpg',1973,'https://www.youtube.com/watch?v=wQxMB4Wk_y8',0),
(2,'Neu!','neu.webp',1972,'https://www.youtube.com/watch?v=vQCTTvUqhOQ',0),
(2,'Neu! 2','neu-2.jpg',1973,'https://www.youtube.com/watch?v=V85AjBFDmbI',0),
(3,'Autobahn','autobahn.webp',1974,'https://www.youtube.com/watch?v=WxFVhBwGr7U',1),
(3,'Trans-Europe Express','trans-europe-express.jpg',1977,'https://www.youtube.com/watch?v=Ms6kC-3yq0k',1),
(4,'Faust IV','faust-iv.webp',1973,'https://www.youtube.com/watch?v=m5-_c2VFxhQ',1),
(4,'Faust So Far','faust-so-far.webp',1972,'https://www.youtube.com/watch?v=8Z4ahue-pSo',0);Nous disposons maintenant d’une petite base cohérente contenant quelques groupes et leurs albums. Ce jeu de données reste volontairement simple, mais il suffit pour vérifier que notre serveur Node est capable d’interroger MySQL et de récupérer des informations relationnelles que nous pourrons ensuite exploiter dans notre interface.
Organisation possible du projet
À ce stade, nous allons introduire plusieurs éléments : le serveur lui‑même, une connexion à la base de données, des fichiers HTML destinés au navigateur et, un peu plus loin, des modules API. Avant d’ajouter ces fichiers, il est utile de se donner une organisation claire du projet. Cela permettra de savoir où placer chaque élément au moment où nous les créerons : le code serveur, les fichiers publics et les futures routes API. Une structure possible pourrait donc ressembler à ceci :
project
│
├── server.js
├── db.js
│
├── api
│ └── albums.js
│
├── public
│ ├── index.html
│ ├── script.js
│
└── package.jsonCréer une connexion MySQL dans Node
À ce stade, il s’agit simplement d’établir la connexion entre Node et la base de données. L’idée est simple : notre serveur Node doit connaître les informations nécessaires pour accéder à MySQL afin de pouvoir exécuter des requêtes et récupérer les données. Pour cela, nous allons créer un petit fichier dédié à cette configuration. Dans beaucoup de projets, cette connexion est isolée dans un fichier séparé afin de ne pas répéter les paramètres à plusieurs endroits dans le code. Créer donc un fichier nommé db.js.
// db.js
import mysql from 'mysql2';
export const db = mysql.createConnection({
host: 'localhost',
user: 'root',
password: '',
database: 'krautrock'
});Chaque propriété décrite dans ce fichier correspond à un des éléments nécessaire pour la connexion à la base de données :
- host indique l’adresse du serveur MySQL. Dans un environnement local, on utilise généralement
localhost. - user correspond à l’utilisateur autorisé à accéder à la base.
- password est le mot de passe associé à cet utilisateur.
- database est simplement le nom de la base que nous avons créée précédemment.
Dans beaucoup d’installations locales (par exemple avec XAMPP, MAMP ou un serveur MySQL installé sur la machine), l’utilisateur par défaut est souvent root avec un mot de passe vide (''). C’est la raison pour laquelle nous utilisons ici cette configuration minimale.
Dans un projet réel ou sur un serveur de production, on utiliserait bien entendu un utilisateur dédié avec un mot de passe sécurisé et des droits limités. Pour l’instant, l’objectif est simplement de comprendre le mécanisme de connexion entre Node et MySQL, sans entrer dans les aspects plus avancés de sécurité ou de gestion des accès.
Le fichier server.js : point de départ du serveur
Dans l’article précédent consacré au serveur Node minimal, nous avons créé un fichier server.js. C’est ce fichier qui lance le serveur HTTP et qui reçoit les requêtes envoyées par le navigateur. Pour la suite de cet article, il n’est pas nécessaire de repartir de zéro : le même fichier peut être réutilisé. L’idée consiste simplement à l’enrichir progressivement.
Dans sa version minimale, ce script se contente simplement d’écouter un port et d’accepter les requêtes du navigateur. Pour les premiers essais, il n’est pas nécessaire de gérer tous les aspects d’un vrai serveur web (types MIME, gestion complète des routes, etc.). Comme l’objectif est seulement de vérifier que l’API fonctionne et que les données arrivent bien côté navigateur, un serveur très simple suffit. Voici par exemple une version minimale possible du fichier server.js :
// server_01.js minimal à améliorer au fur et à mesure des besoins
import http from 'http';
const server = http.createServer((req, res) => {
res.end('Serveur Node actif');
});
server.listen(3000, () => {
console.log('Serveur lancé sur http://localhost:3000');
});Ce script fait seulement trois choses :
- il crée un serveur HTTP avec le module
httpde Node ; - il écoute les requêtes envoyées par le navigateur ;
- il démarre le serveur sur le port 3000.
Pour lancer ce serveur, il suffit ensuite d’exécuter le fichier avec Node depuis le terminal, à la racine du projet :
node server.jsSi le script start est présent dans le fichier package.json, on peut aussi utiliser :
npm startLe message affiché dans la console confirme alors que le serveur est actif. Il devient possible d’ouvrir un navigateur et d’accéder à l’adresse indiquée.

À partir de cette base très simple, il devient ensuite possible d’ajouter progressivement des fonctionnalités, notamment la route /api/albums qui permettra d’interroger la base MySQL. Nous allons donc partir de cette base minimaliste et ajouter progressivement de nouvelles fonctionnalités, notamment la route API qui permettra d’interroger la base MySQL.
Créer une première route API
À ce stade, le serveur Node est capable de fonctionner, mais il ne fait encore qu’une chose très simple : répondre à toutes les requêtes de la même manière. L’étape suivante consiste à lui apprendre à réagir différemment selon l’URL demandée. Dans notre cas, nous allons créer une petite route API qui permettra de récupérer les albums enregistrés dans la base de données. Cette route sera accessible à l’adresse suivante :
/api/albumsLorsqu’un navigateur, un script JavaScript ou un outil comme curl appelle cette URL, le serveur Node va interroger MySQL puis renvoyer les résultats. Voici une version volontairement simple du code à ajouter dans server.js :
// server_02.js
import http from 'http';
import { db } from './db.js'; // import de la connexion MySQL définie dans db.js
// Création du serveur HTTP
const server = http.createServer((req, res) => {
// Si l'URL demandée par le navigateur correspond à /api/albums
if (req.url === '/api/albums') {
// Exécution d'une requête SQL sur la base de données
// db.query envoie la requête à MySQL
db.query('SELECT * FROM tab_albums', (err, results) => {
// Si une erreur se produit pendant la requête
if (err) {
// On renvoie un code HTTP 500 (erreur serveur)
res.writeHead(500);
// Message simple envoyé au navigateur
res.end('Erreur serveur');
// On arrête l'exécution du code
return;
}
// Si tout se passe bien, on renvoie un code HTTP 200
// et on précise que la réponse sera au format JSON
res.writeHead(200, {
'Content-Type': 'application/json'
});
// Les résultats SQL sont convertis en JSON
// puis envoyés au navigateur
res.end(JSON.stringify(results));
});
// Empêche le serveur de continuer à traiter la requête
return;
}
});
// Démarrage du serveur sur le port 3000
server.listen(3000, () => {
console.log('Serveur lancé sur http://localhost:3000');
});Cette petite portion de code constitue déjà une API minimale : une adresse web capable de produire des données dynamiques à partir d’une base de données.
Tester l’API depuis le navigateur
À ce stade, tout est en place : le serveur Node fonctionne, la connexion à MySQL est active et la route /api/albums existe dans notre fichier server.js. Il est donc temps de vérifier concrètement ce qu’il se passe lorsque l’on appelle cette adresse depuis un navigateur. Lorsque vous saisissez l’URL suivante :
http://localhost:3000/api/albumsplusieurs étapes se produisent en réalité :
- Le navigateur envoie une requête HTTP vers le serveur Node.
- Cette requête est capturée par le module
httputilisé dansserver.js. - Le code du serveur analyse l’URL demandée (
req.url). - Si l’URL correspond à
/api/albums, la requête SQL est exécutée via la connexion définie dansdb.js. - Les résultats renvoyés par MySQL sont convertis en JSON puis retournés au navigateur.
Autrement dit, deux éléments absorbent l’essentiel du travail technique :
- le module
httpde Node, qui gère la requête HTTP ; - la connexion MySQL définie dans
db.js, qui se charge de dialoguer avec la base.
Redémarrer le serveur après modification
Un point pratique mérite d’être rappelé : lorsque vous modifiez le fichier server.js, le serveur déjà lancé ne recharge pas automatiquement le code. Il faut donc :
- arrêter le serveur dans le terminal avec Ctrl + C ;
- relancer le script :
node server.js
Ce redémarrage permet de prendre en compte les modifications apportées au fichier.
Ce que l’on observe dans le navigateur

Si tout fonctionne correctement, le navigateur ne va pas afficher une page HTML classique. L’adresse /api/albums renvoie simplement des données JSON. Selon le navigateur, ces données peuvent apparaître comme un texte brut. Dans beaucoup de cas, l’endroit le plus intéressant pour observer la requête reste les outils de développement du navigateur.
Dans les DevTools :
- ouvrir l’onglet Network ;
- recharger la page ;
- sélectionner la requête
/api/albums.
On peut alors voir :
- dans l’onglet Headers, la requête HTTP envoyée par le navigateur ainsi que les informations de réponse du serveur ;
- toujours dans Headers, le code de statut retourné par le serveur (par exemple
200 OK) ; - dans l’onglet Preview ou Response, les données JSON renvoyées par l’API.

Ce comportement est normal : une API n’est pas conçue pour afficher directement une interface visuelle. Son rôle consiste uniquement à fournir des données que d’autres scripts (par exemple JavaScript dans une page HTML) pourront ensuite exploiter.
Récupérer les données depuis un fichier HTML
Jusqu’ici, nous avons surtout vérifié que la route /api/albums répond bien côté serveur. C’est une étape utile, mais dans un projet web, le but n’est pas de laisser une URL JSON seule dans le navigateur. L’idée consiste plutôt à charger une page HTML, y rattacher un script JavaScript, puis demander à ce script de récupérer les données de l’API pour les afficher dans la page.
Pour cette démonstration, inutile de construire une interface complexe. Une page HTML minimale suffit, avec une zone destinée à recevoir le résultat. Nous allons simplement créer une balise div portant l’identifiant resultats, puis laisser JavaScript y injecter le contenu récupéré depuis l’API. Voici un exemple très simple de fichier index.html :
<!-- index.html -->
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Albums krautrock</title>
</head>
<body>
<h1>Albums krautrock</h1>
<div id="resultats"></div>
<script src="script.js"></script>
</body>
</html>Dans cet exemple, il n’est pas nécessaire d’utiliser un script de type module. Le fichier script.js reste ici très simple, et un chargement classique suffit. Si l’on souhaitait plus tard utiliser import et export côté navigateur, il faudrait alors écrire :
<script type="module" src="script.js"></script>Mais pour cette première récupération de données, restons sur la version la plus directe. Côté JavaScript, il faut maintenant appeler l’API puis afficher le résultat dans la balise div#resultats. Voici un fragment minimal possible pour le fichier script.js. Le principe reste simple. Le navigateur charge d’abord la page HTML. Ensuite, le fichier script.js s’exécute. Ce script envoie une requête vers /api/albums, récupère la réponse JSON, puis l’insère dans la zone prévue dans la page.
document.addEventListener('DOMContentLoaded', () => {
fetch('/api/albums')
.then(response => response.json())
.then(data => {
const zone = document.getElementById('resultats');
// création d'une liste HTML
const liste = document.createElement('ul');
// parcours des albums renvoyés par l'API
data.forEach(album => {
const li = document.createElement('li');
// lien vers l'écoute de l'album
const lien = document.createElement('a');
lien.href = album.ch_album_link;
lien.textContent = album.ch_album_label;
lien.target = '_blank';
li.appendChild(lien);
liste.appendChild(li);
});
zone.appendChild(liste);
})
.catch(error => {
console.error('Erreur lors du chargement des albums :', error);
});
});Pour une première vérification, cette approche est déjà suffisante. Elle permet de constater que les données ne transitent pas seulement dans l’onglet Network des DevTools, mais qu’elles peuvent aussi être récupérées et réinjectées concrètement dans le HTML.
Servir les fichiers HTML et JavaScript avant d’invoquer l’API
Seulement pour l’instant, notre serveur ne fait qu’une chose : répondre à l’URL /api/albums. Cela fonctionne pour tester l’API directement, mais dès que nous allons ouvrir http://localhost:3000/, le navigateur attendra une réponse… qui n’arrivera jamais. En fait, le serveur reçoit bien la requête, mais aucune instruction ne lui indique quoi renvoyer pour la racine / ou pour les autres fichiers du dossier public.
Afin de prendre en compte ce type de requête, il nous faut donc ajouter une étape intermédiaire dans server.js pour permettre au serveur de servir les fichiers statiques (HTML et JavaScript, voir CSS) présents dans le dossier public. Concrètement :
- lorsque le navigateur demande
/, le serveur doit renvoyerpublic/index.html; - lorsqu’il demande
script.js, ou tout autres fichiers, il doit renvoyerpublic/lefichierdemandé.
Adaptons notre fichier server.js afin qu’il soit capable de gérer à la fois les fichiers statiques et la route API :
// server_03.js
import http from 'http';
import fs from 'fs';
import path from 'path';
import { db } from './db.js';
const root = path.resolve('./public');
const server = http.createServer((req, res) => {
// --- ROUTE API ---
if (req.url === '/api/albums') {
db.query('SELECT * FROM tab_albums', (err, results) => {
if (err) {
res.writeHead(500);
res.end('Erreur serveur');
return;
}
res.writeHead(200, {
'Content-Type': 'application/json'
});
res.end(JSON.stringify(results));
});
return;
}
// --- FICHIERS STATIQUES ---
const target = req.url === '/' ? 'index.html' : req.url;
const filePath = path.join(root, target);
fs.readFile(filePath, (err, content) => {
if (err) {
res.writeHead(404);
res.end('Fichier non trouvé');
return;
}
res.writeHead(200);
res.end(content);
});
});
server.listen(3000, () => {
console.log('Serveur lancé sur http://localhost:3000');
});Avec cette organisation :
- la route
/api/albumscontinue toujours de produire du JSON ; - toutes les autres requêtes servent simplement les fichiers présents dans
public.
Cela signifie que :
http://localhost:3000/renvoie index.html ;http://localhost:3000/script.jsrenvoie script.js ;- la page HTML peut ensuite appeler l’API
/api/albums.
Comme à chaque modification du fichier server.js, il faut arrêter puis relancer le serveur pour que Node prenne en compte les changements :
Ctrl + C
node server.jsUne fois redémarré, la page HTML se charge normalement, puis le script JavaScript peut appeler l’API et afficher les données dans la page.

Séparer le serveur statique et l’API
Dans une petite expérimentation, tout pourrait être placé dans un seul fichier. Pourtant, dès qu’un projet commence à évoluer, il devient utile de séparer les responsabilités. Un même serveur Node peut en effet jouer plusieurs rôles en parallèle. Il peut servir les fichiers nécessaires à l’interface du site, répondre à des requêtes provenant du navigateur et interroger une base de données pour produire des réponses dynamiques. Concrètement, cela signifie que :
- le serveur peut servir des fichiers statiques, comme une page HTML, une feuille CSS ou un script JavaScript placés dans le dossier
public; - il peut aussi répondre à des routes API, comme
/api/albums, qui ne correspondent pas à un fichier mais à du code exécuté côté serveur ; - enfin, ces routes peuvent interroger une base de données, récupérer des informations puis les renvoyer au navigateur sous forme de JSON.
Cette séparation entre serveur statique et API est très courante dans les architectures web modernes. Elle permet de garder une organisation claire : l’interface utilisateur d’un côté, la logique d’accès aux données de l’autre.
Dans notre exemple, la page HTML et le JavaScript vivent dans le dossier public. Pour éviter que le fichier server.js ne devienne trop volumineux, il est également possible de déplacer la logique des routes API dans un dossier api. Chaque route peut alors être définie dans un fichier dédié (par exemple api/albums.js). Le fichier server.js se contente alors d’importer ces modules et de leur déléguer le traitement des requêtes, ce qui permet de garder un point d’entrée central tout en répartissant le code de l’API dans des fichiers plus lisibles et plus faciles à maintenir.
Concrètement, le fichier server.js peut alors être légèrement adapté afin d’importer la route définie dans api/albums.js et de lui transmettre la requête lorsqu’elle correspond à l’URL /api/albums :
// server_04.js
import http from 'http';
import fs from 'fs';
import path from 'path';
import albumsRoute from './api/albums.js';
const root = path.resolve('./public');
const server = http.createServer((req, res) => {
// délégation de la route API
if (req.url === '/api/albums') {
return albumsRoute(req, res);
}
// gestion des fichiers statiques
const target = req.url === '/' ? 'index.html' : req.url;
const filePath = path.join(root, target);
fs.readFile(filePath, (err, content) => {
if (err) {
res.writeHead(404);
res.end('Fichier non trouvé');
return;
}
res.writeHead(200);
res.end(content);
});
});
server.listen(3000, () => {
console.log('Serveur lancé sur http://localhost:3000');
});La logique de la requête SQL et de la réponse JSON peut alors être déplacée dans le fichier api/albums.js, ce qui permet de garder un fichier server.js plus court et plus lisible.

Conclusion
Le serveur que nous avons construit ne se contente plus de renvoyer des fichiers : il devient un point d’accès aux données. À travers une route simple comme /api/albums, il expose une information structurée que n’importe quelle interface peut venir consommer.
Avec une page HTML et quelques lignes de JavaScript, le dialogue s’installe : le navigateur interroge, le serveur répond, et les données prennent forme côté interface. Cette étape pose les bases essentielles : comprendre où sont les données, comment on les appelle, et comment elles circulent.
À ce stade, l’objectif est atteint. Le mécanisme est en place, lisible, fonctionnel. Mais on sent aussi qu’il peut être affiné : enrichir les requêtes SQL, rendre les appels plus dynamiques, structurer davantage le serveur, améliorer le rendu côté interface. C’est ce que nous vous proposons d’explorer dans notre prochain article Node.js : de la requête simple à une API plus souple, jointures, paramètres et affichage dynamique.
