UD5 · Guía y taller práctico
Node.js: JavaScript fuera del navegador
El mismo lenguaje, sin navegador. Node ejecuta JavaScript en tu máquina, con acceso a ficheros y a la red, y con él construirás primero un servidor HTTP a mano —para entender qué hace de verdad— y solo después lo reescribirás con Express, sabiendo qué te ahorra.
Antes de empezar
- Necesitas
- Node.js 22 o superior y npm.
- Visual Studio Code y una terminal.
- Un cliente HTTP: la extensión REST Client, Thunder Client o curl.
- El catálogo en JSON de las unidades anteriores.
- Debes saber
- Funciones, arrays de objetos, módulos ES, JSON y try/catch (UD3).
- Peticiones, respuestas, códigos de estado y fetch desde el cliente (UD4).
- Manejo básico de la terminal: moverse por carpetas y ejecutar comandos.
¿Qué vas a aprender?
Durante dos trimestres, el servidor ha sido «eso que está al otro lado». En la UD4 le pediste datos con fetch y te respondió, y ni siquiera era tuyo.
En esta unidad cruzas al otro lado.
- UD1–UD2 · el documento
- UD3–UD4 · el cliente
- UD5–UD6 · el servidor
Todo ello sin cambiar de lenguaje. Node.js es JavaScript ejecutándose fuera del navegador: el mismo const, las mismas funciones, los mismos arrays de objetos, los mismos async/await. Lo que cambia es lo que hay alrededor.
Qué cambia al salir del navegador
| En el navegador | En Node |
|---|---|
window, document, el DOM |
No existen |
| No puedes tocar ficheros | Lees y escribes el disco |
| Consumes peticiones | Las atiendes |
| Lo ejecuta quien visita la web | Lo ejecutas tú, y sigue corriendo |
| El código es público | El código no se ve desde fuera |
Esa última fila es la que más consecuencias tiene, y explica la regla que va a gobernar la unidad siguiente: la validación de verdad, las claves y las decisiones que no se pueden saltar viven aquí, porque aquí nadie las puede abrir con DevTools.
La idea que gobierna la unidad
Podríamos empezar directamente por Express, que es lo que se usa en producción. No lo vamos a hacer.
Primero a mano, después con el framework
Vas a escribir un servidor con el módulo nativo de Node: recibir la petición, mirar el método y la ruta, decidir la respuesta, poner las cabeceras y el código de estado. Es incómodo, y esa incomodidad es el contenido de la sesión 13.
Cuando después llegue Express, cada una de sus piezas responderá a un dolor que ya has sentido. Es la diferencia entre saber usar un framework y saber qué está haciendo por ti; la primera se aprende en una tarde, la segunda es la que te permite arreglarlo cuando falla.
El proyecto de la unidad
Cambia el proyecto. Hasta ahora trabajabas en mi-web/; ahora creas al lado un proyecto Node que acabará sirviendo esa web:
mi-api/
│
├── package.json
├── package-lock.json
├── .gitignore
├── .env.example
│
├── datos/
│ └── productos.json ← el catálogo, ahora en disco
│
├── src/
│ ├── cli.js ← la herramienta de línea de comandos
│ ├── almacen.js ← leer y escribir el fichero
│ ├── servidor.js ← primero a mano, luego con Express
│ └── rutas.js
│
└── publico/ ← el sitio de la UD1–UD4, servido desde aquí
├── index.html
├── css/
└── js/Una herramienta de terminal que lista, añade, actualiza y borra productos del fichero JSON; un servidor HTTP escrito con el módulo nativo que sirve la web y responde a /api/productos; y ese mismo servidor reescrito con Express, con estáticos, registro de peticiones y errores centralizados.
Condición 1 · nada de dependencias hasta la sesión 14
Ni Express, ni utilidades de fecha, ni librerías de colores en la terminal: hasta la sesión 14, todo lo que entregues se resuelve con lo que Node trae de fábrica.
La única excepción es el ejercicio de la sesión 5, donde instalarás y desinstalarás un paquete para ver qué le hace al proyecto. La primera dependencia que se quede será Express, y para entonces sabrás exactamente por qué.
Condición 2 · nada de secretos en el repositorio
Un puerto, una ruta de fichero o una clave de API se leen del entorno, no se escriben en el código, y el archivo con los valores reales no se incorpora nunca al repositorio. No se trata de una preferencia de estilo: es la causa más común de credenciales filtradas en repositorios públicos.
Condición 3 · la IA, para entender, no para entregar
- Antes de preguntar: lee el error completo de la terminal. Node dice el módulo, la línea y el código de error.
- Pregunta: pide una explicación, no el fichero terminado. Ejemplo: «Mi servidor responde 404 a todo. He comprobado que la petición llega, porque la registro. Explícame qué debería revisar sin darme el código».
- Después: cierra la respuesta y añade tú una ruta más.
Herramientas
La terminal
Deja de ser un sitio al que se va de vez en cuando. Aquí se arranca el servidor, se instalan dependencias, se ejecutan los programas y se leen los errores.
Un cliente HTTP
Para probar tu servidor sin depender del navegador. Con REST Client de VS Code las peticiones se guardan en un fichero .http dentro del propio proyecto, así que se versionan con el código y sirven de documentación.
No todo pesa lo mismo
node:test, escritura atómica y depuración con el inspector.
Plan de trabajo semanal
| Semana | Bloque temático | Práctica central | Horas |
|---|---|---|---|
| Semana 1 | El entorno | Ejecutar, argumentos, entorno y módulos | 3 h |
| Semana 2 | npm y el proyecto | package.json, dependencias y una herramienta de terminal |
3 h |
| Semana 3 | Ficheros y datos | Leer y escribir el catálogo sin corromperlo | 3 h |
| Semana 4 | El servidor a mano | HTTP nativo, rutas, estados y estáticos | 3 h |
| Semana 5 | Del servidor al framework | Los límites del nativo y el primer Express | 3 h |
| Semana 6 | Integración y entrega | Refactorización, depuración y revisión por pares | 3 h |
| Total | Un servidor propio, escrito dos veces | 18 h |
- Recupera · 5 min
- Aprende y observa · 10–20 min
- Practica · 30–40 min
- Cierra · 5 min
Sesiones de la unidad
Cada sesión es una clase, con su propia página.
18 sesiones
Semana 1 · El entorno
Semana 2 · npm y el proyecto
Semana 3 · Ficheros y datos
Semana 4 · El servidor a mano
Semana 5 · Del servidor a mano al framework
Semana 6 · Integración y entrega