There is nothing to show here!
Slider with alias none not found.
UI in einer Microservice Architektur
Wir bei innFactory setzen von Beginn an auf Microservices im Backend. Die technologische Unabhängigkeit und die flexible Skalierbarkeit zwischen den einzelnen Services sind in unseren Augen unschlagbar. Zusätzlich lassen Frameworks wie Lagom (Scala) das „Mehr-Overhead“ Argument verstummen.
Letzte Woche war ich im Rahmen der Veranstaltung „Microservices“ als Dozent zu Gast an der Hochschule Rosenheim und habe mich der Frage gewidmet, inwiefern sich das Frontend an die Microservice Architektur im Backend anpassen und integrieren lässt.
Der “klassische” Ansatz
Das Frontend wird beim klassischen Ansatz als Monolith belassen. Nach unserer Erfahrung ist das auch bislang der gängigste Weg, um ein Frontend an ein Backend mit Microservice Architektur anzubinden. Das Entwickler Team besteht dabei meist ausschließlich aus Frontend Spezialisten, die das Backend über einen sogenannten „Aggregation Layer“ (das Backend) einbinden. Der Aggregation Layer sorgt für eine spezielle API, zugeschnitten auf die jeweiligen Bedürfnisse. So kann beispielweise die App und die Website mit einer genau passenden Schnittstelle bedient werden, um den Datentransfer gering und die Klarheit hoch zu halten. Um dieses sogenannte „Backend for Frontend Pattern“ dynamischer umzusetzen, verwenden wir bei innFactory überwiegend GraphQL als Abfragesprache für die API.
Klassische Microservice UI
Der “FullStack” Ansatz
Im Gegensatz zur klassischen Architektur führt der FullStack Ansatz die Idee hinter den Microservices weiter bis in das Frontend. Zwar sind die einzelnen Services nach wie vor zwischen Back- und Frontend getrennt, jedoch ergeben sich technologisch gemischte Entwickler Teams, die auf einen bestimmten Use Case gerichtet sind. Meist wirkt sich das sehr positiv auf den Knowhow-Transfer innerhalb des Entwickler-Teams aus, allerdings entstehen im Frontend auch erhebliche Hürden, die weiter unten unter „Probleme bei der UI-Ausarbeitung mit einer Microservice-Architektur“ erklärt werden.
FullStack Microservice UI
Vergleich: Klassisch – FullStack
Folgender Vergleich soll die Tendenzen aufzeigen, nach denen sich die beiden Ansätze unserer Erfahrung nach unterscheiden:
“Klassisch”
- Best Practise – geringes technisches Risiko
- Schnellere Einarbeitung neuer Entwickler
- One team, one user experience
“FullStack”
- Größerer Wissenstransfer im Team
- Flexiblere Entwickler (+ oft höhere Eigenmotivation für FullStack Projekte)
- Fokus komplett auf einen Service gerichtet
Technische Probleme bei der UI-Ausarbeitung mit einer Microservice-Architektur
Eine besondere Herausforderung stellt der Austausch von UI-Komponenten zwischen den einzelnen Teams dar. Dies liegt allen voran daran, dass, wie in einer Microservice Architektur üblich, jedes Team unabhängig ihre Komponenten warten und deployen können soll. Einen interessanten Ansatz verfolgt OpenTable mit ihrem serverless GUI-Framework OpenComponents (https://github.com/opentable/oc).
Microservice UI Probleme
Im Backend sind die einzelnen Microservices technisch vollkommen unabhängig. Diese Unabhängigkeit auch im Frontend bereit zu stellen und jedem Team frei zwischen Frameworks oder Libraries, wie React, Angular oder Ember wählen zu lassen, ist nur schwer realisierbar. Hinzu kommen darüber hinaus viele verschiedene Versionen der genannten Frameworks sowie anderen Javascript Erweiterungen. Der Browser wäre bei clientseitigem Rendering gezwungen unzählige Javascript Dateien zu laden, was die Geschwindigkeit auf einen inakzeptablen Wert drücken würde. Aber auch serverseitiges Rendering mit z.B. next.js ist mit unterschiedlichen Libraries und Versionen aus Gründen der Kompatibilität nicht umsetzbar.
Um trotzdem eine Microservice Architektur zu realisieren bleibt nur eine einheitliche technische Basis aller Teams. Dies kann ein einziges Framework sein oder auch die Entwicklung in reinem Javascript, CSS und HTML. Ein vielversprechender Ansatz ist der WebComponents Standard, auf den sich die großen Browserhersteller derzeit vorbereiten.
Fazit
Die Frontend Architektur der Microservices anzupassen verspricht gerade bei sehr großen Projekten Vorteile in der Teamstrukturierung sowie klare Verantwortlichkeiten der Services. Technologisch wird diese Herausforderung am besten mit dem Verzicht auf externe Frameworks und Libraries bewältigt. Eine Überlegung ist, in naher Zukunft eigene HTML-Tags mit WebComponents zu implementieren, um die gewünschte Unabhängigkeit zu erreichen.
