© best_vector/Shutterstock.com
Unterschiedliche Möglichkeiten, Angular für Microservices zu nutzen

Angular in einer Microservices-Welt


Microservices erfreuen sich derzeit großer Beliebtheit, Single Page Applications auch. Wie man diese beiden Ansätze am besten verwendet, führt zu interessanten Diskussionen. Das Spannende daran ist, dass es hierauf keine eindeutige Antwort gibt. Wie so häufig, hängt es stark von den Prioritäten ab und somit auch von den Gründen, warum die Entscheidung für Microservices gefallen ist.

Im folgenden Artikel stelle ich einige Möglichkeiten vor und bewerte sie im Hinblick auf ausgewählte Architekturziele, die für Microservices sprechen. Zum Einstieg gibt Tabelle 1 einen ersten Überlick.

Architekturziel

Beschreibung

Isolation zu anderen SPA

Inwieweit ist die Angular-Anwendung von anderen Single Page Applications, die im Browser laufen, abgeschottet? Können sich die einzelnen Anwendungen gegenseitig beeinflussen?

Separates Deployment

Lassen sich die einzelnen Single Page Applications separat deployen?

Unterschiedliche Frameworks

Können unterschiedliche Singe Page Applications mit unterschiedlichen Frameworks in unterschiedlichen Versionen geschrieben werden?

Single Page Shell

Präsentiert sich die Shell, die die Navigation zwischen den einzelnen Single Page Applications erlaubt, auch als SPA oder verhält sich die Lösung wie eine klassische Webanwendung, die einzelnen Seiten nachlädt und keine Zustände lokal vorhalten kann?

Tree Shaking

Lassen sich Bundle-Größen durch das Abstoßen nicht benötigter Frameworkbestandteile optimieren?

Tabelle 1: Architekturziele für SPA im Microservices-Umfeld

Variante eins: Integration via Hyperlinks

Die wohl einfachste Möglichkeit, verschiedene Clients im Rahmen einer Microservices-Architektur zu integrieren, ist der Einsatz von Hyperlinks. Auf diese Weise referenzieren sich die einzelnen Clients gegenseitig. Außerdem können übergeordnete Shell-Anwendungen die Clients aufrufen. Während es sich bei diesen Clients um SPAs handelt, trifft das auf die Gesamtlösung nicht zu. Die Seitenwechsel beim Übergang zwischen den Clients hat zur Folge, dass die aktuelle SPA beendet wird und auch deren Zustände verloren gehen. Gerade die Möglichkeit, Zustände im Client vorhalten zu können, führt jedoch bei SPA zu einer erhöhten Benutzerfreundlichkeit. Das ist ein großer Unterschied zu klassischen Webanwendungen, wo Zustände im Weblayer nicht gerne gesehen sind. Um diesen Nachteil zu kompensieren, könnte man die clientseitigen Zustände regelmäßig sichern. Hierfür bieten sich Browserdatenbanken wie IndexedDB an. Alternativ dazu lassen sich die Zus...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang