Montar un servidor Node.js dentro de un monorepo NX te permite tener una REST API en memoria que actúa como puente entre dos aplicaciones Angular. Aquí ves cómo inicializar ese servidor, exponer cursos, estudiantes e inscripciones, y validar cada endpoint con Postman antes de integrarlo a tus proyectos.

¿Qué hace el servidor Node.js dentro del monorepo NX?

El servidor funciona como una REST API ligera que mantiene los datos en memoria y los sirve en formato JSON. Su rol es conectar dos aplicaciones Angular que comparten modelos y componentes comunes.

Dentro de la carpeta server ya están definidas las interfaces que la API usará, junto con los datos iniciales de cursos, estudiantes e inscripciones cargados directamente en TypeScript. Toda esa información se sirve por el puerto 3000.

¿Qué significa que la API esté en memoria? Que los datos viven mientras el servidor está activo. Puedes leerlos, crearlos, editarlos y borrarlos, pero al reiniciar el servidor vuelven al estado inicial definido en el código.

¿Cómo inicializar el servidor desde NX Console?

Levantar el servidor no requiere comandos manuales. Abre NX Console, ve a la sección server y lanza la tarea de arranque. En segundos verás el proceso corriendo en localhost:3000, listo para responder peticiones.

Esta es la ventaja real de trabajar con NX: la consola unifica el control de tareas, así que el mismo flujo que usas para Angular sirve para tu backend.

¿Qué endpoints expone la API y cómo se prueban en Postman?

La API sigue el patrón clásico CRUD sobre tres recursos: cursos, estudiantes (etiquetados como musicians para darle un toque divertido) e inscripciones. Cada recurso responde a los cuatro verbos HTTP estándar.

• GET para consultar todos los registros o uno por ID.
• POST para crear un nuevo registro.
• PUT para modificar un registro existente.
• DELETE para eliminar un registro.

Para probarlo, abre Postman, escribe la URL localhost:3000/courses y lanza un GET. Verás los tres cursos iniciales con IDs uno, dos y tres. Si añades el ID como parámetro, por ejemplo localhost:3000/courses/1, la respuesta se filtra a ese único curso.

¿Por qué usar Postman en este flujo? Porque te deja validar cada endpoint de forma aislada antes de conectarlo a Angular. Si algo falla, sabes que el problema está en la API y no en el cliente.

El mismo patrón aplica para students y enrollments. Copias el nombre del recurso, lo añades a la URL base y obtienes la misma estructura de respuesta. Esa consistencia es lo que hace que la API sea predecible y fácil de consumir desde cualquier cliente.

¿Dónde se almacenan los datos que devuelve la API?

Los datos provienen del propio archivo TypeScript del servidor, donde están declarados como objetos en memoria. Puedes agregar, editar y eliminar registros mientras el servidor esté activo, y esos cambios se reflejan en las respuestas hasta el próximo reinicio.

¿Por qué este servidor encaja con dos apps Angular?

Porque ya tienes componentes comunes, modelos compartidos y la lógica para consumir una REST API. El servidor cierra el círculo: ofrece un punto único de verdad que ambas aplicaciones pueden leer y modificar sin duplicar lógica de datos.

Con este puente listo, el siguiente paso es integrar las llamadas HTTP desde cada app Angular y ver cómo los cambios fluyen entre ellas en tiempo real. ¿Ya tienes claro qué endpoint vas a consumir primero desde tu cliente Angular? Cuéntame en los comentarios.