© SeamlessPatterns/Shutterstock.com
Entwickler Magazin
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.

Till Schulte-Coerne


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).

Abb. 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 A...

Entwickler Magazin
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.

Till Schulte-Coerne


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).

Abb. 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 A...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang