Hoy · Hoja de ruta
- 1. Aprende: Qué se revisa en un proyecto de servidor antes de entregarlo.
- 2. Haz: Audita el tuyo, revisa el de un compañero y corrige.
- 3. Comprueba: Otra persona lo arranca y lo entiende sin ayuda.
La lista de auditoría
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.
Revisión por pares
Intercambia proyectos y, sin preguntar nada:
- Clónalo, instala y arráncalo. Anota cada tropiezo.
- Ejecuta su fichero de peticiones y comprueba que hace lo que dice.
- Envía datos inválidos y mira qué responde.
- Pide un fichero fuera de la carpeta pública y comprueba si se defiende.
- Señala una decisión bien tomada y una mejorable, con su razón.
Defensa
Las preguntas de la defensa
- Enséñame 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?
Evaluación
| Criterio | 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ú.
Entrega
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 13.
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.