Tres horas. Media hora para aprender a diagnosticar cuando no hay interfaz que mirar, y dos horas y media montando un servicio nuevo, reparando uno roto y cerrando la entrega.
Hoy · Hoja de ruta
- 1. Aprende: En qué orden se monta un servicio, cómo se localiza el lado del fallo cuando hay dos consolas, y qué se revisa en un proyecto de servidor antes de entregarlo.
- 2. Haz: Construye un servidor para un dominio que no has visto, repara uno con cinco fallos y audita el tuyo y el de un compañero.
- 3. Entrega: El repositorio completo con su README, su fichero de peticiones y las tres listas de auditoría.
Antes de empezar · 5 minutos, sin apuntes
- ¿En qué orden montarías un servicio nuevo: las rutas o el almacén?
- Si el navegador muestra un error, ¿cómo sabes si el fallo es del cliente o del servidor?
- ¿Cómo demuestras que tu servidor funciona sin abrir el navegador?
Se explica
25 minutos · conceptos y demostración
Hoy no entra nada nuevo del lenguaje ni del framework. Entran dos habilidades: montar un servicio en el orden correcto, y encontrar un fallo cuando la pantalla no te enseña nada.
El orden de montaje
- Modelar los datos y sembrar el fichero JSON
- El almacén con sus operaciones
- Las reglas de negocio, sin saber de HTTP
- Las rutas, con sus códigos de estado
- Registro, errores centralizados y estáticos
- El fichero de peticiones que lo demuestra
Empezar por las rutas es la tentación, porque es la parte que se ve. El problema es que entonces las reglas de negocio acaban escritas dentro de los manejadores, y ahí no se pueden probar ni reutilizar. La capa de HTTP es la última porque es la más superficial.
Dos consolas, y hay que mirar la correcta
- ¿Sale la petición? Pestaña Network del navegador
- ¿Llega al servidor? Tu registro de peticiones
- ¿Qué estado devuelve? 4xx es del cliente, 5xx es tuyo
- ¿Qué dice la terminal? Ahí está la traza
Ese registro de la sesión 5 deja de ser un adorno: es lo que separa «no llega la petición» de «llega y falla», que es la misma pregunta de la UD4 trasladada al servidor.
node --inspect src/servidor.jsCon el servidor arrancado así, puedes conectar DevTools o el depurador de VS Code y poner puntos de interrupción en tu código de servidor: mismo depurador, mismo procedimiento que en la UD3.
| Síntoma | Causa habitual |
|---|---|
El servidor no arranca, EADDRINUSE |
Otro proceso tuyo sigue vivo en ese puerto |
| Todo devuelve 404 | El orden de las declaraciones, o la ruta mal escrita |
peticion.body es undefined |
Falta express.json(), o va después de la ruta |
| La petición se queda colgada | Un middleware sin next ni respuesta |
| «Cabeceras ya enviadas» | Se respondió dos veces: falta un return |
| Los cambios no se aplican | El servidor no se ha reiniciado |
| El módulo del cliente no se ejecuta | Tipo de contenido incorrecto en el estático |
Reproduce sin navegador
Antes de investigar, repite la petición con tu cliente HTTP. Si desde ahí funciona, el problema está en el cliente y no en el servidor; si falla igual, has eliminado media docena de variables de un golpe.
Revisar un servidor ajeno
La revisión de hoy empieza sin leer una línea de código, y los cuatro primeros puntos no lo necesitan:
- Clonarlo, instalar y arrancarlo. Anotar cada tropiezo.
- Ejecutar su fichero de peticiones y comprobar que hace lo que dice.
- Enviar datos inválidos y mirar qué responde.
- Pedir un fichero fuera de la carpeta pública y comprobar si se defiende.
- Señalar una decisión bien tomada y una mejorable, con su razón.
Si el primer punto falla, ese es el hallazgo más valioso que le puedes devolver: un proyecto que no arranca desde una instalación limpia no está terminado, por bien escrito que esté por dentro.
Se trabaja
150 minutos · servicio nuevo, servidor roto y cierre del proyecto
El primer paso no cabe entero en su hora, y no se pretende: lo que se evalúa es que el método sea tuyo, y eso se ve en el modelado y en las dos primeras rutas.
Paso 1 · Otro servicio · 50 min
Recibirás un dominio distinto del tuyo —reservas de aulas, préstamos de una biblioteca, incidencias de un taller— con sus reglas propias, al menos una de las cuales no se resuelve con un CRUD elemental: no se puede reservar un aula ocupada, no se presta un ejemplar ya prestado.
Sigue el orden de montaje de la explicación. En la sesión:
- Modela los datos y siembra el fichero JSON.
- Escribe el almacén con sus operaciones.
- Escribe la regla de negocio fuera de las rutas, sin que sepa nada de HTTP.
- Deja funcionando las dos primeras rutas con sus códigos.
- Empieza el
peticiones.httpcon los casos de esas dos.
El resto se termina como trabajo personal y se entrega con la unidad, con estos requisitos:
Lo que hay que entregar del servicio
- Cinco rutas, con al menos un
POSTy unDELETE. - Validación de entrada con respuesta 400 y lista de errores.
- La regla de negocio del enunciado, con su código de estado propio.
- Escritura segura en el fichero de datos.
- Registro de peticiones y manejador de errores central.
- Un
peticiones.httpque recorra todos los casos, incluidos los que fallan. - Un README con cómo arrancarlo y qué rutas ofrece.
La regla de negocio tiene truco: decide qué código de estado merece intentar reservar un aula ocupada. No es un 400 ni un 404, y la respuesta está en la tabla de la sesión 4.
Paso 2 · El servidor roto · 40 min
Recibirás un proyecto con cinco fallos, uno de cada familia de la tabla. Para cada uno:
| Fallo | Síntoma exacto | ¿Cliente o servidor? | Cómo lo supiste | Hipótesis | Corrección |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 4 | |||||
| 5 |
Rellena las cuatro primeras columnas antes de tocar nada. La tercera es la que se evalúa: decir si el fallo está en el cliente o en el servidor, y por qué lo sabes, es el 80 % del diagnóstico.
Corrige con el cambio más pequeño posible, y añade después a cada uno una comprobación que lo hubiera hecho evidente.
Paso 3 · La auditoría final · 25 min
Auditoría · el proyecto
- Se arranca con
npm starttras unnpm install. node_modulesy.envno están en el repositorio; el bloqueo sí.- Existe
.env.examplecon las claves y sin los valores. - El README dice cómo arrancarlo y qué rutas ofrece.
- Solo hay una dependencia, y sabes justificarla.
Auditoría · el servidor
- Cada ruta devuelve el código de estado correcto, incluidos los errores.
- Toda entrada se valida antes de tocar los datos.
- Los errores se tratan en un solo sitio y no filtran trazas.
- Cada petición queda registrada con su estado y su tiempo.
- No se puede pedir un fichero fuera de la carpeta pública.
- La escritura del fichero de datos es segura.
- Ninguna operación de disco es síncrona.
Auditoría · el código
- La lógica de negocio no sabe nada de HTTP ni de ficheros.
- Ningún valor de configuración está escrito en el código.
- No queda código comentado ni mensajes de depuración.
- Los nombres están en un solo idioma.
Paso 4 · Revisión por pares · 20 min
Intercambia proyectos y aplica los cinco puntos de la explicación, empezando por clonarlo en una carpeta limpia. Devuelve las respuestas por escrito, recibe la tuya y decide qué aceptas.
El punto 4 conviene hacerlo de verdad: intenta leer el .env de tu compañero a través de su servidor. Si lo consigues, es el hallazgo del día.
Paso 5 · Cerrar la entrega y preparar la defensa · 15 min
El repositorio de mi-api con su README y su .env.example; el CLI del catálogo; el servidor nativo conservado en una rama o carpeta aparte, como prueba de lo que sabes hacer sin framework; el servidor Express con estáticos, registro y errores centralizados; el fichero peticiones.http; las tres listas de auditoría marcadas; la revisión del compañero por escrito; y el informe de la sesión 5.
Las preguntas de la defensa
- Enseña el recorrido completo de una petición
POST, desde que llega hasta que se responde. - ¿Por qué escribimos primero el servidor a mano? ¿Qué te resolvió Express exactamente?
- ¿Qué pasa si el fichero de datos no existe? ¿Y si el proceso muere escribiéndolo?
- ¿Dónde validas, y qué pasaría si solo validaras en el cliente?
- Si mañana los datos vinieran de una base de datos, ¿qué ficheros tocarías?
| Criterio de evaluación | Puntos |
|---|---|
| El proyecto arranca desde una instalación limpia siguiendo el README | 1 |
| Herramienta de terminal: comandos, ayuda, validación y códigos de salida | 1,5 |
| Acceso a ficheros correcto, con rutas portables y escritura segura | 1,5 |
| Servidor nativo: rutas, métodos y códigos de estado | 2 |
| Estáticos servidos con su tipo de contenido y la ruta protegida | 1 |
| Reescritura con Express equivalente a la versión anterior | 2 |
| Registro de peticiones y errores centralizados | 1 |
No puntúa la cantidad de rutas. Puntúa que sepas decir qué hace por ti cada pieza de Express, porque antes lo escribiste tú.
Ampliación si has completado el trabajo
Primero termina la entrega. El primer reto invierte el ejercicio del paso 2; el segundo prepara el terreno de la UD6.
Reto 1 · Rompe tu propio servidor
Haz una copia de tu proyecto e introduce cinco fallos deliberados, uno de cada familia:
- uno que impida arrancar;
- uno de orden de declaración, que haga que todo responda 404;
- uno que deje
peticion.bodysin contenido; - uno que cuelgue la petición sin error ni traza;
- uno de lógica, que responda 200 con un dato equivocado.
Guarda aparte la solución. Intercámbialo con un compañero y cronometrad cuánto tarda cada uno en encontrar los cinco.
- ¿Cuál costó más? Casi siempre el cuarto y el quinto, y por motivos distintos: uno no deja rastro, el otro no parece un fallo.
- ¿Miró la terminal, el Network o el registro? Anota en qué orden, y compáralo con el diagrama de la explicación.
- ¿Encontró la causa o solo el síntoma? Compruébalo preguntándole qué pasaría con otra ruta distinta.
- Para el cuarto fallo, el que cuelga la petición: ¿qué habría tenido que mirar para verlo? Escribe la comprobación que lo habría delatado.
- Anota una técnica que usara y tú no hubieras usado.
Reto 2 · Consultas que se combinan
Tu GET /api/productos acepta como mucho un filtro. Una API real acepta varios a la vez, y ahí aparecen decisiones que no son evidentes.
GET /api/productos?categoria=teclados&precioMax=100&disponible=true&orden=precio&pagina=2&tamano=10- Haz que los filtros se combinen entre sí, reutilizando tu
aplicarFiltrosde la UD4 sin reescribirla. Si no puedes reutilizarla, mira por qué: probablemente sabía algo del DOM. - Todos los parámetros llegan como texto. Conviértelos y valida cada uno en el borde, antes de que toquen la lógica.
- Decide y documenta qué hacer con cada caso raro: un parámetro desconocido,
precioMax=abc,pagina=0,pagina=-1,tamano=100000,orden=inventado. Ninguno debe producir un 500. - Devuelve la respuesta paginada con su metainformación: total de resultados, página actual y número de páginas. Decide la forma del objeto y sé coherente.
- Documenta los parámetros en el README, con un ejemplo de cada uno.
- Escribe en tres líneas por qué esta ruta, tal como queda, empieza a necesitar una forma más ordenada de declarar qué acepta. Eso es lo que resuelve la validación por esquema, y aparece en la UD6.
Cierre
5 minutos · comprobación y recuerdo
Lista de verificación de la entrega
- Has montado un servicio completo sin partir del tuyo, con las capas separadas.
- Separas fallos de cliente de fallos de servidor antes de tocar nada.
- El proyecto arranca desde una instalación limpia siguiendo el README.
- Las tres listas de auditoría están marcadas.
- Has revisado el proyecto de un compañero desde un clon limpio.
- Conservas el servidor nativo como prueba de lo que sabes hacer sin framework.
Antes de cerrar · 3 minutos, sin mirar
- ¿En qué orden se monta un servicio, y por qué las rutas van al final?
- Un servidor responde 404 a todo: escribe dos hipótesis.
- ¿Qué te dice la familia del código de estado sobre dónde buscar?
- ¿Qué haces antes de investigar un fallo que has visto en el navegador?
- ¿Qué significa que
peticion.bodyseaundefined? - Si mañana los datos vinieran de una base de datos, ¿qué ficheros tocarías?
Ver respuestas
1 · Datos, almacén, reglas de negocio y por último rutas; porque la capa de HTTP es la más superficial y la que menos debería saber.
2 · Por ejemplo: el orden de las declaraciones, con el 404 final puesto antes de las rutas; o la ruta escrita de forma distinta a la que se pide.
3 · Un 4xx señala al cliente y un 5xx a tu servidor, así que decide en qué consola empezar a mirar.
4 · Reproducirlo con el cliente HTTP, para saber si el problema estaba en el cliente.
5 · Que falta express.json(), o que está declarado después de la ruta que lo usa.
6 · Solo el almacén, si la lógica de negocio no sabe de dónde vienen los datos.
Microprueba semanal 6 · 10 minutos
Individual, sin IA y sin apuntes.
- Describe, en orden, el recorrido de una petición POST por tu servidor.
- Un servidor responde 404 a todo. Escribe dos hipótesis y cómo comprobarías cada una.
- ¿Por qué escribimos el servidor a mano antes de usar Express? Responde en tres líneas.