Die Aufrufe eines Angular-Frontends routen

Bei einem Backend-Micro ist es unkompliziert, eine Abhängigkeit auf lokal, Cloud oder einen Mock zu richten: Aseptic injiziert ihm die aufgelöste URL beim Start, als Systemeigenschaft (-D) oder als Umgebungsvariable. Ein Angular-Frontend hat keinen Ort, um sie zu empfangen: seine Aufrufe gehen vom Browser aus, und die URL, auf die sie zeigen, wurde beim Bauen festgelegt oder liegt in einer Datei, die die App selbst ausliefert.

Deshalb routet Aseptic es anders. Es gibt drei Wege, in dieser Reihenfolge gewählt, vom am wenigsten zum am stärksten eingreifenden. Die ersten beiden fassen Ihr Repository nicht an.

1. Per Proxy (was standardmäßig passiert)

Aseptic schreibt eine proxy.conf.json nach .aseptic/.runtime/ —außerhalb Ihres Repos— und übergibt sie ng serve mit --proxy-config. Diese Datei bildet das API-Präfix jeder Abhängigkeit auf das Ziel ab, das das Szenario für sie aufgelöst hat: den lokalen Micro, die Cloud oder den Mock-Server.

Damit das funktioniert, muss jede Abhängigkeit des Frontends als lokalen Pfad das Präfix angeben, mit dem die App aufruft (zum Beispiel /api/bestellungen). Das ist das Einzige, was nach dem Anlegen des Frontends zu prüfen ist: die Autoerkennung kann es nicht aus dem Code erraten und überlässt es Ihnen zur Bestätigung.

Es gibt nichts zu aktivieren. Löst das Szenario die Abhängigkeit auf mock auf, spricht das Frontend mit dem Mock, ohne dass es das Frontend —oder Sie— merken.

2. Wenn ng serve das Flag nicht akzeptiert

Manche Frontends starten nicht mit dem Entwicklungsserver von Angular, sondern mit einem eigenen Builder —Module Federation ist der typische Fall—, und dieser Builder kennt --proxy-config nicht. Es ihm zu übergeben verschlechtert das Routing nicht: es verhindert den Start des Micros, mit einem Error: Unknown argument: proxy-config. Und da der, der nicht hochkommt, die mitreißt, die von ihm abhingen, zeigt das Szenario am Ende auf eine ganz andere Stelle.

Aseptic schaut auf den in angular.json (oder workspace.json, bei Nx) deklarierten Builder und hört nur dann auf, das Flag zu übergeben, wenn es den Beweis hat, dass es nicht akzeptiert wird. Fehlt die Datei, ist sie unlesbar oder lässt sich das Projekt nicht bestimmen, wird es wie immer übergeben: es „sicherheitshalber“ wegzulassen würde Frontends, die heute funktionieren, ohne Routing lassen, und dieser stille Fehler ist schlimmer als der laute, den es vermeidet.

Wenn es nicht übergeben wird, startet das Szenario trotzdem, und das Log sagt es: dieses Frontend bleibt ohne Routing, und genau dort wird Ihnen der Ausweg gezeigt.

Unter Micros → Lokale Startkonfiguration können Sie es mit Routing über den ng-serve-Proxy erzwingen:

• Automatisch — aus dem Builder abgeleitet. Das ist der Normalfall.
• Ja, Flag übergeben — für einen Builder, der es akzeptiert und nicht auf der Liste steht.
• Nie übergeben — für einen, der es nicht akzeptiert.

3. Per Laufzeitkonfiguration

Wenn Ihre App ihre Konfiguration beim Start anfordert —das Muster des APP_INITIALIZER, der ein fetch auf einen Pfad macht und daraus die URLs zieht—, geben Sie das unter Konfigurationspfad zur Laufzeit an. Aseptic liefert dort ein JSON mit den bereits aufgelösten URLs aus und routet diesen Pfad über denselben Proxy.

Es ist ein virtueller Pfad, keine Datei Ihres Repositorys: genau deshalb lässt er sich abfangen. Und es gibt zwei Arten, ihn auszuliefern:

• Abhängigkeits-JSON (Standard): ein Objekt Abhängigkeits-Id → aufgelöste URL. Es ist ein Vertrag zwischen Ihrer App und dem Manifest: die App muss diese Schlüssel kennen.
• Gateway-relativ: für Apps, die ihre Konfiguration bereits in einem eigenen Asset mitbringen (assets/config/environment.js), mit den URLs an einem API-Gateway. Aseptic liefert genau dieses Asset, unverändert, plus eine Kürzung, die zur Laufzeit den Ursprung des Gateways in einen relativen Pfad verwandelt, damit der Proxy ihn per Präfix einfängt. Bringt das Repo diese Datei mit, wird sie beim Anlegen des Micros automatisch erkannt und es gibt nichts einzurichten.

4. Durch Umschreiben des environment (letztes Mittel)

Ein Fall bleibt, den keiner der vorherigen erreicht: Frontends, die das Proxy-Flag nicht akzeptieren, keine Konfiguration zur Laufzeit anfordern und das Backend mit beim Bauen kompilierten URLs auflösen, im environment des aktiven Profils. Dort ist der einzige Weg, diese Datei anzufassen.

Aseptic tut es eng begrenzt und umkehrbar, und nur wenn Sie darum bitten: es wird im Manifest mit stack.environmentRewrite deklariert, indem man sagt, welche Datei und welche Felder auf welche Abhängigkeit zeigen. Beim Start ersetzt es den Wert dieser Felder durch die aufgelöste URL; beim Stoppen lässt es ihn, wie er war. Es gibt absichtlich kein Bedienelement in der Oberfläche: es ist opt-in und wird von Hand deklariert.

Zwei Sicherungen, die man kennen sollte:

• Es übersteht abrupte Abstürze. Das Original wird außerhalb des Repositorys gesichert (.aseptic/.runtime/env-backups/) und sowohl beim Stoppen als auch beim nächsten Start wiederhergestellt: wurde die App mit veränderter Datei abgeschossen, ist das Erste, was sie tut, sie zurückzulegen.
• Besser ein nicht versioniertes Profil. Die Datei bleibt verändert, solange das Szenario läuft, daher wird ein von git ignoriertes environment.local.ts bevorzugt. Die Umgebungsprüfung warnt, wenn die deklarierte Datei versioniert ist oder nicht existiert.

Welcher ist Ihrer

• Startet Ihr Frontend mit ng serve und ruft über ein Präfix auf? Nummer 1, ohne etwas zu tun.
• Startet es, routet aber nicht, und das Log spricht von --proxy-config? Nummer 2, und wenn Ihr Builder es doch akzeptiert, erzwingen Sie es.
• Fordert Ihre App ihre Konfiguration beim Start an? Nummer 3.
• Nichts davon und die URLs sind einkompiliert? Nummer 4.

Siehe auch

• Abhängigkeiten · Micro, Manifest und Stack
• Bereich Micros · Start anpassen