Construir dos aplicaciones Angular que compartan backend y componentes dentro de un monorepo con Nx te permite escalar funcionalidades sin duplicar código. Aquí verás cómo la app de profesores y la app de estudiantes se comunican a través de un mismo Node.js Server, y cómo un cambio en un componente compartido impacta en ambos proyectos al instante.

¿Cómo se estructura la app de profesores en un monorepo Nx?

Dentro de packages/app2 vive la segunda aplicación Angular, dedicada a la gestión docente. Su HTML general arma el panel de profesores con dos rutas principales: gestión de cursos e inscripciones por curso.

Cada vista usa componentes que ya existían en la primera app. La pantalla de inscripciones reutiliza la shared table, y la pantalla de gestión de cursos combina la tarjeta del curso con esa misma tabla compartida. En el archivo .ts, que actúa como controller, se importan utilidades comunes: el modelo curso, el API service, y los componentes UI como tabla, botón y tarjeta. A partir de Angular 17, todo esto entra directamente en los imports del componente standalone [01:30].

¿Qué es un monorepo con Nx? Es un repositorio único que aloja varias aplicaciones y librerías, permitiendo compartir código, servicios y componentes entre proyectos sin duplicarlos.

¿Por qué reutilizar el API service entre aplicaciones?

El mismo API service que consume la app de estudiantes lo consume la app de profesores. Esto ahorra líneas de código, unifica la lógica de peticiones HTTP y garantiza que ambas vistas hablen con el backend bajo el mismo contrato.

¿Cómo levantar el backend y las dos apps Angular a la vez?

Desde Nx Console primero levantas el server, que queda disponible en localhost:3000. Luego abres la aplicación uno en el puerto 4200 y la aplicación dos en el 4201.

La velocidad de arranque sorprende, y aquí entra en juego una pieza clave de la infraestructura.

¿Por qué Nx Cloud acelera el desarrollo? Porque guarda en caché los resultados de builds y tareas previas. Cuando vuelves a ejecutar algo que no cambió, Nx lo recupera de memoria en lugar de recompilar [03:30].

Con el backend y los dos frontends corriendo en paralelo, ya puedes ver cómo dialogan entre sí.

¿Cómo impactan los cambios entre dos apps Angular conectadas?

La app de profesores tiene dos vistas. La gestión de cursos usa un formulario reactivo con un botón que se deshabilita hasta cumplir las validaciones, y debajo monta un CRUD completo: create, read, update y delete sobre la tabla compartida. La vista de inscripciones por curso muestra un select para filtrar, una tarjeta general y una tabla de solo lectura, sin acciones, porque un profesor no debería inscribirse a sí mismo.

¿Qué pasa al crear un curso desde la app de profesores?

Al dar de alta un curso como Angular con Firebase, este aparece de inmediato en la app de estudiantes tras un refresh. Si Alex Cooper se inscribe desde la app uno, al volver a la app dos y abrir inscripciones por curso → Angular con Firebase, su nombre ya figura en la lista [05:30].

Esto demuestra el efecto pivote del Node.js Server: ambas apps escriben y leen del mismo origen, por eso una acción en una pantalla se refleja en la otra sin sincronización manual.

¿Cómo modificar un componente compartido afecta a ambos proyectos?

Las tarjetas comparten elementos, como la etiqueta del profesor, aunque cada app decida si muestra o no el botón de inscripción. Si abres ui-shared y editas la clase course-teacher en el CSS, cambiando por ejemplo el color de la etiqueta, el ajuste se propaga al instante a las dos aplicaciones [07:30].

Es un cambio cosmético, pero ilustra el verdadero valor: la lógica vive en un solo lugar.

• Una sola fuente de verdad para los componentes UI.
• Cambios visuales y de comportamiento replicados en N apps al mismo tiempo.
• Menos código duplicado y menos bugs de inconsistencia entre vistas.

Imagina este patrón con 10, 15 o 20 aplicaciones dentro del mismo monorepo. El ahorro en tiempo y mantenimiento se vuelve enorme.

¿Qué decisiones del proyecto son solo con fines educativos?

Algunas elecciones del flujo no replican un entorno productivo. El selector de usuario actual que aparece en pantalla, por ejemplo, jamás existiría en una app real: en producción siempre habría un login con autenticación previa para modificar datos.

Lo mismo aplica a la edición libre de cursos. En un sistema real existirían restricciones por rol, permisos y validaciones de servidor antes de permitir cualquier alta o eliminación. Tenlo en mente al adaptar este patrón a tus propios proyectos.

Con las dos apps Angular ya coordinadas a través del backend Node.js y compartiendo componentes, tarjetas y servicios, queda demostrado el poder de Nx para escalar arquitecturas frontend. ¿Qué otro componente reutilizarías entre tus apps si trabajaras en un monorepo? Cuéntalo en los comentarios.