Monolithisch oder modular?

UI-Architektur in Zeiten von Microservices
Kommentare

Wer von Microservice-Architekturen spricht, meint damit Backend-Themen. Die Aufteilung monolithischer Anwendungen auf viele einzelne APIs gehört heute zum Standard in der Web-Entwicklung. Wenn es um das Frontend geht, bringt dieser Trend jedoch nicht nur Vorteile mit sich. So können dem Nutzer nämlich sowohl zu monolithische als auch zu stark modularisierte Frontends Probleme bereiten. Am Ende ist es aber das User Interface, das darüber entscheidet wie gut eine Anwendung ankommt. Also sollte ihm genau so viel Aufmerksamkeit geschenkt werden, wie der Backend-Architektur!

„Orchestration is cheap“ ist eine der Fehlannahmen über Microservice-Architekturen, die Stefan Tilkov auszuräumen versucht. Was nämlich für das Backend gilt, so erläuterte der innoQ-Mitgründer in einem Talk auf der microXchg, muss auf das User Interface noch lange nicht zutreffen. Während die Kommunikation zwischen verschiedenen Anwendungsteilen serverseitig in Mikrosekunden erfolgen kann, muss für die Zusammensetzung des UI auch bedacht werden, dass alle Daten durch das Internet gesendet werden müssen. Das kann schon einmal deutlich länger dauern, sodass das UI langsam und ungleichmäßig laden könnte. Nutzer warten allerdings nicht gerne!

Usability in Microservice-Architekturen

Das ist aber nicht das einzige Problem, das Nutzer häufig mit Microservice-basierten Anwendungen haben. Auch die heute so wichtige Kompatibilität mit unterschiedlichen Devices wird in solchen Architekturen oft nicht optimal umgesetzt. Wer darauf setzt, jedem Device ein eigenes Frontend zu geben, erzeug schnell eine Vielzahl von Abhängigkeiten zwischen den einzelnen Microservices, die zu Problemen mit dem Ladeverhalten und der Darstellung führen können.

Dabei ist es aber das UI, das im Zentrum jeder Anwendung stehen sollte. Nicht die Services sind für Tilkov am wichtigsten, sondern ihre Nutzbarkeit. Ein großes Problem stellt dabei ein weiteres Missverständnis dar: Channels matter. Auch hier widerspricht Tilkov und verweist darauf, dass der Nutzer eine einheitliche User Experience sowie alle Informationen an jedem Ort erwartet – egal, ob er per Smartphone oder Tablet oder am PC auf eine Anwendung zugreift.

Mobile First oder Single Page Application?

Wie lässt sich das aber nun am besten umsetzen? Viele Standards des Webdesigns sind gut vereinbar mit den Grundlagen der Microservice-Entwicklung. So lassen sich die Ideen des responsive Designs gut nutzen, um bessere Interfaces für Microservice-Anwendungen zu erstellen. Ein gutes responsive Design ermöglicht es nämlich, mit nur einem Interface viele Geräte abzudecken. Wer die Grundsätze des Mobile First im Hinterkopf hat, kommt außerdem nicht in die Verlegenheit, bestimmte Funktionalitäten nur auf einem Teil des Device-Kontinuums verfügbar zu machen.

Die Idee hinter der API-basierten Entwicklung ist aber ja, dass die Webentwicklung vereinfacht werden soll. Je weniger einzelne Teile für jede Anwendung erneut erstellt werden müssen, desto besser. Um diese Idee so weitgehend wie möglich umzusetzen, wurde das Konzept der Single Page Application (SPA) entwickelt. Dabei bestehen Websites im Frontend nicht mehr aus vielen verschiedenen Teilen, sondern nur noch aus einer einzelnen, monolithischen Oberfläche, die im Backend mithilfe von Frameworks und APIs generiert wird.

Vor- und Nachteile überall

Dieser Ansatz vermeidet insofern durchaus viele der typischen Probleme eines modularisierten Webdesigns. Unumstritten sind aber auch SPAs nicht. So müssen viele der Funktionen, die der Browser bereits mitbringt, erneut in eine SPA integriert werden. Auch die Durchsuchbarkeit für Suchmaschinen stellt immer noch ein Problem dar, obwohl sich die großen Anbieter dieser Branche langsam auf den neuen Typ der Webinhalte einstellen. SPAs brechen mit vielen Konzepten, die dem Nutzer bereits lange bekannt und vertraut sind.

Eine SPA ist nämlich typischerweise nicht gut über die vertrauten Browser-Mechanismen nutzbar. Um zwischen verschiedenen Seiten vor und zurück springen zu können, braucht es ein integriertes Feature dafür, da die Browser-Tasten versuchen zwischen (nicht existenten) separaten Seiten zu wechseln. Statt einen Link zu einem bestimmten Inhalt abspeichern zu können, muss der Nutzer sich den Weg merken, der durch die Seite zum Inhalt führt. Das ist unbequem, widerspricht den Erwartungen des Nutzers. Oder führt zu ausufernden Komplexitäten, um genau diesen Problemen zu begegnen. Beides ist nicht im Sinne einer gelungenen UI-Architektur.

Best of both worlds

Insofern ist auch ein monolithischer Ansatz kein Allheilmittel gegen die Probleme der modernen UI-Architektur. Die beste Lösung scheint darin zu bestehen, sowohl klassischen Design-Prinzipien als auch moderne Ansätze miteinander zu kombinieren. So gibt es durchaus Anwendungsfälle, in denen eine SPA die beste Wahl für ein Projekt darstellt, weil sie die komplexe Orchestrierung verschiedener Prozesse ins Backend verlegt und eine nahtlose Verwendung verschiedener Anwendungsteile ermöglicht. Mit der immer weiteren Verbreitung nativer mobile Apps fällt auch ihre Verwendung dem Nutzer immer leichter. Dennoch ist es nicht so, dass die Ära der Browser-Technologien vorbei wäre. Um ein User-Interface zu generieren, das möglichst gut an verschiedene Zwecke anpassbar ist und den Nutzer vor wenig Hürden stellt, eignen sich immer noch die klassischen Browser am besten.

 

Aufmacherbild: House, design, drawing via Shutterstock / Urheberrecht: kazoka

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -