C6 · Java ↔ Express Comparison: It was like building the same `/api/v1/bugs` restaurant with two different teams: the Spring Boot team arrived with a **ready-made brigade system*
It was like building the same `/api/v1/bugs` restaurant with two different teams: the Spring Boot team arrived with a **ready-made brigade system** (every chef's role pre-assigned via annotations — the starter, `@Valid`, `@RestControllerAdvice`); the Express team was like a **freelance chef** — nothing was imposed, you built every step by hand (middleware order, validation library, error handler). Is this "freedom" really an advantage? For small, fast prototypes, YES — less code, fewer decisions; but as you saw in C3-C5 (middleware order, reading a validation result, error handler position), every "hand-built" step is also a step that can be "hand-forgotten" — in Spring the framework remembers FOR you, in Express YOU remember. This is not a "which is better" question, it is a **"whose responsibility is this bug"** question — and for a tester it becomes "which silent bug is COMMON in this framework": in Spring it is a missing annotation/dependency, in Express it is the wrong ORDER.
Three Frameworks, One Contract
🎬 Three Kitchens, One Menu
The same POST request
Spring: @Valid automatic
Express: hand-ordered chain
Nest: decorator + pipe
The same JSON contract
The same `POST /api/v1/bugs { "title": "" }` request is sent to three different servers.
Spring: `@Valid` is triggered automatically by the framework, 400 is returned — the developer writes no extra code.
Express: validation returns 400 only if `validationResult(req)` is READ — if not, 201 leaks through.
Nest: if `ValidationPipe` is registered GLOBALLY, DTO decorators run automatically — if not, decorators are just decoration.
The lesson — all three target the SAME contract (400 + error message), but the "automatic vs. manual" axis differs. In every framework, a tester asks "is this safeguard REALLY triggered?"