3.2Moteurs de templates & service de fichiers
L'essentiel en 30 secondes
- Le statique se sert en une ligne : app.use(express.static('public')) livre CSS, images et JS client depuis un dossier dédié.
- Le dynamique se rend avec un moteur : templates EJS/Handlebars/Pug + res.render('vue', { données }) = HTML assemblé côté serveur (SSR).
- Deux architectures valables : SSR pour contenu et SEO, API JSON + front séparé pour applis interactives — les niveaux suivants penchent vers l'API.
Mini-cas filé — Salim publie le catalogue en SSR puis en API
Salim, développeur junior à Alger, doit publier le catalogue : fiches produits en HTML pour le référencement, plus un tableau de bord interne très interactif. Il sert d'abord le CSS et les images avec express.static('public'), configure EJS (app.set('view engine', 'ejs')) et rend res.render('produit', { produit }) pour les fiches SSR. Pour le tableau de bord, il expose les mêmes données en res.json() : le front dédié consommera l'API. Un seul serveur, deux rendus selon l'usage.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h.
1. Fichiers statiques & templates
Une appli web livre des ressources fixes (CSS, images, JS client, polices) : Express les sert avec le middleware natif express.static() — app.use(express.static('public')) expose tout le dossier public/ (une requête vers /style.css renvoie public/style.css). On regroupe les assets dans ce dossier dédié.
Pour le HTML dynamique, on utilise un moteur de templates : un gabarit (HTML + variables, boucles, conditions) rempli avec des données. Les courants : EJS (JS dans des balises <% %>, proche du HTML), Handlebars/hbs (syntaxe {{ }}, épurée), Pug (indentée, concise). On configure (app.set('view engine', 'ejs')), on range les vues dans views/, on rend avec res.render('page', { données }). C'est le SSR (Server-Side Rendering) : le serveur construit le HTML complet et l'envoie au navigateur.
2. SSR ou API + front séparé : arbitrer selon le projet
Le SSR convient aux sites de contenu (vitrines, blogs, e-commerce classique), au SEO (HTML prêt, bien indexable) et au chargement initial rapide. L'alternative moderne : Node expose une API REST en JSON (section 4-1) consommée par un front séparé (React, Vue, Angular) qui affiche côté navigateur — idéal pour les applis interactives (tableaux de bord, outils) et l'expérience fluide sans rechargement.
Les deux sont valables : Salim choisit SSR pour les fiches (contenu, SEO) et API + front pour le tableau de bord (interactivité). Et le SSR n'est pas dépassé : il revient en force via Next.js/Nuxt qui combinent rendu serveur et interactivité. Les niveaux suivants penchent vers l'approche API/JSON, dominante côté Node.
🔎 Exemple concret — Servir puis rendre, puis exposer en JSON
Salim couvre les trois sorties avec le même serveur.
app.use(express.static('public'));
app.set('view engine', 'ejs');
app.get('/produits/:id', (req, res) => {
res.render('produit', { produit: { id: req.params.id } });
});
app.get('/api/produits/:id', (req, res) => {
res.json({ id: req.params.id });
});Lecture : même donnée, deux rendus : HTML via EJS ou JSON via res.json().
Leçon : comparer les deux rendus fait sentir la différence SSR vs API.
Vocabulaire de la section
- Fichiers statiques
- Ressources fixes (CSS, images, JS client, polices) servies telles quelles par express.static('public').
Exemple simple : Le style.css de Salim servi depuis public/.
Ce que ce n'est pas : une vue EJS rendue avec des données.
Réflexe : regrouper tous les assets dans public/.
- Moteur de templates
- Outil générant du HTML dynamique depuis des gabarits (variables, boucles, conditions) : EJS, Handlebars, Pug.
Exemple simple : La fiche produit EJS de Salim bouclant sur les avis.
Ce que ce n'est pas : un simple dossier de fichiers fixes.
Réflexe : choisir EJS pour démarrer, proche du HTML.
- res.render()
- Méthode Express rendant une vue : res.render('page', { données }) injecte les données dans le template de views/.
Exemple simple : res.render('produit', { produit }) chez Salim.
Ce que ce n'est pas : un envoi de JSON brut au front.
Réflexe : nommer la vue comme le fichier de views/.
- SSR
- Server-Side Rendering : le serveur génère le HTML complet et l'envoie au navigateur ; atout contenu et SEO.
Exemple simple : Les fiches catalogue indexables de Salim.
Ce que ce n'est pas : une SPA qui rend tout dans le navigateur.
Réflexe : privilégier le SSR pour les pages à référencer.
- API + front séparé
- Node expose du JSON (API REST) consommé par un front React/Vue/Angular qui affiche côté navigateur.
Exemple simple : Le tableau de bord interne alimenté en res.json().
Ce que ce n'est pas : un template EJS rendu côté serveur.
Réflexe : réserver cette architecture aux applis interactives.
En pratique — Servir des fichiers et générer du HTML
- Servez des fichiers statiques avec app.use(express.static('public')) : placez un CSS et une image dans public/ et vérifiez qu'ils sont accessibles.
- Configurez un moteur de templates (ex. EJS : app.set('view engine', 'ejs')) et placez des templates dans views/.
- Rendez une vue avec des données : res.render('page', { titre: '...', items: [...] }) ; dans le template, insérez les variables et bouclez sur une liste.
- Comparez : rendez la même donnée en JSON (res.json(data), approche API) pour percevoir la différence SSR vs API + front séparé.
Script prêt à dire — justifier SSR vs API (30 s)
« Les fiches catalogue partent en SSR avec EJS : HTML complet, bon pour le SEO et le premier affichage. Le tableau de bord, très interactif, consomme la même donnée en JSON via notre API. Le statique CSS et images est servi par express.static depuis public. »
À dire en arbitrage d'archi ; montrer la même donnée en HTML puis en JSON.
Modèle copier-coller — statique + EJS + JSON
const express = require('express');
const path = require('path');
const app = express();
app.use(express.static('public'));
app.set('view engine', 'ejs');
app.set('views', path.join(__dirname, 'views'));
app.get('/produits/:id', (req, res) => {
res.render('produit', { id: req.params.id });
});
app.get('/api/produits/:id', (req, res) => {
res.json({ id: req.params.id });
});
app.listen(3000);Indépendant
Un site vitrine suffit en SSR + statique : pas de front lourd pour quelques pages.
PME à Alger
Salim rend les fiches en EJS pour le SEO et garde l'API JSON pour l'admin interne.
Équipe produit
Séparer views/ (SSR) et /api (JSON) pour que deux équipes avancent sans conflit.
Débutant
Cette semaine : un CSS servi en statique et une vue EJS avec une boucle sur trois items.
✓ Bonnes pratiques
- Servir les assets avec express.static (un dossier public/).
- Choisir l'architecture selon le projet (contenu/SEO vs app interactive).
- Maîtriser l'API REST (JSON) : approche dominante des niveaux suivants.
✗ Pièges fréquents
- Croire le SSR « dépassé » (il connaît un renouveau : Next.js/Nuxt).
- Choisir une SPA pour un simple site de contenu (complexité inutile).
- Négliger le SEO en architecture SPA pure.
Points clés à retenir
- SERVICE STATIQUE : app.use(express.static('public')) sert les ressources fixes (CSS, images, JS client).
- MOTEURS DE TEMPLATES (EJS, Handlebars, Pug) : HTML dynamique via res.render('vue', {données}).
- SSR : le serveur génère le HTML complet — approche des sites classiques (contenu, SEO).
- Alternative moderne très répandue : Node expose une API REST (JSON) consommée par un FRONT SÉPARÉ (React/Vue/Angular).
Défi 48h — appliquez demain
Servez 1 CSS en statique et rendez 1 vue EJS avec une boucle sur 3 items.
- Je sers un dossier public/ sans hésiter.
- Je rends une vue avec res.render().
- J'arbitre SSR vs API selon le projet.
Questions fréquentes
SSR (templates) ou API + front séparé : quelle architecture choisir ?
Les deux sont valables selon le projet. Le SSR convient aux sites de contenu (blogs, vitrines, e-commerce classique), quand le SEO compte (HTML livré prêt), pour un chargement initial rapide et les sites peu interactifs (plus simple). L'API + front séparé convient aux applis interactives (tableaux de bord, outils), à l'expérience fluide sans rechargement et à la séparation front/back. Salim panache : SSR pour les fiches, API pour le tableau de bord.
Le rendu côté serveur est-il dépassé face à React ?
Non, il connaît même un renouveau. Après l'ère SSR classique (templates EJS), puis l'engouement SPA (tout rendu côté client, avec ses limites SEO et chargement initial), des frameworks comme Next.js et Nuxt combinent les deux : HTML rendu serveur (SEO, rapidité) + interactivité client (expérience SPA). Le SSR classique reste pertinent pour de nombreux sites par sa simplicité.
Quelle méthode Express rend une vue avec des données ?