• Angular

    Angular ist eines der modernsten und bekanntersten Webframeworks für Single-Page-Anwendungen. Durch die Erweiterung des normalen HTML-Vokabulars und einem Two-Way-DataBinding ist die Entwicklung mächtiger Web-Apps für Desktops und Smartphones möglich. Die gute Testbarkeit von Angular unterstützt die Erstellung von Anwendungen in höchster Qualität und Stabilität. Seit der Version 2 wird Angular in TypeScript entwickelt. Dies ermöglicht eine strikte Typisierung, was enorm zur besseren Wartbarkeit von großen Projekten beiträgt.
    Angular ist die erste Wahl für komplexe Webanwendungen.

  •  

    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.

    Single Page Microservice UI
    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
    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 Problems
    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.

    Different UI Libs
    Unterschiedliche UI Frameworks

     

    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.