En 03-01 elegimos Express y no discutimos la decisión: había que empezar por algún sitio y Express es el punto de partida más didáctico del ecosistema Node, porque no esconde nada. Cada middleware que registramos en src/app.js lo escribimos nosotros, y por eso entendemos qué hace cada uno.

Pero Express no es la única opción, ni siquiera dentro de JavaScript, y la pregunta «¿qué framework usamos?» aparece en el primer día de cualquier proyecto nuevo. Se responde casi siempre mal: por costumbre, por moda o por un benchmark leído a medias.

Esta lección da la perspectiva que falta. Vamos a implementar el mismo endpoint, GET /v1/cafes, en nueve frameworks distintos de cinco lenguajes, con el mismo contrato: los filtros de 02-06, la paginación obligatoria, la respuesta {datos, total} y la validación que produce el 400 del catálogo. Compararemos qué hace el framework por ti y qué te deja a ti, y terminaremos con los criterios honestos de elección —los que no salen en los gráficos de peticiones por segundo— y con la observación más importante del módulo: casi nada de lo aprendido en este curso depende del framework.

Esta lección no es un tutorial de instalación. No vas a montar nueve proyectos. Los fragmentos están para ser leídos y comparados, no ejecutados; cada uno asume el proyecto ya creado con las herramientas del lenguaje correspondiente.

1. Por qué esta lección existe
2. Qué se espera hoy de un framework de API
3. El endpoint de referencia
4. Express: el mínimo, todo a tu cargo
5. Fastify: esquemas, plugins y velocidad
6. NestJS: arquitectura opinada para equipos grandes
7. Hono: ligero y multi-runtime
8. FastAPI (Python): el tipado como contrato
9. Django REST Framework (Python): serializers y viewsets
10. Spring Boot (Java): el estándar empresarial
11. ASP.NET Core (C#): minimal APIs y rendimiento
12. Menciones: Laravel, Rails API y Go
13. La tabla comparativa
14. Criterios de elección honestos
15. Lo que no depende del framework
16. Migrar entre frameworks: de Express a Fastify
17. Runtimes alternativos y serverless

Tres situaciones concretas hacen que esta comparación importe:

• Empiezas un proyecto y tienes que elegir. La decisión condiciona los siguientes años: contrataciones, formación, dependencias y velocidad de entrega. Se toma en una reunión de una hora y se paga durante cinco años.
• Cambias de trabajo y el proyecto está en otro framework. Si entiendes qué problema resuelve cada uno, aterrizas en días en lugar de en meses.
• Alguien propone migrar. Necesitas argumentos mejores que «Fastify es más rápido» para decidir si compensa.

Y hay un cuarto motivo, más de fondo: ver el mismo endpoint nueve veces enseña qué es esencial en una API REST —el contrato, los códigos, la validación, la paginación— y qué es accidental, propio del framework de turno. Es la mejor vacuna contra confundir Express con REST.

Un framework de API se juzga por cuánto de esta lista te da resuelto y con qué calidad:

Observa cuántas casillas de la columna derecha dicen «a mano». Eso no es un defecto de Express: es su propuesta. La pregunta de esta lección es qué ganas y qué pierdes cuando otro framework rellena esas casillas por ti.

El contrato que implementarán los nueve, tal como lo fijamos en 02-06 y 05-02:

Reglas que cada implementación debe cumplir:

1. limite por defecto 20, máximo 100; desplazamiento máximo 10.000.
2. tueste solo admite claro, medio u oscuro.
3. Un parámetro inválido produce 400 con {"error": {"codigo": "parametro_invalido", ...}}.
4. El precio se almacena en céntimos enteros y se serializa en euros con dos decimales.
5. Requiere autenticación.

Esa cuarta regla es la más reveladora: es donde se ve si el framework serializa por ti y si te deja controlar la transformación.

Nuestro punto de partida, condensado para poder compararlo:

Balance de Express. El código es transparente: se lee de arriba abajo y no hay magia. Cada garantía del contrato existe porque la escribimos. El coste es que la lista de "a mano" del apartado 2 es larga, y que nada te obliga: es perfectamente posible que un compañero registre una ruta sin validar y nadie se entere hasta que llegue un 500.

Fastify nació preguntándose si se podía tener la simplicidad de Express con mejor rendimiento. La respuesta fue sí, y el mecanismo es interesante: JSON Schema como pieza central.

Tres cosas que Fastify hace distinto y que conviene entender:

• La validación es declarativa y automática. No hay middleware validar: el esquema querystring lo hace el framework, y produce el 400 solo. Ganas garantía —no puedes olvidarte— y pierdes control sobre el formato del error, que hay que personalizar con setErrorHandler para que encaje con nuestro catálogo.
• El esquema de respuesta compila un serializador. Fastify convierte ese response.200 en una función de serialización especializada, más rápida que JSON.stringify genérico. Efecto secundario crucial: los campos no declarados en el esquema se eliminan de la respuesta. Es una protección estupenda contra fugas accidentales de datos (04-02) y, a la vez, la causa número uno de «he añadido un campo y no aparece».
• Los plugins tienen encapsulación real. Un plugin registrado en un ámbito no contamina a los demás, a diferencia de app.use en Express, que es global. Eso permite, por ejemplo, aplicar un rate limiting distinto a /v1/sesiones sin trucos.

La documentación es casi gratis, porque los esquemas ya están escritos:

Aquí está la diferencia práctica con 05-02: en Express escribimos openapi.yaml a mano y arriesgamos deriva; en Fastify el esquema es la validación y es la documentación. A cambio, la especificación resultante es más pobre en descripciones y ejemplos si nadie los escribe.

NestJS es el framework más opinado del ecosistema Node. Trae TypeScript, decoradores, módulos e inyección de dependencias; su modelo mental viene de Angular y, más atrás, de Spring.

Qué ganas. Estructura idéntica en todos los proyectos y equipos, lo que reduce a días el tiempo de incorporación de alguien nuevo. Inyección de dependencias de verdad, que hace triviales las pruebas con dobles —lo que en 03-08 conseguimos a mano con el repositorio en memoria—. Documentación OpenAPI generada desde los DTO con @nestjs/swagger. Y una convención tan fuerte que las discusiones sobre estructura de carpetas desaparecen.

Qué pagas. Mucho código para poco: el DTO anterior son treinta líneas para lo que en Zod son seis. Curva de aprendizaje real —módulos, proveedores, ámbitos, guardias, interceptores, tuberías—. Arranque y consumo de memoria mayores. Y una capa de abstracción que, cuando falla, obliga a entender sus interioridades.

Cuándo compensa. Equipos de más de cinco personas, proyectos de largo recorrido, dominios complejos con muchos módulos. Para una API de seis endpoints es un traje demasiado grande.

Hono responde a una pregunta nueva: ¿y si tu API no corre en un servidor Node, sino en el borde de la red —Cloudflare Workers, Deno Deploy, Bun—?

Lo interesante de Hono no es la sintaxis —muy parecida a Express— sino que usa APIs web estándar: Request, Response, fetch. El mismo código corre en Node, Deno, Bun, Cloudflare Workers y AWS Lambda. Es diminuto (unos pocos kilobytes), lo que importa mucho en entornos donde el arranque en frío se mide en milisegundos.

Su límite es el otro lado de la misma moneda: en el borde no tienes sistema de ficheros ni conexiones TCP persistentes, así que better-sqlite3 y el pool de PostgreSQL de 03-05 no existen; hay que usar servicios de datos con API HTTP. Y su ecosistema es mucho menor que el de Express.

FastAPI es probablemente la mejor demostración de una idea: si el lenguaje tiene anotaciones de tipos, el framework puede deducir de ellas la validación, la serialización y la documentación.

Lo que ocurre con esas veinte líneas, sin escribir nada más:

• Validación completa de tipos y rangos, con 422 automático (personalizable a nuestro 400).
• Conversión de tipos: limite=20 llega como texto y se entrega como int.
• Documentación OpenAPI 3.1 completa, servida en /docs con Swagger UI y en /redoc con Redoc, sin una línea extra.
• Serialización con los alias precio_euros → precioEuros, que resuelve el eterno choque entre el snake_case de Python y el camelCase del JSON.
• Inyección de dependencias con Depends, que además hace trivial sustituir usuario_actual en las pruebas.

FastAPI es la respuesta más elegante del panorama a la deriva entre código y contrato de 05-02. Sus límites: Python es más lento que los runtimes compilados —aunque FastAPI, sobre async, es de lo más rápido del ecosistema—, y el async de Python es fácil de estropear: una llamada bloqueante dentro de una función async congela el bucle de eventos entero, un error tan clásico como el await olvidado en Node.

DRF es la otra escuela: no un framework de API, sino una capa de API sobre un framework web completo. Su premisa es que ya tienes modelos de Django y quieres exponerlos.

Cuarenta líneas producen los siete endpoints del recurso completo, con filtrado, ordenación, paginación, permisos y una consola HTML navegable. Es, con diferencia, la mayor productividad inicial de todo este recorrido.

El precio. Los ViewSets exponen la forma de tu modelo de datos, no la de tu contrato de API, y ahí choca de frente con 02-02: el día que el contrato deba divergir del modelo —campos calculados, agregaciones, nombres distintos, subrecursos de transición de estado como /pedidos/{id}/pago— peleas contra el framework. Se puede hacer, con serializers y acciones personalizadas, pero cada excepción cuesta más que si lo hubieras escrito a mano. Además, Django arrastra una filosofía completa: su ORM, su sistema de migraciones, su admin. Si no vas a usarlos, DRF es un peso muerto.

Cuándo compensa: un CRUD sobre un modelo relacional que ya existe, con panel de administración incluido. Es imbatible en ese terreno.

Spring Boot es el framework que más APIs corporativas sostiene en el mundo. Su modelo —anotaciones, inyección de dependencias, capas— es el que NestJS imita.

Java resuelve limpiamente algo que en JavaScript es un problema real: BigDecimal para el dinero. En JavaScript, 0.1 + 0.2 no es 0.3, y por eso en 02-05 decidimos guardar céntimos enteros. Java tiene un tipo decimal exacto de serie, igual que C# con decimal.

Su ecosistema es el mayor argumento: Spring Security para OAuth y OIDC (04-03), Spring Data para persistencia, Actuator que da /salud y métricas de Prometheus (04-07) prácticamente gratis, springdoc-openapi para la documentación. Todo lo que en el módulo 4 construimos pieza a pieza existe aquí como dependencia estándar, revisada y con soporte comercial.

El precio: verbosidad, arranque lento (segundos, aunque GraalVM lo mitiga), consumo de memoria alto, y una curva de aprendizaje larga donde el problema no es Java sino la cantidad de conceptos de Spring.

ASP.NET Core es, en los benchmarks públicos, uno de los frameworks web más rápidos que existen, y su modo minimal API elimina buena parte de la ceremonia clásica de C#.

Puntos destacables: [AsParameters] agrupa los parámetros de consulta en un record tipado, decimal da aritmética exacta para el dinero, y el rendimiento en el mismo hardware suele estar entre los mejores del panorama. Su punto flojo relativo es la validación declarativa, que no viene de serie con la potencia de Pydantic o Zod.

Cuándo elegirlo: organizaciones ya en el ecosistema Microsoft, o cuando el rendimiento por servidor es un factor de coste real. Y conviene desmontar el prejuicio: ASP.NET Core es multiplataforma, de código abierto y corre en Linux y en contenedores con normalidad.

Laravel (PHP). Sigue siendo dominante en la web PHP y su modo API con Eloquent, API Resources y Sanctum es productivo y bien documentado. Su hosting es el más barato y disponible del mundo. Estigmatizado sin motivo: el PHP moderno con tipos poco tiene que ver con el de hace quince años.

Ruby on Rails API (rails new --api). Padre del "convención sobre configuración" que inspiró a medio sector. Enorme productividad inicial, ideal para prototipos y startups. Su rendimiento por proceso es modesto y el ecosistema ha perdido impulso frente a otros.

Go con net/http (que desde Go 1.22 enruta con patrones de método y ruta), o con Gin o Echo:

Go destaca en tres cosas: binario único sin runtime (imágenes Docker de pocos megas, arranque instantáneo), concurrencia con goroutines y muy poca memoria por petición, y una biblioteca estándar tan completa que muchos equipos no usan framework. A cambio, escribes más código: no hay validación declarativa ni generación automática de OpenAPI sin herramientas adicionales.

Cómo leer la columna de rendimiento. Es una ordenación aproximada de peticiones por segundo en pruebas sintéticas de "devolver un JSON pequeño". Casi nunca describe tu API real, porque en cuanto hay una consulta a base de datos, una llamada de red o una plantilla, el framework deja de ser el cuello de botella. Un GET /v1/cafes que tarda 40 ms de los cuales 35 son la consulta SQL rinde prácticamente igual en Express que en Fastify. Si tu p99 es alto, mide antes de culpar al framework: la respuesta suele estar en el apartado de índices y N+1 de 04-06.

Los criterios reales, ordenados por el peso que deberían tener:

1. El lenguaje que domina tu equipo. Es el criterio número uno, por mucho. Un equipo experto en Python entregará antes y con menos errores en FastAPI que en el framework Node más rápido del mundo. El coste de aprender un lenguaje nuevo —no la sintaxis, sino sus modismos, su depuración, su empaquetado, sus trampas— se mide en meses de productividad reducida y en errores sutiles en producción.

2. Contratación y mercado laboral. Si mañana necesitas dos personas más, ¿las encuentras? ¿Y en tu ciudad, o en tu franja horaria? Elegir un framework de nicho porque es elegante y descubrir que no hay a quién contratar es un error caro y frecuente.

3. Madurez y horizonte de soporte. ¿Quién lo mantiene? ¿Hay una empresa detrás, una fundación, una persona? ¿Cuál es la política de versiones? Spring y Django llevan más de quince años y seguirán; un framework de dos años con un solo mantenedor es una apuesta. Este criterio pesa el doble si la API es de largo recorrido y el triple si estás en un sector regulado.

4. Encaje con el problema. Un CRUD sobre modelo relacional con panel de administración pide DRF a gritos. Una API en el borde con latencia mínima pide Hono. Un dominio complejo con veinte módulos y quince personas pide NestJS o Spring. Forzar la herramienta contra el problema se paga cada semana.

5. Ecosistema para lo que necesitas. No el ecosistema en abstracto: ¿existe un cliente maduro para tu base de datos, tu proveedor de OAuth, tu pasarela de pago, tu sistema de colas? Descubrir en la semana seis que el SDK de tu pasarela no existe en ese lenguaje es un problema serio.

6. Rendimiento. El último, salvo que estés en un caso concreto donde importa: decenas de miles de peticiones por segundo, latencia sub-10 ms, o una factura de servidores lo bastante grande como para que un 30 % de eficiencia sea dinero real. Para el 95 % de las APIs, la diferencia entre frameworks es irrelevante frente a una consulta sin índice.

Y una advertencia sobre los benchmarks públicos: miden un endpoint que devuelve {"hello":"world"}, con configuraciones optimizadas por especialistas y sin base de datos, sin autenticación, sin validación y sin logs. Son útiles para descartar órdenes de magnitud y engañosos para todo lo demás. Mide tu API real con autocannon (04-06) antes de tomar cualquier decisión basada en velocidad.

Esta es la observación central de la lección. Repasa el curso:

De seis módulos, uno cambia. Y ni siquiera entero: la separación por capas de 03-03 —rutas, controladores, servicios, repositorios— se conserva en todos ellos con otros nombres, porque no es una idea de Express.

Ejemplos concretos de lo que se transfiere sin cambios:

• Que POST /v1/pedidos exija Idempotency-Key y devuelva 201 con Location es contrato. Igual en los nueve.
• Que un ETag que coincida con If-None-Match produzca 304 lo dicta HTTP. Cambia la función que lo escribe, no la regla.
• Que el token JWT lleve sub, rol y exp, y que la validación compruebe firma, expiración y emisor, es OAuth y JWT. Cambia la biblioteca.
• Que un error se devuelva como {"error": {"codigo", "mensaje", "detalles"}} es tu catálogo.
• Que las etiquetas de las métricas no incluyan ped_5001 porque revientan la cardinalidad es una regla de Prometheus.

Conclusión práctica: si sabes diseñar y operar APIs, aprender un framework nuevo es cuestión de una o dos semanas. Si solo sabes Express, no sabes hacer APIs: sabes usar Express. El conocimiento transferible es el de los módulos 1, 2, 4 y 5.

Supongamos que Tienda Aroma decide migrar a Fastify por rendimiento y por la generación automática de OpenAPI. ¿Qué pasa con el proyecto?

Se conserva todo lo que no toca req y res: los servicios de src/servicios/, los repositorios de src/repositorios/, los mapeadores, src/errores/error-api.js, las migraciones y —lo más valioso— el openapi.yaml y las pruebas de integración de 03-08, porque hablan HTTP y les da igual quién responda. Esas pruebas son la red de seguridad que hace posible la migración: si pasan con Fastify, la migración es correcta por definición.

Se reescribe la capa de entrega: rutas, middlewares y la composición de la aplicación.

Aquí está el mismo endpoint, antes y después:

El controlador es idéntico salvo la firma. Los esquemas Zod se convierten con zod-to-json-schema, la herramienta que ya vimos en 05-02.

La receta de migración, si alguna vez te toca:

1. Congela el contrato. Ni un cambio funcional durante la migración. Si mezclas ambas cosas, no sabrás si un fallo viene de la migración o de la función nueva.
2. Asegura las pruebas de integración primero. Son el criterio objetivo de éxito. Si la cobertura de los endpoints es baja, súbela antes de tocar nada.
3. Migra por recursos, no de golpe. Con un proxy delante puedes servir /v1/cafes desde el servicio nuevo y el resto desde el viejo. Es el patrón de la higuera estranguladora, y es lo que hace viable migrar un sistema en producción.
4. Compara respuestas byte a byte. Ejecuta la colección de Postman de 05-01 contra ambos y diferencia. Las sorpresas suelen estar en las cabeceras y en el orden de los campos.
5. Vigila los detalles pequeños, que son los que muerden: el formato exacto del error de validación, el orden de las claves del JSON, si el ETag es débil o fuerte, la codificación de los parámetros repetidos.

¿Compensa? Casi nunca por rendimiento solo. Compensa cuando el framework actual bloquea algo importante: falta de tipado en un equipo que crece, ausencia de un ecosistema que necesitas, o un mantenimiento abandonado. «Es más moderno» no es una razón; es un gasto sin retorno.

Dos ejes más, brevemente, porque afectan a la elección tanto como el framework.

Runtimes de JavaScript:

El detalle más interesante de Deno para lo que hemos visto en 04-02: los permisos son explícitos (--allow-net=api.tiendaaroma.example), de modo que una dependencia comprometida no puede leer tu disco ni abrir conexiones a un servidor desconocido. Es una defensa real contra los ataques de cadena de suministro que mencionamos con npm audit.

Serverless. Tu API no corre como proceso permanente, sino como funciones que se invocan bajo demanda: AWS Lambda con API Gateway, Google Cloud Functions, Azure Functions, Cloudflare Workers.

Implicaciones directas para lo que hemos construido: el rate limiting con memoria local de 04-04 no funciona en serverless —cada invocación puede ir a otra instancia—, así que Redis pasa de recomendable a obligatorio; la caché en proceso desaparece; y el pool de conexiones de 03-05 se convierte en un problema que exige un pooler externo.

Express corre en Lambda con adaptadores (serverless-http), pero Hono está diseñado para ese entorno y arranca en una fracción del tiempo. Es un buen ejemplo de cómo el entorno de despliegue —tema de 05-05— condiciona la elección del framework tanto como el lenguaje.

• Elegir por benchmark. Los gráficos miden {"hello":"world"} sin base de datos ni autenticación. Tu p99 lo domina la consulta SQL, no el enrutador.
• Elegir por moda. El framework del que todo el mundo habla este año puede estar sin mantenimiento dentro de tres. Comprueba quién lo sostiene y con qué política de versiones.
• Elegir un lenguaje que el equipo no domina. Es la decisión que más proyectos hunde. La sintaxis se aprende en una semana; la depuración, el empaquetado y las trampas del runtime, en meses.
• Confundir el framework con la arquitectura. DRF o NestJS no te dan un buen diseño de API: te dan una estructura. Un ViewSet mal usado expone tu modelo de datos y viola todo el módulo 2.
• Migrar sin pruebas. Sin las pruebas de integración de 03-08, una migración es una reescritura a ciegas. Asegúralas antes de empezar.
• Mezclar migración y funcionalidad nueva. Cuando algo falle no sabrás de qué mitad viene. Congela el contrato.
• Olvidar que Fastify elimina los campos no declarados en el esquema de respuesta. Es una virtud de seguridad y la causa más frecuente de «mi campo nuevo no sale».
• Creer que "código primero" te libra de pensar el contrato. Los tipos se generan; el diseño de 02-02 no.
• Consejo: aprende un segundo framework de otro lenguaje, no otro de Node. Comparar Express con Fastify enseña poco; comparar Express con FastAPI o Spring enseña qué es esencial y qué es accidental.
• Consejo: mantén la lógica de negocio fuera del framework. Si tus servicios no importan nada de Express, migrar es cambiar la capa de entrega. Es la razón de ser de la separación de 03-03, y su valor solo se aprecia el día que hace falta.
• Consejo: escribe un ADR con la decisión (04-01), con los criterios y las alternativas descartadas. Dentro de dos años alguien preguntará por qué, y sin ADR la respuesta será «porque sí».

Para cada escenario, elige un framework, justifícalo con al menos tres criterios del apartado 14 y menciona la alternativa que descartas y por qué:

A) Una startup de tres personas con experiencia en Python lanza el MVP de una API de reservas de restaurantes en ocho semanas. Necesitan un panel de administración interno desde el primer día y prevén cambios de modelo constantes.

B) Un banco moderniza su API de consulta de movimientos. Diez personas, requisitos de auditoría y trazabilidad, integración con un proveedor de identidad corporativo, y soporte garantizado a diez años.

C) Una API de geolocalización que recibe 50.000 peticiones por segundo, devuelve respuestas muy pequeñas desde una caché en memoria, y debe responder en menos de 20 ms en todo el mundo.

Este es el endpoint GET /v1/cafes/{id}/resenas en Express:

Pórtalo a Fastify manteniendo el mismo contrato: mismos parámetros y validaciones, mismas cabeceras Cache-Control y Link, y el mismo formato de error parametro_invalido. Indica qué piezas desaparecen, cuáles cambian de nombre y qué hay que añadir explícitamente que en Express estaba en un middleware.

Un compañero se incorpora a un proyecto en Spring Boot viniendo de este curso, hecho en Express. Redacta una guía de una página que le diga: qué conocimientos de los módulos 1, 2, 4 y 5 aplica tal cual (con tres ejemplos concretos), qué tiene que reaprender del módulo 3 y cuál es el equivalente en Spring de cinco piezas de nuestro proyecto (middleware/autenticacion.js, middleware/errores.js, repositorios/cafes-sqlite.js, esquemas/cafes.js y observabilidad/metricas.js).

A) Startup de reservas → Django REST Framework.

Alternativa descartada: FastAPI. Mejor contrato y mejor documentación automática, pero no trae ORM, ni migraciones, ni admin: habría que montar SQLAlchemy, Alembic y un panel, y ahí se van las ocho semanas. Se reconsideraría a los dos años si la API deja de ser un CRUD y el contrato empieza a divergir del modelo.

B) Banco → Spring Boot.

Alternativa descartada: NestJS. Da una arquitectura parecida con TypeScript y sería una elección defendible, pero pierde en horizonte de soporte, en madurez del ecosistema de seguridad y auditoría empresarial, y en profundidad del mercado laboral bancario. Además, JavaScript carece de tipo decimal nativo, lo que en un sistema financiero es fricción constante.

C) Geolocalización a 50.000 rps → Go, o Hono sobre Cloudflare Workers.

Decisión: Hono en el borde si el conjunto de datos cabe en un almacén distribuido tipo KV; Go multirregión si los datos son grandes o el cálculo es intensivo. Descartados Express, NestJS y DRF: a ese volumen la diferencia de eficiencia se traduce directamente en factura, y DRF además arrastra un ORM que este caso no usa.

Y el manejador de errores global, imprescindible para que el 400 automático de Fastify hable nuestro idioma:

Balance de la migración de este endpoint:

Lo que hay que añadir explícitamente es lo más importante de la lista: en Express controlábamos el formato del 400 porque lo escribíamos nosotros; en Fastify, si no se registra setErrorHandler, la validación automática devuelve el formato del framework y rompe el contrato de errores de 02-04 sin que nadie lo note hasta que un consumidor se queja. Es el ejemplo perfecto de que las garantías automáticas de un framework hay que reconducirlas a tu contrato, no al revés.

Guía de incorporación: de Express a Spring Boot

Lo que aplicas tal cual (módulos 1, 2, 4 y 5).

El 80 % de lo que sabes sigue siendo válido, porque describe HTTP y diseño, no Express. Tres ejemplos concretos:

1. El diseño del contrato (módulo 2). Que los recursos sean sustantivos en plural, que las transiciones de estado se expresen como subrecursos (POST /pedidos/{id}/pago) y no como un PATCH sobre estado, que 201 lleve Location, que un filtro sin resultados sea 200 con lista vacía y no 404, y que la paginación sea obligatoria con limite y desplazamiento. Nada de esto cambia: lo escribirás con @PostMapping en lugar de router.post, y punto.
2. Caché y concurrencia (04-06). ETag, If-None-Match → 304, If-Match → 412, Cache-Control con max-age. Spring lo expone con ResponseEntity.ok().eTag(...) y ShallowEtagHeaderFilter, pero las reglas son las de HTTP y las decisiones de política son las mismas que tomaste.
3. Todo el módulo 5. La colección de Postman funciona sin tocar una línea, porque habla HTTP. El openapi.yaml es el mismo documento. La tubería de CI cambia npm ci por mvn verify y poco más. Y un gateway delante no distingue qué hay detrás.

Lo que tienes que reaprender (módulo 3).

Solo la capa de entrega y sus herramientas: anotaciones en lugar de middlewares, Bean Validation en lugar de Zod, JPA o JDBC en lugar de better-sqlite3, JUnit y MockMvc en lugar de node:test y Supertest, y —lo más ajeno viniendo de Node— el contenedor de inyección de dependencias: en Spring no instancias tus servicios, los declaras y el framework los construye e inyecta.

Tabla de equivalencias:

Consejo final para la incorporación: dedica el primer día a leer el openapi.yaml del proyecto, no el código. El contrato es lo que ya sabes leer, y te dará el mapa completo del sistema antes de enfrentarte a una sola anotación de Spring.

Has visto el mismo endpoint —GET /v1/cafes, con sus filtros, su paginación obligatoria, su 400 del catálogo y su conversión de céntimos a euros— resuelto en Express, Fastify, NestJS, Hono, FastAPI, Django REST Framework, Spring Boot, ASP.NET Core y Go. Y con ello has visto los tres modelos que se reparten el panorama: el minimalista, donde tú escribes todas las garantías y por eso las entiendes; el de esquema como centro, donde un mismo documento sirve de validación, serialización y documentación —Fastify y FastAPI son sus mejores exponentes, y resuelven de raíz la deriva de contrato que en 05-02 tuvimos que combatir con herramientas—; y el opinado, NestJS, Spring y DRF, que a cambio de más ceremonia dan estructura idéntica, inyección de dependencias y una productividad enorme cuando el problema encaja con lo que el framework espera.

Los criterios de elección, en su orden real: el lenguaje que domina tu equipo, la contratación, la madurez y el horizonte de soporte, el encaje con el problema, el ecosistema concreto que necesitas y, en último lugar salvo casos muy específicos, el rendimiento —porque los benchmarks miden {"hello":"world"} sin base de datos y tu p99 lo domina la consulta SQL de 04-06—. Y sabes que una migración se conserva o se pierde según una única cosa: si tu lógica de negocio importa el framework o no. En Tienda Aroma no lo hace, y por eso src/servicios/, src/repositorios/, los mapeadores, openapi.yaml, la colección de Postman y —sobre todo— las pruebas de integración de 03-08 sobrevivirían intactos a un cambio a Fastify; solo se reescribirían src/rutas/, src/middleware/ y src/app.js.

Lo más importante de esta lección es lo que no cambia. De los seis módulos del curso, solo el tercero depende del framework, y ni siquiera entero. Que un pedido exija Idempotency-Key, que un ETag coincidente produzca 304, que los errores lleven un código estable del catálogo, que la SPA necesite CORS y el panel un token con ámbitos, que las etiquetas de las métricas no incluyan identificadores: nada de eso es Express. Si sabes diseñar y operar APIs, aprender un framework nuevo son dos semanas; si solo sabes Express, sabes usar Express.

Volvemos ahora al proyecto y a un cabo que 05-02 dejó suelto. Tenemos un contrato completo y validado como documento, pero nada garantiza todavía que el servidor lo cumpla, ni que un cambio en el YAML no rompa a la SPA sin avisar. En 05-04, Contratos, mocks y pruebas automatizadas de API, cerramos ese círculo: levantaremos un mock con Prism desde openapi.yaml para que la SPA avance en paralelo, usaremos msw en el front y nock para las llamadas salientes a RápidoEnvíos, validaremos las respuestas reales contra los esquemas dentro de las pruebas Supertest que ya tenemos, detectaremos cambios rompedores con oasdiff aplicando las reglas de 02-07, veremos cuándo el contract testing con Pact compensa y cuándo es sobreingeniería, y organizaremos el recorrido de compra completo como prueba de extremo a extremo, con la tabla de qué se ejecuta al guardar, en el pull request, en el despliegue y en producción.