Validation du full-stack vanilla
Quatre épreuves pour valider le socle full-stack.
Objectifs
Une validation pratique : démontrer, sur votre propre application, que vous maîtrisez le chemin complet et les décisions de conception associées.
🔗 Pour vous rafraîchir la mémoire : en-têtes HTTP et JSON · curl pas à pas
Épreuve 1 — le chemin raconté
Écrivez (papier ou notes), sans consulter le code : le parcours complet d'une création de tâche, depuis la frappe clavier jusqu'au disque PostgreSQL, en nommant chaque couche, protocole et format. Comparez ensuite avec votre code réel.
Épreuve 2 — l'API résiste au curl
Passez cette batterie ; notez les codes obtenus puis justifiez chacun :
curl -X POST localhost:3000/tasks -H "Content-Type: application/json" \
-d '{"titre":""}' # attendu : ?
curl -X POST localhost:3000/tasks -H "Content-Type: application/json" \
-d '{"titre":"ok","user_id":9999}' # attendu : ?
curl -X PATCH localhost:3000/tasks/1 -d 'pas-du-json' # attendu : ?
curl -X DELETE localhost:3000/tasks/99999 # attendu : ?
Épreuve 3 — la panne maîtrisée
- Arrêtez PostgreSQL (
docker compose stop postgres). - Tentez une lecture via le frontend.
- Observez : quel état s'affiche ? Quel log côté serveur ? Quelle erreur SQL précise ?
- Redémarrez, vérifiez la reprise.
Épreuve 4 — la décision argumentée
Répondez par écrit :
- Pourquoi valider à trois niveaux alors qu'un seul suffirait « techniquement » ?
- Pourquoi le repository est-il isolé dans db.js ?
- Que se passerait-il si deux requêtes créent simultanément des tâches ? Pourquoi la base garantit-elle des ids uniques ?
Critères de réussite
- Le chemin complet est raconté sans erreur d'ordre ni d'étage.
- Chaque code HTTP observé correspond à la théorie du chapitre 11.
- La panne produit un message clair, pas un crash silencieux.
- Les trois questions de conception ont des réponses argumentées.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses attendues
Épreuve 2. Titre vide → 400 (validation). user_id inconnu → 400 traduit de la contrainte FK 23503. JSON cassé → 400 (catch du parse). Suppression inexistante → 404. Tout autre code mérite une investigation.
Question 1. Chaque niveau protège contre un adversaire différent : le client contre la maladresse (UX), l'API contre la malveillance (sécurité), la base contre les bugs de l'API elle-même. La redondance est le prix de la robustesse.
Question 2. Isolation = testabilité + évolutivité + lisibilité. Le jour où le SQL change (ou passe à un ORM), seul db.js bouge ; les tests du routeur tournent sans base.
Question 3. Deux INSERT concurrents obtiennent chacun leur id via la séquence de la colonne IDENTITY : le serveur PostgreSQL sérialise l'accès à la séquence en interne. Aucun doublon possible, aucune action de votre part — c'est exactement le type de garantie qui justifie d'utiliser une vraie base plutôt qu'un compteur JS partagé.
Si ces quatre épreuves passent, le cœur du cursus est acquis : tout ce qui suit (modules, npm, POO, TypeScript, frameworks) construit AUTOUR de ce socle.