L'architecture full-stack complète

Objectifs

À la fin de cette leçon, vous saurez :

• décrire le chemin complet d'une donnée, du clic à PostgreSQL et retour ;
• identifier la responsabilité de chaque couche ;
• comprendre pourquoi cette application « vanilla » est votre référence permanente.

🔗 Pour vous rafraîchir la mémoire : Pool pg et requêtes paramétrées ($1, $2) · CRUD en SQL · méthodes HTTP et codes de statut

Le schéma directeur

Navigateur                    Serveur Node                 PostgreSQL
┌───────────────┐   HTTP    ┌──────────────────┐   SQL   ┌────────────┐
│ HTML/CSS/JS   │ ────────→ │ serveur http     │ ──────→ │ tables     │
│ fetch + DOM   │ ←──────── │ + routage        │ ←────── │ + index    │
└───────────────┘   JSON    │ + validation     │  lignes └────────────┘
                            └──────────────────┘

Chaque flèche est un chapitre que vous avez déjà fait : TCP/HTTP pour le transport, JSON pour le format, requêtes paramétrées pour la base.

Suivre une création de tâche bout en bout

1. L'utilisateur tape « Courses » et clique : événement JS (ch. 16).
2. fetch("/tasks", { method: "POST", body: ... }) : le navigateur ouvre une connexion TCP (ch. 9) et envoie du HTTP (ch. 11).
3. Le serveur reçoit le flux (ch. 19), collecte le corps, valide.
4. pool.query("INSERT ...", [...]) : le driver parle à PostgreSQL (ch. 22), contraintes vérifiées (ch. 20).
5. RETURNING * renvoie la ligne ; le serveur répond 201 + JSON.
6. Le frontend reçoit la Promise résolue (ch. 17), ajoute la ligne au DOM.

Six couches, zéro magie. Vous pouvez nommer chaque étape — c'est exactement l'objectif final du cursus (« expliquer entièrement le chemin »).

Qui sait quoi ? Les responsabilités

Couche	Sait	Ne doit pas savoir
Frontend	afficher, saisir, appeler des URLs	le SQL, les règles métier profondes
API	valider, décider, orchestrer	comment le navigateur affiche
Base	stocker, garantir cohérence/perf	le sens métier des données

La règle transversale : le serveur revalide tout. Le client peut être contourné avec curl ; la base ne voit que ce que l'API lui soumet. La validation vit donc aux trois étages, chacun selon ses moyens.

Ce découpage est aussi votre carte de diagnostic : quand « ça ne marche pas », la couche défaillante se localise par ses symptômes propres :

rien dans le réseau DevTools        → le frontend n'a pas appelé (bug JS)
requête rouge 4xx dans le réseau    → l'API a refusé : lire le corps de réponse
requête 5xx                         → l'API a planté : lire SES logs
API lente sur une route précise     → suspect n°1 : la requête SQL (EXPLAIN)

Chaque étage a ses outils d'inspection (DevTools / curl -v / logs / psql) — vous les avez tous appris ; il ne reste qu'à les associer à leur étage.

Pourquoi cette version vanilla est précieuse

Les prochains chapitres introduiront Express/NestJS (routing automatique), des ORM (SQL généré), Angular (DOM géré). Chacune de ces abstractions remplacera un mécanisme que vous venez d'écrire à la main :

• le routeur regex → décorateurs @Get/@Post ;
• db.js repository → ORM entities/repositories ;
• innerHTML render → templates déclaratifs.

Quand une abstraction échouera bizarrement, vous saurez remonter dessous : c'est le principe fondateur du cursus.

Exercice

1. Récitez le chemin complet d'un DELETE depuis le clic jusqu'au disque.
2. Où se situe la validation du titre ≤ 200 caractères dans chaque couche ?
3. Que perd-on si on supprime la couche repository ?

Résumé

• Navigateur → HTTP → Node → SQL → PostgreSQL → retour : le circuit complet maîtrisé.
• Trois couches, trois responsabilités ; validation redondante par sécurité.
• L'app vanilla = carte de référence de toutes les abstractions futures.