Visión general

En la nube de UCIC conviven dos sistemas distintos que hoy comparten proyecto de Google Cloud pero no comparten casi nada más:

Sistema	Qué es	Dominio
Aprendix	La plataforma de aprendizaje. Lo que ya existía.	aprendix.ucic.pe
Nexo	El portal nuevo y sus módulos.	nexo.ucic.pe

Que estén en el mismo proyecto de GCP es herencia, no diseño. Conviene tenerlo presente: un problema de cuota, de facturación o de permisos en ese proyecto afecta a los dos a la vez.

Nexo: un portal y sus módulos

Nexo no es una aplicación, son varias que se montan juntas en el navegador. El patrón es Module Federation: el portal descarga en caliente el código de cada módulo y lo dibuja dentro de su propio marco.

                      ┌─────────────────────┐
  nexo.ucic.pe ─────► │  nexo-hub-frontend  │  el portal: sesión, menú, marco
                      └──────────┬──────────┘
                                 │ descarga remoteEntry.js
                                 ▼
                      ┌─────────────────────┐
                      │  nexo-ti-frontend   │  el módulo de TI
                      └─────────────────────┘

  nx-api.ucic.pe ───► nexo-hub-backend   identidad: quién eres
                      nexo-ti-backend    lo del módulo de TI
                      nexo-ia            motor de voz

Por qué así y no una sola aplicación

Porque los módulos los van a escribir personas distintas en momentos distintos. Con una sola aplicación, agregar una pantalla obliga a desplegar todo; con módulos federados, cada uno se despliega solo y un error en uno no tumba a los demás.

El precio es real y conviene saberlo: hay más piezas que mantener, y los fallos de integración —una versión de React distinta, una cabecera CORS ausente— se manifiestan como pantallas en blanco, no como errores claros.

Las reglas que sostienen el diseño

El portal es el único que autentica. Los módulos no tienen login ni saben cerrar sesión: reciben quién eres y con qué token hablar con su propio backend. Si el token muere, muere para todos a la vez, que es lo correcto porque es uno solo.

Cada módulo es dueño de lo suyo. Si una pantalla del módulo de TI necesita un endpoint, ese endpoint va en nexo-ti-backend. El día que alguien ponga lógica de negocio en nexo-hub-backend porque «es más cómodo», el portal deja de ser un portal.

React es una sola instancia compartida. Dos copias de React en la misma página son dos sistemas de hooks: el módulo revienta con "Invalid hook call", un error que no menciona ni la federación ni qué módulo lo causó.

Las URLs de los módulos salen del entorno, nunca del código. Un portal con la URL horneada a mano es como se termina con producción cargando el módulo de pruebas: compila igual, despliega igual, y el error aparece recién en la cara de alguien.

Lo que todavía no existe

La autorización. El portal sabe leer roles y oculta del menú lo que no corresponde, pero ningún backend comprueba nada. Quien escriba la URL del API llega igual, con cualquier cuenta válida. Ocultar una opción del menú no protege nada mientras eso siga así.

La autenticación sí está resuelta: token guardado como hash, con vencimiento, y baja inmediata si se desactiva a alguien.