Cómo fluye una solicitud

Ahora lo juntamos todo. Sigamos a nuestro usuario haciendo clic en "Guardar perfil" a través de cada pieza que acabas de conocer. Este es el modelo mental más útil de todo el libro; si interiorizas un solo diagrama, que sea este.

1. USER clicks "Save profile"
        │
        ▼
2. FRONTEND (HTML form, JavaScript reads the values)
        │   sends an HTTP request:  "POST /profile  { name: 'Ada' }"
        ▼
3. HOSTING routes the request to your running BACKEND
        │
        ▼
4. BACKEND
     ├─ is this user logged in?        (no  → respond 401, stop)
     ├─ is the data valid?             (no  → respond 400, stop)
     └─ all good → save to the DATABASE
        │
        ▼
5. DATABASE writes the row, confirms back to the BACKEND
        │
        ▼
6. BACKEND responds:  "200 OK  { saved: true }"
        │
        ▼
7. FRONTEND receives the response, updates the DOM
        │   ("Profile saved ✓") — the user sees it
        ▼
   DONE

Repasa lo que hizo cada capa: el frontend recopiló la entrada y la envió; el hosting llevó la solicitud al lugar correcto; el backend aplicó las reglas (inicio de sesión, validación) y decidió; la base de datos lo hizo permanente; y la respuesta fluyó de regreso hasta que el frontend pudo actualizar la pantalla. Toda aplicación es una variación de este ciclo, ejecutado miles de veces por segundo.

Nota que todas las verificaciones ocurren en el backend, nunca en el frontend — la regla de la primera sección, en acción: el frontend es para el usuario, el backend es para la verdad. Cuando sabes dónde ocurre cada paso, puedes describir una funcionalidad con precisión ("valida el correo en el backend antes de guardar") en lugar de vagamente ("haz que el formulario funcione") — y la precisión es todo el juego.