Cómo enrutar las llamadas de un front Angular

Con un micro de backend, apuntar una dependencia a local, a la nube o a un mock es directo: Aseptic le inyecta la URL resuelta al arrancarlo, como propiedad del sistema (-D) o como variable de entorno. Un front Angular no tiene dónde recibirla: sus llamadas salen del navegador, y la URL a la que apuntan se decidió al compilar o vive en un fichero que sirve la propia app.

Por eso Aseptic lo enruta de otra forma. Hay tres vías, y se eligen en este orden, que es el de menos a más intrusivo. Las dos primeras no tocan tu repositorio.

1. Por proxy (lo que pasa por defecto)

Aseptic escribe un proxy.conf.json en .aseptic/.runtime/ —fuera de tu repo— y se lo pasa a ng serve con --proxy-config. Ese fichero mapea el prefijo de API de cada dependencia al destino que el escenario haya resuelto para ella: el micro local, la nube o el servidor de mocks.

Para que funcione, cada dependencia del front tiene que declarar como ruta local el prefijo con el que la app llama (por ejemplo /api/pedidos). Es lo único que hay que revisar tras dar de alta el front: el autodetector no puede adivinarlo del código, así que lo deja para que lo confirmes.

No hay nada que activar. Si el escenario resuelve la dependencia a mock, el front habla con el mock sin que ni el front ni tú os enteréis.

2. Cuando ng serve no acepta el flag

Algunos fronts no arrancan con el servidor de Angular sino con un builder propio —Module Federation es el caso típico—, y ese builder no conoce --proxy-config. Pasárselo no degrada el enrutado: impide que el micro arranque, con un Error: Unknown argument: proxy-config. Y como el que no levanta arrastra a los que dependían de él, el escenario acaba señalando a otro sitio.

Aseptic mira el builder que declara angular.json (o workspace.json, en Nx) y solo deja de pasar el flag cuando tiene prueba de que no lo admite. Si no hay fichero, no se puede leer o el proyecto no se identifica, lo pasa como siempre: quitarlo «por si acaso» dejaría sin enrutar a fronts que hoy funcionan, y ese fallo silencioso es peor que el ruidoso que evita.

Cuando no lo pasa, el escenario arranca igual y el log lo dice: ese front se queda sin enrutar, y ahí mismo te apunta por dónde salir.

En Micros → Arranque (local) puedes forzarlo con Enrutado por proxy de ng serve:

• Automático — lo deduce del builder. Es lo normal.
• Sí, pasar el flag — para un builder que sí lo admite y no está en la lista.
• No pasarlo nunca — para uno que no.

3. Por configuración en runtime

Si tu app pide su configuración al arrancar —el patrón del APP_INITIALIZER que hace un fetch a una ruta y de ahí saca las URLs—, dilo en Ruta de configuración en runtime. Aseptic sirve ahí un JSON con las URLs ya resueltas y enruta esa ruta por el mismo proxy.

Es una ruta virtual, no un fichero de tu repositorio: precisamente por eso se puede interceptar. Y hay dos formas de servirla:

• JSON de dependencias (por defecto): un objeto identificador de dependencia → URL resuelta. Es un contrato entre tu app y el manifiesto: la app tiene que conocer esas claves.
• Relativa al gateway: para las apps que ya traen su configuración en un asset propio (assets/config/environment.js) con las URLs colgando de un API gateway. Aseptic sirve ese mismo asset, tal cual, más un recorte que en runtime convierte el origen del gateway en ruta relativa, para que el proxy la capture por prefijo. Si el repo trae ese fichero, se autodetecta al dar de alta el micro y no hay que configurar nada.

4. Reescribiendo el environment (último recurso)

Queda un caso al que no llega ninguna de las anteriores: fronts que no aceptan el flag del proxy, no piden configuración en runtime y resuelven el backend con URLs compiladas al construir, dentro del environment del perfil activo. Ahí la única vía es tocar ese fichero.

Aseptic lo hace de forma acotada y reversible, y solo si tú lo pides: se declara en el manifiesto con stack.environmentRewrite, diciendo qué fichero y qué campos apuntan a qué dependencia. Al arrancar sustituye el valor de esos campos por la URL resuelta; al parar, lo deja como estaba. No hay control en la interfaz a propósito: es opt-in y se declara a mano.

Dos salvaguardas que conviene conocer:

• Es a prueba de cierres abruptos. El original se respalda fuera del repositorio (.aseptic/.runtime/env-backups/) y se restaura tanto al parar como al volver a arrancar: si la app se cerró de golpe con el fichero tocado, lo primero que hace es devolverlo a su sitio.
• Mejor un perfil que no esté versionado. El fichero queda modificado mientras el escenario corre, así que se prefiere un environment.local.ts ignorado por git. El chequeo de entorno avisa si el que declaraste está versionado, o si no existe.

Cuál te toca

• ¿Tu front arranca con ng serve y llama por un prefijo? La 1, sin hacer nada.
• ¿Arranca pero no enruta y el log habla del --proxy-config? La 2, y si tu builder sí lo admite, fuérzalo.
• ¿Tu app pide su configuración al arrancar? La 3.
• ¿Ninguna de las anteriores y las URLs están compiladas dentro? La 4.

Ver también

• Dependencias · Micro, manifiesto y stack
• Sección Micros · Personalizar el arranque