Comment router les appels d'un front Angular

Avec un micro de backend, pointer une dépendance vers le local, le nuage ou un mock est direct : Aseptic lui injecte l’URL résolue au démarrage, comme propriété système (-D) ou comme variable d’environnement. Un front Angular n’a nulle part où la recevoir : ses appels partent du navigateur, et l’URL qu’ils visent a été décidée à la compilation ou vit dans un fichier que l’app sert elle-même.

C’est pourquoi Aseptic le route autrement. Il y a trois voies, choisies dans cet ordre, du moins au plus intrusif. Les deux premières ne touchent pas votre dépôt.

1. Par proxy (ce qui se passe par défaut)

Aseptic écrit un proxy.conf.json dans .aseptic/.runtime/ —hors de votre dépôt— et le passe à ng serve avec --proxy-config. Ce fichier associe le préfixe d’API de chaque dépendance à la destination que le scénario a résolue pour elle : le micro local, le nuage ou le serveur de mocks.

Pour que cela fonctionne, chaque dépendance du front doit déclarer comme chemin local le préfixe avec lequel l’app appelle (par exemple /api/commandes). C’est la seule chose à revoir après avoir ajouté le front : l’autodétection ne peut pas le deviner depuis le code, elle vous laisse donc le confirmer.

Il n’y a rien à activer. Si le scénario résout la dépendance en mock, le front parle au mock sans que ni le front ni vous ne vous en rendiez compte.

2. Quand ng serve n’accepte pas le drapeau

Certains fronts ne démarrent pas avec le serveur de développement d’Angular mais avec un builder à eux —Module Federation étant le cas typique—, et ce builder ne connaît pas --proxy-config. Le lui passer ne dégrade pas le routage : il empêche le micro de démarrer, avec une Error: Unknown argument: proxy-config. Et comme celui qui ne se lève pas entraîne ceux qui dépendaient de lui, le scénario finit par désigner un autre endroit.

Aseptic regarde le builder déclaré dans angular.json (ou workspace.json, sous Nx) et cesse de passer le drapeau uniquement quand il a la preuve qu’il n’est pas accepté. S’il n’y a pas de fichier, qu’il est illisible ou que le projet ne s’identifie pas, il le passe comme toujours : le retirer « au cas où » laisserait sans routage des fronts qui fonctionnent aujourd’hui, et cet échec silencieux est pire que celui, bruyant, qu’il évite.

Quand il ne le passe pas, le scénario démarre quand même et le journal le dit : ce front reste sans routage, et il vous indique là même par où sortir.

Dans Micros → Configuration de démarrage local, vous pouvez le forcer avec Routage par le proxy de ng serve :

• Automatique — déduit du builder. C’est le cas normal.
• Oui, passer le drapeau — pour un builder qui l’accepte et n’est pas dans la liste.
• Ne jamais le passer — pour un qui ne l’accepte pas.

3. Par configuration à l’exécution

Si votre app demande sa configuration au démarrage —le motif de l’APP_INITIALIZER qui fait un fetch vers un chemin et en tire les URL—, dites-le dans Chemin de configuration à l’exécution. Aseptic y sert un JSON avec les URL déjà résolues et route ce chemin par le même proxy.

C’est un chemin virtuel, pas un fichier de votre dépôt : c’est précisément pour cela qu’on peut l’intercepter. Et il y a deux façons de le servir :

• JSON de dépendances (par défaut) : un objet identifiant de dépendance → URL résolue. C’est un contrat entre votre app et le manifeste : l’app doit connaître ces clés.
• Relatif à la passerelle : pour les apps qui portent déjà leur configuration dans un asset à elles (assets/config/environment.js) avec les URL suspendues à une passerelle d’API. Aseptic sert ce même asset, tel quel, plus un rognage qui, à l’exécution, transforme l’origine de la passerelle en chemin relatif, pour que le proxy la capture par préfixe. Si le dépôt embarque ce fichier, il est autodétecté à l’ajout du micro et il n’y a rien à configurer.

4. En réécrivant l’environment (dernier recours)

Il reste un cas qu’aucune des précédentes n’atteint : les fronts qui **n’**acceptent pas le drapeau du proxy, ne demandent pas de configuration à l’exécution, et résolvent le backend avec des URL compilées à la construction, dans l’environment du profil actif. Là, la seule voie est de toucher ce fichier.

Aseptic le fait de façon délimitée et réversible, et seulement si vous le demandez : cela se déclare dans le manifeste avec stack.environmentRewrite, en disant quel fichier et quels champs pointent vers quelle dépendance. Au démarrage il remplace la valeur de ces champs par l’URL résolue ; à l’arrêt, il le laisse comme il était. Il n’y a pas de contrôle dans l’interface exprès : c’est opt-in et cela se déclare à la main.

Deux garde-fous à connaître :

• Cela résiste aux fermetures brutales. L’original est sauvegardé hors du dépôt (.aseptic/.runtime/env-backups/) et restauré aussi bien à l’arrêt qu’au démarrage suivant : si l’app a été tuée avec le fichier modifié, la première chose qu’elle fait est de le remettre en place.
• Mieux vaut un profil non versionné. Le fichier reste modifié pendant que le scénario tourne, on préfère donc un environment.local.ts ignoré par git. Le contrôle de l’environnement vous avertit si celui que vous avez déclaré est versionné, ou s’il n’existe pas.

Laquelle est la vôtre

• Votre front démarre-t-il avec ng serve et appelle-t-il par un préfixe ? La 1, sans rien faire.
• Démarre-t-il sans router, et le journal parle-t-il de --proxy-config ? La 2, et si votre builder l’accepte, forcez-le.
• Votre app demande-t-elle sa configuration au démarrage ? La 3.
• Aucune des précédentes et les URL sont compilées dedans ? La 4.

Voir aussi

• Dépendances · Micro, manifeste et stack
• Section Micros · Personnaliser le démarrage