© SeamlessPatterns/Shutterstock.com
Gängige Patterns zur Integration unterschiedlicher Backend Services im Browser

Optionen der Frontend-Integration


Die Integration von Daten und Funktionalität im Frontend ist ein mächtiges, aber trotzdem relativ selten beleuchtetes Thema. Wir versuchen, gängige Muster aufzuzeigen und mögliche Vor- und Nachteile zu benennen.

Systemgrenzen sind aus Nutzersicht tendenziell ein Ärgernis. So ist die Modularisierung von Systemen ein rein technisch motiviertes Thema, das reibungslosen Arbeitsabläufen ohne größere Kontextverluste nicht im Wege stehen sollte.

Haben wir also „aus Gründen“ unsere Systeme zerschnitten, müssen wir diese für die Nutzer zumindest im Frontend auch wieder zusammenführen. Das kann an verschiedenen Stellen passieren: Statische übergreifende Dinge wie Layouts kann man im Build oder Deployment integrieren. Bei dynamischen Inhalten kann man im jeweiligen Backend dafür sorgen, dass es sich die notwendigen Informationen aus anderen Systemen besorgt. Dabei kann es sich zum einen um direkte Aufrufe zu einem anderen System zur Bearbeitung des unmittelbaren Requests handeln. Man benötigt in diesem Fall also eine Antwort eines anderen Systems, um den eigenen Request zu beantworten. Es kann sich zum anderen aber auch um von Requests losgelöste Interaktionen handeln, wie beispielsweise eine Feed-basierte Replikation von Daten.

Aus meiner Sicht jedoch ist die Integration im Frontend der Königsweg, genauer gesagt die Integration im Browser der Benutzer. Diese Art der Integration ist meist leichtgewichtiger und performanter. Außerdem hat sie den grundsätzlichen Vorteil, dass sie im Endgerät des Nutzers erfolgt und somit die eigenen Systeme (also die Backends) nicht auf das jeweils andere System warten müssen, womit sie ihre eigene Antwort verzögern würden (Abb. 1).

schulte_coerne_frontend_1.tif_fmt1.jpgAbb. 1: Problem der Integration mehrerer Backends

Über die ersten beiden Optionen wurde schon viel gesagt und geschrieben. Daher soll es hier um die dritte gehen: die Frontend-Integration. Dafür gibt es, wie so oft in der IT, nicht nur eine einzige Möglichkeit der Umsetzung, sondern viele. Einige davon wollen wir nachfolgend auflisten. Die Auflistung beginnt mit dem Quasistandard von heute. Dabei handelt es sich um die monolithische Single Page App (SPA) im jeweiligen Trendframework des Entstehungsjahrs der App.

Monolithische SPA

Der laufende Microservices-Hype ist in meinen Augen primär ein Backend-Hype. Das bedeutet, dass viele Microservices-Architekturen in einer reinen Backend-Perspektive entstanden sind. Findet man dann Zeit, sich um das „kleine Problem“ des Frontends zu kümmern, und nimmt den gleichzeitigen Single-Page-Hype hinzu, erscheint es logisch, die Backends auf Ebene ihrer APIs zu integrieren. Man baut also eine Single Page App (SPA), typischerweise mit einem speziellen Team von UI-/SPA-Experten. Diese App macht dann in der Regel Ajax-Aufrufe gegen die REST-APIs der Backend-Teams.

Überzeugend ist bei diesem Konzept, dass das Web-Frontend ein völlig eigenständiges System darstellt. Es reiht sich damit nahtlos neben anderen Consumer-Systemen wie dem Mobile-Client für iOS oder den Aufrufen eines Partnerunternehmens ein, ganz so, wie man sich das auf dem Papier beziehungsweise dem Flipchart wünscht (Abb. 2).

schulte_coerne_frontend_2.tif_fmt1.jpgAbb. 2: Integration in einer monolithischen SPA

Leider ergeben sich bei genauerem Hinsehen dann aber schon einige technische Probleme:

  • Öffentliche APIs müssen allesamt Querschnittsthemen wie Authentifizierung oder ganz grundsätzlich Security adressieren. Das lässt sich aber in der Regel mit Infrastruktur irgendwie lösen.

  • Die Orchestrierung von Service-Aufrufen gegen unterschiedliche Backends über das Internet ist, wenn man es naiv angeht, alles andere als performant. Insbesondere wenn es sich um mobiles Internet handelt.

  • Hierfür gibt es dann keine einfachen technischen Lösungen mehr, sondern nur noch architektonische: Das Backend-for-Frontend-Pattern hilft aus, indem man dem Frontend-Team erlaubt, sich ein (typischerweise auf Node.js basierendes) Backend-System zu bauen. Dieses spezielle Backend-System übernimmt die Orchestrierung der eigentlichen Backends und kann dadurch deutlich kompakter und performanter mit dem Frontend kommunizieren.

Das Hauptproblem bei diesem Ansatz ist aber kein technisches, sondern ein organisatorisches: Dadurch, dass man ein spezielles Querschnitts-Frontend-Team erfunden hat, verstößt man letztendlich gegen die Grundidee von Microservices. Diese besagt nämlich, Teams und Systeme rund um Geschäftsbereiche zu schneiden, was bei einem Querschnittsteam einfach niemals der Fall sein kann (sonst wäre es kein Querschnittsteam). In der Konsequenz ist es beispielsweise schwer vorstellbar, dass ein neues Feature allein von einem Team umsetzbar sein könnte. Denn in der Regel benötigt jede neue Funktionalität im Backend eine Entsprechung im Frontend (und umgekehrt), um sie überhaupt benutzen zu können.

Pro:

  • Es gibt eine strikte Trennung zwischen Backends und dem einen Frontend.

  • Monolithische Single Page Apps sind State of the Art.

Contra:

  • Man muss mit allen Nachteilen eines Monolithen sowie mit allen Nachteilen davon umgehen, trotzdem mehrere Teams zu haben.

  • SPA-Technologien sind kurzlebig. Man macht sich extrem abhängig von einem einzigen Framework-Hersteller.

Modulare SPA

Das organisatorische Problem einer monolithischen SPA ist allerdings mit technischen Mitteln und einigem Aufwand teilweise adressierbar. Dazu zerteilt man die SPA in mehrere Module, die von den jeweiligen Fachteams bereitgestellt werden. Das bedeutet, es gibt no...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang