© Excellent backgrounds/Shutterstock.com
Kolumne: Die Angular-Abenteuer

Kolumne: Die Angular-Abenteuer


Microservices erfreuen sich großer Beliebtheit, Single Page Applications auch. Wie man diese beiden Ansätze am besten verwendet, habe ich in den letzten Monaten immer wieder mit meinen Kunden diskutiert. Das Spannende daran ist, dass es hierfür 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. Deshalb stelle ich hier einige Möglichkeiten vor und bewerte sie im Hinblick auf ausgewählte Architekturziele, die für Microservices und Angular-Clients sprechen (Tabelle 1).

Video: GraphQL & Angular - forget (the) REST?

Architekturziel

Beschreibung

Isolation zu anderen SPAs

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 Single 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 SPAs 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...

Neugierig geworden?

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