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 wie IndexedDB an. Alternativ dazu lassen sich die Zustände auch zum Server senden, um sie dort in einer Datenbank zu persistieren. Dieser Ansatz hat den Vorteil, dass der Benutzer zu einem späteren Zeitpunkt genau dort weitermachen kann, wo er aufgehört hat.
Doch Wegsichern...