Integrationsmuster für Web-Frontends

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Anja Kammer: Hallo und herzlich willkommen zum INNOQ Podcast. Heute sprechen Tammo van Lessen und Till Schulte-Coerne über Integrationsmuster für Web-Frontends. Hallo.

Tammo van Lessen: Hallo Anja.

Till Schulte-Coerne: Hallo Anja.

Anja Kammer: Stellt euch doch bitte einmal kurz vor.

Tammo van Lessen: Ja, ich bin Tammo, ich bin Principal Consultant bei der INNOQ. Bin, glaube ich, schon seit 12 Jahren dabei und mache hauptsächlich Architekturdinge, die mich interessieren. Ich habe verschiedene Stationen durchlaufen, solche Dinge.

Till Schulte-Coerne: Ja, ich bin Till, ich bin schon ewig bei der INNOQ, länger als Tammo, und beschäftige mich relativ viel mit Web-Themen, Web-Architektur, Web-Softwareentwicklung.

Anja Kammer: Super. Ja, wir sind heute hier versammelt, weil ihr ein Paper geschrieben habt. Ihr habt im Grunde eine Taxonomie entwickelt mit sechs Integrationsmustern für Web-Frontends. Welches Problem wolltet ihr denn damit lösen? Warum braucht es jetzt diese Taxonomie auf einmal?

Till Schulte-Coerne: Ja, wir hatten im Prinzip immer schon das Problem, dass wir aus verschiedenen Gründen, können wir ja gleich vielleicht noch drauf kommen, immer wieder um dieses Thema Frontend-Integration gekreist sind und einfach bei diesem Thema eine belastbare Quelle fehlte. Also wir hatten immer das Problem, dass wir etwas zitieren können wollten, dass man eben einfach mal Leuten sagen kann: „Wenn du wissen willst, wie man Frontend integriert, welche Optionen du dafür hast, dann schau doch einfach mal da." Und ja, da hat Tammo die EuroPLoP vorgeschlagen. Kannst ja vielleicht mal ein paar Töne dazu sagen, Tammo?

Tammo van Lessen: Ja, klar. Ich wurde nämlich auch immer darauf angesprochen. Ich hatte auch so einen akademischen Hintergrund und meine Bekanntschaften von damals haben mir mal gesagt, man muss unbedingt mal zu EuroPLoP. Und tatsächlich, das Thema Patterns war mir schon immer irgendwie sehr wichtig. Ich hatte damals so ein Aha-Erlebnis, als ich, glaube ich, das erste Mal dieses Buch von Hohpe gelesen hatte und verstanden habe: Wenn andere das auch gelesen haben, kann ich mich total effizient mit denen ausdrücken. Wenn ich sage „Competing Consumer", wissen alle sofort, was gemeint ist, und der Kontext darum ist gesetzt. Das passt ganz gut zu diesen ganzen KI-Diskussionen im Übrigen, weil da ist es genauso: Wenn der Kontext allen klar ist. Aber genau, ich will nicht zu weit abschweifen. Genau, und wie kommen diese Patterns zustande? Da gibt es eine ziemlich große oder verteilte Pattern-Community, die sich darum bemüht, im Grunde so eine Art Katalog oder die Pflege von solchen Patterns und Pattern Languages zu entwickeln. Ursprünglich kommt das, glaube ich, von dem Architekten Christopher Alexander, der damals irgendwie gesagt hat: „Wir können doch Architektur nicht immer dem Zufall überlassen, sondern brauchen wiederkehrende Muster." Wir haben wiederkehrende Probleme und dafür brauchen wir wiederkehrende Lösungen. Und bei Software ist es ja im Grunde genauso, und das wurde dann irgendwann mal adaptiert. Ich glaube, diese Gang-of-Four-Leute waren dann da ziemlich am Anfang, die so etwas gemacht haben. Und daraus sind eben diese Konferenzen entstanden, die halt lustigerweise gar nicht so Konferenzen sind, wie man sie sonst in Academia kennt, sondern einen sehr interaktiven Teil haben. Also im Grunde läuft es so, dass man erstmal, wenn man da etwas einreicht, man mit einem Abstract aufschlägt, und wenn das Programmkomitee das für vernünftig hält, was man da einreicht an Patterns oder Pattern Language, also irgendwie eine zusammenhängende Sprache von Mustern, dann kriegt man einen sogenannten Shepherd zugewiesen, der dann über einen längeren Zeitraum mit einem an diesem Paper arbeitet, immer wieder kontinuierlich Feedback gibt, und man dann dieses Paper im Grunde schärft und entsprechend diesen Anforderungen an Patterns – da kommen wir vielleicht gleich noch mal kurz dran – sozusagen ausformuliert. Und dann, wenn es dann gut genug ist und akzeptiert wird, dann trifft man sich zu so einem Workshop. Und das ist tatsächlich ganz cool, das ist bei der EuroPLoP im Kloster Irsee, das ist wirklich eine traumhafte Kulisse, ist so ein Kloster mit angebundener Brauerei. Man hat also keinen Grund, das Gelände jemals zu verlassen eigentlich über den Zeitraum.

Till Schulte-Coerne: Es gibt aber auch einen schönen See, wenn man 10 Minuten geht, da waren wir ja auch, nicht nur eine Brauerei.

Tammo van Lessen: Richtig.

Till Schulte-Coerne: Nicht nur eine Brauerei.

Tammo van Lessen: Genau, es gibt sehr viele Möglichkeiten, sich da sozusagen auszutauschen und zu inspirieren. Und dann gibt es neben aller möglichen Kennenlern-Rituale erstmal diese Workshops, wo dann bestimmte Gruppen, also die versuchen Gruppen zu finden, die thematisch so ein bisschen besser zueinander passen. Und die zerreißen dann nach allen Regeln der Kunst diese Papers. Also das ist alles sehr konstruktiv angelegt. Man muss auch vorher dann, ich glaube, wir hatten sechs Papers in unserem Workshop, man muss die dann alle vorher mal gelesen haben oder wirklich durchgearbeitet haben. Und dann gibt es eben dieses Ritual, dass der Autor dann die „Fly on the Wall" wird, also sprich die Fliege an der Wand. Man darf nichts mehr sagen, sich nur noch Notizen machen, dreht sich auch so mit dem Rücken zu den anderen und muss dann sozusagen das Feedback über sich ergehen lassen. Das weist sozusagen dann erstmal über die positiven Dinge und den Stil und dann über die inhaltlichen Dinge. Und das Auditorium bedankt sich auch immer sehr dafür, dass man dieses Paper geschrieben hat. Das ist wirklich eine sehr wertschätzende Atmosphäre und Geschichte, und man kriegt halt wahnsinnig gutes Feedback auch dadurch, dass man eben nicht reingrätschen darf und sagen kann: „Ja, das habt ihr alles falsch verstanden, das haben wir doch so und so gemeint." Offensichtlich hat man es ja dann so gelesen, wie sie das da verstanden haben und nicht so, wie wir es gemeint haben. Und genau, das war wirklich sehr cool, und diese ganzen Geschichten hatte ich halt vorher schon mal gehört, dass man da unbedingt mal hin muss. Und wir hatten ja schon in verschiedenen Blogposts dieses Thema angerissen, und auch in meinen Projekten ist es immer so, dass Frontend-Integration immer ein wiederkehrendes Thema ist. Es ist aber schwierig, das zu erklären, zu verkaufen, zu sagen: „Wie funktioniert es denn jetzt tatsächlich?" und darauf zu verweisen. Und deswegen genau habe ich gedacht: „Hey, das ist eine gute Idee, da mal gemeinsam uns auf diese Reise zu begeben und das zu machen." Und es war auch echt ganz cool, weil wir dachten eigentlich, wir wissen genau, was wir da aufschreiben müssen. Aber dieser Weg dahin, also schon beim Shepherding hat man schon ein paar Sachen noch mal irgendwie gemerkt.

Till Schulte-Coerne: Also tatsächlich war alleine der Prozess, dass wir uns sehr intensiv darüber ausgetauscht haben, wie man diese Patterns, die wir eigentlich schon lange kennen – das war irgendwie nichts Neues. Das ist ja auch eigentlich der Sinn von einem Pattern. Ein Pattern heißt ja eigentlich, dass man etwas beobachtet hat, was wiederkehrt, und nicht, dass man etwas Neues vorschlägt. Also wir haben uns da jetzt keine Sachen aus den Fingern gesogen, da ist auch nichts, was wir in irgendeiner Form erfunden hätten oder so, sondern diese Patterns sind einfach nur eine Sammlung von Dingen, die wir immer wieder gesehen haben. Die haben wir de facto ja immer gesehen. Und alleine die Frage, wie man so etwas katalogisiert, wie man so etwas strukturiert, wie man alleine die Einleitung dafür schreibt, hat mir unglaublich viel gebracht, weil es sehr viel Klarheit aus der Diskussion mit Tammo für mich gegeben hat, die ich vorher überhaupt nicht hatte, und danach noch mal mit unserem Shepherd. Also wir hatten wirklich einen ganz hervorragenden Shepherd, den Cesare Pautasso, der uns wirklich geniales Feedback gegeben hat zu dem Paper schon und danach dann in der Runde. Ich konnte tagelang vorher nicht schlafen, weil ich so einen Schiss hatte, die Fliege an der Wand zu sein. Das ist wirklich unangenehm für jemanden, der das nicht kennt, aber die Atmosphäre auf dieser Konferenz ist wirklich unglaublich, weil sie unfassbar viel Wert darauf legen, dass das eine Konferenz auf Augenhöhe ist, wo jeder mit jedem immer respektvoll umgeht. Es war wirklich großartig, wie das funktioniert hat. Man muss sich vorstellen, da laufen nur gestandene Professoren rum und teilweise deren eigene Studierende, und die sollen sich auf Augenhöhe Feedback geben, konstruktives Feedback zu etwas, wo Leute wirklich Arbeit rein investiert haben, und das hat wirklich funktioniert, weil diese Konferenz einfach insgesamt so aufgezogen ist, dass sich jeder irgendwie ein bisschen lächerlich macht, dass jeder auf Augenhöhe ist. Das war wirklich ein ganz großartiges Erlebnis. Aber jetzt bin ich schon wieder abgeschweift, deswegen wollte ich eigentlich über das reden, was uns dabei klar geworden ist. Und woran ich mich zum Beispiel noch erinnern kann, was an so einer Diskussion mit Tammo in einem Hotelkonferenzraum mal so klar wurde, ist zum Beispiel: Was ist eigentlich Frontend-Integration? Wir haben früher immer über Frontend-Integration geredet, wir haben irgendwie immer gesagt, ja, es gibt irgendwie Transklusion und keine Ahnung, irgendwelche Komponenten, Web Components oder Single Page Application monolithisch, aber wir haben uns nie darüber Gedanken gemacht, warum wir denn das eine dafür halten, dass es Frontend-Integration ist, und das andere irgendwie nicht. Und Tammo und ich haben dann irgendwann mal eine für mich gute Definition davon gemacht, was wir eigentlich unter Frontend-Integration verstehen. Und das ist im Prinzip, dass man sagt: Ein Provider stellt einen Teil einer UI bereit, den ich in mein System integriere. Also wenn ich das vergleiche mit der altbekannten Backend-Integration, wenn ich ein Backend-Integrationsmuster habe, zum Beispiel eine datenbasierte Integration oder eine funktionale Integration, dann funktioniert das ja typischerweise so, dass zum Beispiel ein Backend einen Event-Feed bereitstellt oder eine HTTP-API, die ich aufrufen kann, die Funktionalität exponiert, und jemand anders integriert das, indem er diesen Feed abonniert oder das Backend per HTTP aufruft, also die Funktionalität im Prinzip aufruft. Und Frontend-Integration ist eigentlich genau das Gleiche, unserer Meinung nach, nur dass man eben nicht irgendeinen HTTP-Request macht, sondern dass man einen Teil einer UI integriert, den jemand anders zur Verfügung stellt. Also ein anderes Team im Normalfall, ein anderes System zumindest, ist dafür verantwortlich, einen Teil einer UI zu bauen, den ich, ohne wirklich viel zu wissen darüber, wie genau dieser Teil der UI seine Funktionalitäten abbildet, wie genau da der Klick-Flow ist, einfach integrieren kann. Und das ist etwas gewesen, was mir eigentlich eine sehr große Klarheit gebracht hat, weil das im Prinzip einfach bedeutet: UI-Integration, die Muster, über die wir gleich reden, sind einfach eine bestimmte Spielart einer API. Also eine Remote-API, genau wie eine HTTP-API oder irgendwelche Messaging-Infrastrukturen APIs sind, die eben auch unglaubliche Probleme haben, wenn man sie einbindet, weil irgendwo muss ich mich immer koppeln, wenn ich fremde Systeme integriere. Aber die eben umgekehrt, was die UI anbelangt, zumindest eine relativ lose Kopplung bereitstellen, weil der Vorteil bei der UI-basierten Kopplung einfach der ist, dass ich relativ wenig Annahmen darüber machen muss, was das fremde System in diese UI einbettet, und dadurch das bereitstellende System, das Team, das für das bereitstellende UI-Fragment verantwortlich ist, eine unglaublich hohe Autonomie hat. Ich kann einfach entscheiden, ich möchte dort neue Funktionalitäten, neue Buttons, neue UI-Teile einbauen, und muss die Leute, die mein UI benutzen, im Prinzip gar nicht großartig drüber informieren. Das heißt: Was für uns ein sehr wichtiger Aspekt war, als wir das Paper geschrieben haben, war, dass wir auch definiert haben, dass UI-Integration zur Laufzeit stattfinden muss. Also es gibt auch ganz viele Integrationsmuster, die zur Compile-Zeit stattfinden, die könnte man theoretisch auch mal dokumentieren, aber das, was für uns jetzt in dem Paper, was wir jetzt geschrieben haben, quasi die Baseline war, war, dass wir eben gesagt haben: Ich habe ein UI-Fragment von jemand anderem und möchte das zur Laufzeit in mein System integrieren, und wenn die bereitstellende Partei etwas an diesem UI-Fragment ändern möchte, dann können sie das einfach tun, ohne dass sie die einbettenden Systeme notifizieren muss, dass sich da jetzt etwas geändert hat.

Tammo van Lessen: Ja, das Coole war ja auch, fand ich, dass ganz viele Sachen haben wir in den SCS schon beschrieben, dass wir da auch über Frontend-Integration reden –

Anja Kammer: Magst du noch mal kurz erzählen, was SCS sind?

Tammo van Lessen: Entschuldigung, Self-Contained Systems. Das ist ja im Grunde einer unserer Go-to-Architekturansätze, bei denen wir das Gefühl haben, die funktionieren in vielen Fällen sehr gut. Man kann sie vielleicht auch als grobgranulare Microservices beschreiben, aber wir haben ganz oft Diskussionen darüber, ist das jetzt ein reiner SCS oder nicht? Wir achten da sehr drauf, dass die Definition von SCS, so wie wir sie auf der Webseite beschreiben, möglichst rein ist. In der Praxis gehen wir dann doch auch Kompromisse ein und machen mal da irgendwie Abstriche oder so. Aber das Interessante war halt: Wir haben da viele Dinge beschrieben, irgendwie gibt es auch API-Zugriffe, wir wollen aber viel Frontend-Integration machen, die Dinger sind autonom. Aber ganz vieles ist irgendwie klar geworden, wenn man das halt so in diese Kategorien einsortiert, wie wir es jetzt dann da gemacht haben, dann ergibt sich ganz vieles so automatisch daraus: Einfach alles ist eine API. Es gibt aber verschiedene Ebenen, auf denen man integrieren kann. Man kann in der Datenbank integrieren, man kann Data Products bereitstellen, so wie unsere Datenleute das mit Data Mesh machen – das ist sozusagen auch eine Art zu integrieren –, dann haben wir die Integration über die Business-Logik und dann haben wir eben die Integration über die UI. Und wenn man das aber alles als Schnittstelle begreift, die unterschiedlich starke Kopplung bereitstellt, dann hat man halt plötzlich ein Händel dran, vernünftige Entscheidungen zu machen und zu sagen: Wann lohnt sich das eine, wann lohnt sich das andere, wann sind die Aufwände dafür zu groß, wann wollen wir das eingehen, etc.

Anja Kammer: Dann sind wir ja schon bei einem sehr wichtigen Punkt: Anhand welcher Aspekte unterscheide ich, wann welches Muster am besten geeignet ist? Also es hat bestimmt auch was damit zu tun, was ich damit erreichen will – Team-Autonomie, Performance, Konsistenz der User Experience und so weiter. Ihr habt euch da bestimmt Gedanken gemacht. Erzählt mal.

Till Schulte-Coerne: Wir mussten uns dazu Gedanken machen. Wenn man ein Pattern dokumentiert, funktioniert das typischerweise so, dass man sich immer an die gleiche Struktur hält. Womit man typischerweise anfängt, wenn man so ein Pattern dokumentiert, sind natürlich erstmal die Rahmenbedingungen, aber danach eben unterschiedliche Kräfte oder „Forces" auf Englisch, die auf meine Architekturentscheidung einwirken. Im Fall von der Frontend-Integration gibt es eine gewisse Menge von Einwirkungskräften, von Rahmenbedingungen, die im konkreten Fall unterschiedlich sein können. Baue ich einen Online-Shop, ist das komplett anders, als wenn ich ein Kundenportal für eine Versicherung baue, zum Beispiel. Das ist einfach nicht das Gleiche. Gewisse Forces kehren wieder. Gewisse Dinge sind einfach immer die gleichen bei all diesen Frontend-Integrationsmustern. Du hast ja schon eins genannt: Unabhängigkeit von Teams ist das, was wir erreichen wollen. Das ist etwas, das wollen wir immer haben, aber der Grad der Unabhängigkeit kann natürlich unterschiedlich sein. Kann das fremde Team in sein UI beliebiges CSS einbauen, beliebiges Styling machen, oder muss sich das fremde Team an bestimmte Styling-Vorgaben halten? Das ist ja eine Frage der Autonomie. Kann ich einfach irgendwie Tailwind benutzen und die anderen benutzen Bootstrap, oder müssen alle dieselbe Bootstrap-Version verwenden? Die Unabhängigkeit ist kein Ja-Nein, wie immer, sondern das ist ein Spektrum, in dem man sich aufhalten muss. Dasselbe gilt dafür, dass man zum Beispiel die Anwendung weiterentwickeln kann, also dass man neue Features einbringen kann, ohne dass das die anderen in irgendeiner Form instabilisiert. Da gibt es natürlich auch sehr unterschiedliche Ansätze. UX ist ein sehr wichtiger Punkt. Wie stark ist mein UI dann, das ja am Ende im Optimalfall aus verschiedenen Elementen verschiedener autonomer bereitstellender Systeme gekapselt ist – wie eng ist mein UI dann am Ende des Tages doch wieder gekoppelt? Wenn ihr euch jetzt zum Beispiel vorstellt, wir haben ein Dashboard, wo auf dem Dashboard fünf verschiedene Kacheln sind, die von fünf verschiedenen Systemen kommen, dann kann es natürlich sein, dass es Aspekte gibt, die dieses Dashboard doch dann sehr stark wieder koppeln. Zum Beispiel könnte ich einen globalen Filter für einen Zeitraum haben, den ich in diesem Dashboard anzeigen möchte. Ich möchte irgendwo eine Eingabemöglichkeit haben, um eine Zeitspanne einzugeben, und dann sollen sich in all diesen fünf Kacheln von den fünf verschiedenen Systemen sofort alles ändern. Da gibt es natürlich Frontend-Integrationsmuster, mit denen man so etwas sehr leicht erreichen kann, aber das geht nicht mit jedem Frontend-Integrationsmuster. Ein ganz wichtiger Aspekt, der auch wirklich leider keine wirklich zufriedenstellende Antwort hat, ist das Thema Authentifizierung. Wenn ich in einem Browser – wir reden ja über Web-Integrationsmuster typischerweise – hinter einem Single Sign-On-System zum Beispiel Dinge integrieren möchte, dann ist das, wenn ich wirklich eine sehr hohe Autonomie haben will in der Entwicklung der einzelnen Frontend-Bestandteile, kein ganz triviales Thema. Das ist etwas, das kann sehr stark wehtun, abhängig davon, für welches Pattern ich mich im Prinzip entscheide.

Tammo van Lessen: Ich stimme dir da zu, aber das ist an anderen Stellen halt auch ein Problem. Ich würde nicht unbedingt sagen, dass das jetzt etwas ist, was dagegen spricht. Wenn wir jetzt mal das allereinfachste Pattern einmal kurz rausnehmen, den Link: Wenn ich auf eine andere Seite springe, dann muss ich mich halt zur Not neu authentifizieren. Aber dann ist es halt auch einfach erledigt, und ich muss nicht hintenrum irgendwelche Verrenkungen machen, dass das irgendwie funktioniert. Ich finde, dass auch das auf das Spektrum dazugehört, dass manche Dinge damit auch sehr viel einfacher sind, wenn man an der UX vielleicht an ein paar Stellen auch bereit ist, Kompromisse einzugehen. Das erlebe ich halt in der Praxis oft, dass diese Kompromisse oft nicht mitgedacht werden, und deswegen finde ich helfen diese Patterns auch, weil sie die Punkte, an denen man Kompromisse möglicherweise eingehen muss, klar benennen und man weiß: Da musst du dran denken, wenn du das gut findest.

Till Schulte-Coerne: Das kann man, glaube ich, auch jetzt einfach vorwegnehmen: Selbst wenn man sich dieses Paper irgendwie besorgt und sich das durchliest, da ist keine Silver Bullet dabei. Es ist einfach nicht so, sondern es gibt halt diese Forces, diese unterschiedlichen Einflüsse. Es gibt ein Pattern, was ich auswählen kann, was ich umsetzen kann, und dieses Pattern hat Konsequenzen. Authentifizierung wird zum Beispiel schwierig, Authentifizierung wird vielleicht unmöglich – kann sein, dann ist es das falsche Pattern, wenn ich damit ein Kundenportal für eine Versicherung machen will, zum Beispiel. Umgekehrt ist eben genau das Ziel des Papers auch gewesen, das in irgendeiner Form klarzumachen: Wenn ich das mache, welche Konsequenzen hat diese Entscheidung, und wenn die Konsequenz nicht zu meinen Anforderungen passt, dann sollte ich es tunlichst sein lassen.

Anja Kammer: Dann stell doch mal die sechs Pattern vor. Eins haben wir ja schon, also den Link, den Hyperlink. Wollt ihr dazu noch etwas sagen?

Till Schulte-Coerne: Das ist tatsächlich etwas – das hat unser früherer Chef Stefan immer so schön gesagt –, das ist das magische Integrationskonzept des Webs. Eigentlich ist das gesamte Web ja ein gigantisches Frontend-Integrationsexperiment. Ich bin erst auf der UI von einer unabhängigen Partei und dann lande ich plötzlich, indem ich einem Link folge, auf der UI einer anderen unabhängigen Partei. Das ist tatsächlich etwas, wo ich sagen würde: In jeder Frontend-Integration im Web würde ich erwarten, dass das funktioniert. Der Link ist sozusagen das, was meiner Meinung nach immer funktionieren sollte, was natürlich auch ganz klare Nachteile hat, weil die Art von Frontend-Integration, die ich gerade gepitcht habe – ich habe ein UI, und das besteht aus verschiedenen Modulen verschiedener unabhängiger Teams –, das erreiche ich natürlich durch einen Link nicht. Ein Link bringt Dinge in einer zeitlichen Ebene hintereinander. Ich bin erst auf Seite eins, danach auf Seite zwei, danach auf Seite drei. Da gibt es aber einen sehr interessanten Sonderfall, das ist so ein Sub-Pattern, das ist quasi unser zweites Pattern. Das ist die Frage: Ich bin erst auf Seite eins, dann bin ich auf Seite zwei. Jetzt bin ich auf Seite zwei fertig – was mache ich denn dann? Wie komme ich wieder zurück auf Seite eins? Das ist etwas, das haben wir auch kurz erwähnt, weil das eigentlich ein totaler No-Brainer ist, so etwas zu machen: dass man sich eben die Gedanken darüber macht, wie ein System, das abspringt, dem anderen System mitgibt, wie ich wieder zurückkommen kann, wenn das andere System fertig ist. Stellen wir uns vor, wir erfassen gerade einen neuen Vertrag, irgendein Verkaufsdokument in irgendeinem System. Jetzt haben wir die ganzen Artikel hinzugeklickt, und jetzt fehlt der Kunde – wir können den Kunden noch nicht auswählen. Das ist ja die Frage: Wie kann ich jetzt den Kunden per Link anlegen in einem anderen System, das für die Kundenverwaltung verantwortlich ist, und danach wieder in die Vertragsverwaltung zu dem neuen Vertrag zurückspringen? Das ist natürlich eigentlich relativ simpel. Man gibt einfach beim Absprung in das andere System eine URI mit, die das Kundensystem aufrufen kann oder wohin es redirecten kann, wenn es mit der Kundenanlage fertig ist. Das sind dann Return-URIs oder Rücksprung-URIs, die man einfach per Konvention mitgeben muss und wo man dann aber auch, wenn man sich auf so eine Architektur festlegt, relativ konsequent dafür sorgen muss, dass die Systeme untereinander dieselben Konventionen haben, wie man mit diesen Return-URIs umgeht. Das kennen wir zum Beispiel aus den Single Sign-On-Protokollen, die es so gibt. Wenn ich irgendwie OpenID Connect habe und ich logge mich irgendwo ein bei einem solchen OpenID Connect Provider, dann will ich ja, nachdem ich mich eingeloggt habe, wieder dahin zurückspringen, wo ich abgewiesen wurde, weil ich noch nicht eingeloggt war. Auch so etwas passiert typischerweise über Return-URIs. Die Kunst bei diesen URIs ist, dass man sie nicht vergisst. Wenn ich so eine Return-URI übergebe, dann den Kunden anlege, dann ist das, was man dabei berücksichtigen muss, dass man Mechanismen hat, dass diese Return-URI durch den Kundenanlageprozess konsequent durchgeschleppt wird, damit ich dann nicht im letzten Schritt diese URI vergessen habe. Und das bedeutet, dass man in seiner Anwendung bestimmte Vorkehrungen haben muss, damit das relativ einfach funktioniert. Ist aber ein extrem mächtiges Muster, was aber auch wieder Konsequenzen hat, natürlich.

Tammo van Lessen: Aber auch eins, was, finde ich, immer unterschätzt wird. Wir haben jetzt in der Praxis halt auch oft, dass wenn man diese agilen Prozesse – oder ich weiß gar nicht, ob es mit den agilen Prozessen zu tun hat – wenn jemand von der Anforderung kommt, dann wird irgendwo ein Ticket eingestellt: „Hier, wir müssen diesen Vertrag noch mit anzeigen."

Till Schulte-Coerne: Genau.

Tammo van Lessen: Und eigentlich muss man den gar nicht anzeigen an der Stelle. Da hilft vielleicht die Vertikalisierung, dass man dann darüber nachdenkt, weil es plötzlich teurer ist, etwas anzuzeigen, von dem man die Daten gar nicht im Zugriff hat.

Till Schulte-Coerne: Genau.

Tammo van Lessen: Aber es ist teilweise so einfach, einfach auf den Link zu springen, der öffnet sich in einem neuen Tab, da kann sich ein Sachbearbeiter etwas angucken und schließt den halt wieder, wenn er fertig ist. Auch das hat Stefan schon vor Jahren immer gesagt. Nur das Interessante ist, dass das halt nicht irgendwie so einfach als ganz offensichtlich und ganz „easy" in den Köpfen ist.

Anja Kammer: Du hattest gerade den Begriff Vertikalisierung genannt. Magst du den kurz erklären?

Tammo van Lessen: Ja, auch das ist ein Einschub. Auch das ist etwas, was wir hier sehr gerne bei INNOQ machen und was ein Treiber in unseren SCS-Architekturen ist: dass wir versuchen, die Dinge, die eine hohe fachliche Kohärenz haben, zusammen in ein System zu stecken. Und andere Dinge, die nicht so fachlich gekoppelt sind oder die wieder so eine Blase sind, die einen hohen fachlichen Zusammenhang haben, in ein anderes System zu stecken. Das kann man sich im Grunde wie verschiedene Vertikalen vorstellen, die von Ende zu Ende, also von der UI bis zur Datenhaltung, mit einem Team relativ autonom an dieser Sache arbeiten können. Uns gefällt das deshalb gut, weil die Teams eine gewisse Expertise zu allen Vertragsthemen oder so aufbauen können und über High-Level-KPIs gesteuert werden können, sodass sie einfach selber überlegen, wie sie ihre Vertikale zu einem besseren Resultat im Gesamtkontext bringen. Grundsätzlich geht es darum, dass sich die Teams nicht auf den Füßen stehen, dass man die Komplexität von so ganz großen Gesamtsystemen zerteilen kann in Systeme, die eine gute Größe haben. Da kann man wieder die berühmten zwei Pizzaschachteln rausholen, die mit zwei Pizzen ernährt werden können. Ich weiß immer gar nicht, auf welche Zeiteinheit diese Pizzaschachtel halten muss.

Anja Kammer: Was man vielleicht noch dazu sagen sollte: Es geht bei diesen Integrationsmustern um die Integration von mehreren Vertikalen.

Tammo van Lessen: Ja, also jetzt in der Sprechweise würde ich das, glaube ich, sagen. Genau, wir wollen uns jetzt nicht festlegen, dass man das nur in vertikalisierten Systemen machen kann, deswegen würde ich sagen: Der Übergang zwischen zwei Systemen oder die Integration zwischen den Frontends zweier Systeme – das ist eigentlich das Interessante.

Till Schulte-Coerne: Wobei jetzt ganz konkret zum Beispiel die Return-URIs und die Links natürlich auch ein hervorragendes Integrationskonzept innerhalb einer Anwendung sind. Aber natürlich, normalerweise, wenn wir über Frontend-Integration reden, dann reden wir genauso wie bei allen anderen Backend-API-Strukturen über die Integration fremder Systeme. Typischerweise ruft man ja auch nicht seine eigene Backend-API auf – auch wenn das manchmal eine gute Idee ist, aber das ist nicht der Standard-Use-Case.

Anja Kammer: Ein anderes Bild, das ich hatte, als du, Till, über Hyperlinks gesprochen hast, war das Bild von Amazon und diesem unfassbar großen Menüband. Je nachdem, wo ich da draufklicke, lande ich manchmal gefühlt in einer komplett anderen UI. Das Einzige, was noch gleich ist, ist irgendwie der Banner und das Menü, aber ansonsten –

Till Schulte-Coerne: Genau, das Amazon-Grau und Orange erkennt man wieder, aber der ganze Rest ist weg.

Anja Kammer: Ja, also die UI unterscheidet sich dann schon. Das ist doch auch eine Integration über Links, oder?

Till Schulte-Coerne: Genau, über das Menüband. Ja, genau. Im Prinzip ist die Herausforderung bei so einer hyperlink-integrierten UI vor allem die Wiedererkennung: „Bin ich überhaupt noch da?" Weil ob ich jetzt zu Google abspringe und das sieht dann anders aus, oder ob ich in unseren Checkout-Prozess reinkomme – woher weiß ich, dass es immer noch unser Checkout-Prozess ist und nicht der von irgendjemand anderem? Man muss im Prinzip typischerweise, um diese Patterns umzusetzen, sich Gedanken darüber machen, wie eigentlich eine konsistente UX aussieht oder wie eine konsistente UI-Komponentenbibliothek aussieht, damit man zwischen verschiedenen Elementen dieser UI immer noch die gleiche Firma, die gleiche Webseite erkennt. Obwohl das Ziel von uns ja technisch eigentlich immer ist, dass wir uns so benehmen, als wären wir nicht zusammenhängend. Wir wollen, dass die Teams komplett autonom sind, wir wollen, dass die Teams ihre UIs völlig unabhängig voneinander weiterentwickeln können, wir wollen, dass die einen Bootstrap benutzen können und die anderen Tailwind oder alles selber schreiben. Das soll ja alles möglich sein. Deswegen ist es umso wichtiger, dass wir auf einer UI-Ebene oder UX-Ebene definieren, was uns denn eigentlich ausmacht. Was in unserer UX muss in all diesen verschiedenen UI-Fragmenten gleich sein? Und im Fall von Amazon ist es wirklich erstaunlich wenig. Wenn man in den Checkout reingeht, ist das Logo noch irgendwie gleich, aber der ganze Rest ist natürlich auch Absicht. Die wollen wahrscheinlich gar nicht, dass man, wenn man im Checkout ist, irgendwo draufklickt und den Kaufvorgang abbricht.

Anja Kammer: Ja.

Till Schulte-Coerne: Genau, aber das ist so ein ganz klassisches Beispiel dafür, dass da offensichtlich link-basiert integriert wird. Ich bin in einem anderen System, wahrscheinlich.

Tammo van Lessen: Ich finde wahrscheinlich.

Till Schulte-Coerne: Ich finde, das ist ein schönes Beispiel dafür, dass man irgendwie eine durchgängige UX auf der einen Ebene braucht, aber ich glaube, da geht’s vor allen Dingen um Corporate Identity.

Tammo van Lessen: Ja, aber nicht unbedingt auf diesen ganzen Komponenten- und Feature-Ebenen, weil du tatsächlich vielleicht ganz andere Anforderungen hast oder es auch einfach nicht so wichtig ist. Die Account-Settings-Seite, wo ich irgendwie die Sprache und meine E-Mail-Adresse ändern kann, da muss man vielleicht weniger Liebe reininvestieren. Wenn ich mich jetzt aber komplett darauf binde, dass alles aus einem Baukasten zusammengelötet und geleimt werden muss, dann –

Till Schulte-Coerne: Überall das gleiche Menü drüber – das ist ja eigentlich auch quasi visueller Lärm. Wenn man sich irgendwie vorstellt, dass man in dem Kundenportal rumklickt und jemandem ist furchtbar wichtig, dass überall die fünf Hauptversicherungsarten aufgeführt sind mit ihren 300 Untermenüpunkten, und ich bin aber gerade dabei, wie Tammo sagt, ein Passwort zu verändern, dann ist die Wahrscheinlichkeit, dass ich gerade beim Passwort-Ändern bin und hier jetzt abspringen möchte, um eine KFZ-Versicherung abzuschließen, ziemlich gering. Das heißt, eigentlich will ich ja auch, dass meine User sich auf das konzentrieren, was sie gerade machen, und dann will ich sie gar nicht mit irgendwelchem Zeug belästigen, was aus komplett anderen Systemen die ganze Zeit reinliegt.

Anja Kammer: Daran habe ich noch gar nicht gedacht.

Tammo van Lessen: Ich glaube, wir müssen ein bisschen die Kurve kriegen. Till, was machen wir denn, wenn wir nicht mit Links integrieren?

Till Schulte-Coerne: Das, was wir im Self-Contained-Systems-Kontext sehr häufig gemacht haben – obwohl Self-Contained-Systems damit eigentlich gar nichts zu tun hat, ich weiß auch gar nicht, warum das traditionell immer darauf hinauslief –, ist, dass wir transkludiert haben. Transklusion ist das dritte Pattern, das wir beschrieben haben, was meiner Meinung nach ein bisschen veraltet ist, was aber immer noch relativ viele machen. Das funktioniert so: Wenn ich mir überlege, dass ein Webbrowser, wenn ich den öffne, egal ob das jetzt eine Angular-App oder React-App oder serverseitig gerendertes HTML ist, was ich da anzeige, aus einem großen HTML-Baum, dem DOM, besteht – die Idee bei Transklusion ist, dass ich in diesem DOM bestimmte konzeptionelle Links habe. Die können irgendwelche Custom Elements sein oder Web Components, oder es kann irgendeine Konvention in meinem HTML sein, die ersetzt werden, und zwar durch den Rückgabewert, den ich bekomme, wenn ich diesen Link auflöse. Ich habe einen Link dort, der auf ein HTML-Fragment zeigt, und Transklusion bedeutet, dass irgendein Stück Infrastruktur den DOM, das HTML, durchläuft, diese Sockel-Links identifiziert, HTTP-GET-Requests gegen diese Link-Ziele macht und den Rückgabewert an die Stelle einpflanzt. Das kann man an verschiedenen Stellen machen, zum Beispiel klassisch irgendwo im Backend. Dafür gibt es dann Technologien im Backend, wie Edge Side Includes in Reverse Proxys – uraltes Zeug, gibt es schon seit Ewigkeiten –, oder Server Side Includes, kann jeder Nginx, jeder Apache schon seit Jahren. Die im Prinzip einfach nichts anderes machen, als dass der Webserver nach einem bestimmten String in dem Fall sogar sucht, der parst auch nicht den DOM, sondern der benutzt irgendeinen regulären Ausdruck, extrahiert die URI, macht einen HTTP-GET-Request darauf und packt den Rückgabewert an die Stelle. Das kann man aber auch ganz wunderbar im Frontend machen. Da kann man auch so eine Referenzkomponente, die ich immer ganz cool finde, verlinken: das H-Include. Das ist im Prinzip einfach eine Web Component, die kann ich in meine Webseite reinwerfen, und dann kann ich bestimmte Link-Komponenten in meinem HTML verwenden, egal ob ich das nun clientseitig generiere oder serverseitig generiere, und dann kann ich im Prinzip Teile davon austauschen. Also genau dasselbe, was ich auf dem Reverse Proxy mache: Link identifizieren, HTTP-GET-Request dagegen machen und den Link durch den Rückgabewert ersetzen. Das klingt irgendwie einfach, das ist auch technisch sehr einfach, das kann man wirklich mal so eben machen. Das hat aber unglaubliche Konsequenzen, weil das Problem einfach ist, dass ich HTML aus einer fremden Quelle in einen neuen Kontext reinwerfe. Und HTML kommt typischerweise nicht allein, sondern das hat ja auch Annahmen, die es typischerweise über die Umgebung macht, und das klassischste oder offensichtlichste ist wahrscheinlich CSS. Ich erwarte einfach, dass es irgendein CSS gibt, was dafür sorgt, dass das HTML-Schnipsel, was ich jetzt in irgendeinen Kontext reinwerfe, vernünftig gestylt wird, und das ist natürlich schon etwas relativ Kompliziertes. Ich habe tatsächlich mittlerweile auch so eine Komponente geschrieben – ich weiß nicht, ob wir die verlinken, müssen wir mal gucken, ist noch nicht so ganz produktionsreif –, wo die Idee eigentlich ist, dass man das kombiniert mit Shadow DOM. Also dass man im Prinzip Transklusion macht und den Teil, in dem man das reinwirft, wirklich komplett isoliert stylt. Ich weiß tatsächlich nicht, warum das so wenige Leute machen. Das liegt, wenn man clientseitige Transklusion macht, finde ich, ziemlich auf der Hand, dass man das in der Regel will. Aber ja, vielleicht ist das Thema auch einfach schon so durch, dass da auch keiner mehr Gehirnschmalz reinstecken möchte.

Anja Kammer: Ja, also erklären kann man es, aber die Leute verstehen es oftmals nicht, wie jetzt HTML-Schnipsel gemeinsam integriert werden. Normalerweise denkt man da eher so an einen JSON-Payload und dann wird das HTML neu gerendert, aber nein, das ist einfach schon gerendertes HTML, was damit kommt.

Till Schulte-Coerne: Genau. Das funktioniert auch gar nicht gut, wenn man HTML komplett clientseitig generiert. Wenn ich jetzt zum Beispiel auf so einer Mikroarchitekturebene einfach entschieden habe, unsere gesamte Firma benutzt ausschließlich Angular, um damit UIs zu bauen, dann ist Transklusion offensichtlich nicht das richtige Muster. Ich kann ganz wunderbar clientseitig in der Angular-App Sachen reintranskludieren, das kann man machen, habe ich, glaube ich, noch nie gesehen, aber das würde theoretisch gehen. Aber ich kann natürlich nicht mit einer Angular-App Dinge bereitstellen, die transkludiert werden, typischerweise, außer ich fange jetzt an, da irgendwie serverseitiges Pre-Rendering und so etwas aufzuziehen. Das will ich dann vielleicht auch nicht mehr. Obwohl Single-Server-Side-Rendering, ich würde es immer Edge Side Rendering nennen, ist ja heutzutage wieder cool, insofern vielleicht erlebt das demnächst auch sein Revival. Ganz ausschließen würde ich es nicht.

Anja Kammer: Das war jetzt das zweite Pattern, über das ihr geredet habt. Wenn man über Patterns oder Muster generell redet, stellt man sich doch immer die Frage: Welches Problem löst denn jetzt dieses Pattern? Also welches Problem löst jetzt Transklusion gegenüber anderen?

Till Schulte-Coerne: Transklusion ist sehr leichtgewichtig. Es ist relativ simpel, das in der reinen Integrationstechnik umzusetzen, und es ist unglaublich flexibel. Wenn wir jetzt mal diese ganzen Probleme, die ich schon genannt habe – Styling und so weiter – so ein bisschen ausklammern, dann kann man sich in so einer ganz klassisch serverseitig gerenderten Welt vielleicht vorstellen, dass das unglaublich mächtig sein kann. Wir kennen Online-Shops, da funktioniert der Online-Shop im Prinzip so, dass ich eine Suche habe, eine Vertikale, die die Suche implementiert. Und diese Suche – ich suche nach Toaster, keine Ahnung – die returniert dann nicht irgendwie eine Liste von Produkten, sondern die returniert im Prinzip ein HTML, in dem einfach nur mehrere Links drin sind. Für jeden Eintrag ist ein Link drin, und dieser Link wird dann durch Edge Side Includes zum Beispiel aufgelöst und führt einfach dazu, dass eine Suche einfach nur auf die Artikelkacheln aus einem anderen System referenziert, die dann eben dynamisch in diese Liste eingebaut werden. Und wenn sich das System für Artikelkacheln überlegt: „Hey, in meiner Artikelkachel, die in der Suche eingebunden wird, möchte ich jetzt den Preis nicht mehr rechts, sondern links anzeigen", dann ändern die das halt einfach. Also das ist etwas unglaublich Flexibles im Prinzip, was gerade, glaube ich, bei der Phase, bevor man live geht, unglaublich produktiv sein kann. Nachdem man live ist, tut es ein bisschen mehr weh, weil man dann aufpassen muss, wie man diese ganzen Laufzeitintegrationen noch unter Kontrolle behält, weil gerade Änderungen an den Seitenaspekten, also insbesondere an dem CSS oder auch am JavaScript, was sonst noch so drumherum ist, relativ schwer abzuschätzen sind, wenn überall irgendwelche Snippets reingeworfen werden, von denen man eigentlich gar nicht so genau weiß, was sie alles voraussetzen und was nicht. Deswegen ist das ein relativ schwieriges Thema, das sauber zu beantworten. Ich habe da auch vor Ewigkeiten, glaube ich, mal einen Blogpost drüber geschrieben, den können wir auch noch mal versuchen rauszukramen und verlinken. Aber im Prinzip ist das Thema, glaube ich, alleine durch den wahnsinnigen Hype von frontendseitigen Rendering-Techniken – die meisten Leute wollen heutzutage kein HTML mehr serverseitig machen, aus welchen Gründen auch immer – und das führt dann ganz häufig dazu, dass Transklusion von vorne herein raus ist. Dafür war das nie gedacht.

Anja Kammer: Mhm.

Till Schulte-Coerne: Aber damals war es ein relativ mächtiges Werkzeug und hat, wenn man wirklich gewusst hat, was man tut und die Probleme, die dieser Ansatz induziert, sauber adressiert hat, wirklich eine sehr mächtige Sache.

Tammo van Lessen: Ich weiß nicht, ob das deine Frage war. Im Grunde geht es ja ein bisschen von der – also auf der einen Dimension haben wir, glaube ich, die lose Kopplung und auf der anderen Seite vielleicht diese Nutzererfahrung oder so. Auf einen Hyperlink zu klicken und dann öffnet sich es in einem Tab ist halt was anderes, als die Daten werden direkt inline an der Stelle angezeigt, wo ich es haben will. Und da haben wir nämlich – ich glaube, das haben wir so in der Reihenfolge ein bisschen vertan – wenn wir von der losen Kopplung argumentieren, haben wir den iFrame eigentlich noch dazwischen. Das ist das Pattern, was noch dazwischen sitzt, was eben im Browser Isolationsmechanismen benutzt, um bestimmte Dinge an bestimmten Stellen anzeigen zu können, die aber dann ein bisschen schwieriger anzusteuern sind von außen.

Till Schulte-Coerne: Ja, genau. Es gab auch viele Leute, die irgendwie gesagt haben, Transklusion – das sind ja eigentlich abgemilderte iFrames oder so etwas. iFrames sind natürlich auch ein Muster, was es gibt, was wir auch beschrieben haben, was ich auch nach wie vor für super relevant halte, auch wenn es total unbeliebt ist. Aber iFrames sind halt tatsächlich das Muster: Was sind iFrames? iFrames sind im Prinzip einfach ein bestimmtes HTML-Element, das einfach einen komplett eigenen Browser-Kontext mit eigener JavaScript-Umgebung und allem eröffnet und im Prinzip einfach einen Bereich in einer Webseite für eine andere Seite reserviert. Ein Tab, ein Browser-Tab in einem Browser-Tab eigentlich. Und das ist natürlich unglaublich schwerfällig, das schleppt wirklich riesige Mengen an Browser-Kontexten mit sich. Man will ja auch nicht einen Browser aufhaben, in dem 200 Tabs auf sind. Das Problem dabei ist halt einfach, dass irgendwann die Maschine langsamer wird, weil so ein Browser-Tab einfach etwas Teures ist – viel, viel teurer ressourcenmäßig, als wenn man einfach ein paar HTML-Fragmente irgendwo reinwirft. Der Vorteil bei iFrames ist ganz klar der, dass iFrames wirklich eine Isolation sind. Also wenn ich Frontends habe und ich möchte Frontends integrieren von anderen Teams, denen ich nicht traue – zum Beispiel, dass sie sicheres JavaScript schreiben können, dass das JavaScript nicht irgendwelche Cross-Site-Scripting-Angriffe mit sich rumschleppt –, dann bleiben eigentlich neben Links eigentlich nur die iFrames über, wenn ich eben die Anforderung habe, dass ich Informationen von zwei oder mehr Systemen auf einer Seite anzeigen möchte. Deswegen haben wir das auch beschrieben, und ich finde es nach wie vor relevant. Das ist auch eigentlich das einzige Pattern, wo wir so ein bisschen die Brücke weggeschlagen haben auch vom Browser, weil das auch ein Pattern ist, was man in so hybriden Umgebungen häufig sieht. Also ich baue irgendwie eine Mobilanwendung und in dieser Mobilanwendung möchte ich einen UI-Teil von jemand anderem haben, der wirklich autonom ist – dann ist das eine Anforderung, die geht in der Mobilwelt typischerweise nicht so einfach. Wenn ich aber in der Mobilanwendung quasi einen kleinen Mini-Browser ohne Adresszeile einbinde und darin eine Seite öffne, dann kann ich im Prinzip Inhalte von anderen anzeigen, und die anderen können auch ihre Inhalte ändern, ohne dass die Anwendung neu durch den Freigabeprozess in irgendwelchen App Stores muss. Das ist aber im Prinzip konzeptionell exakt dasselbe wie ein iFrame in der Webseite, mit genau denselben Vor- und Nachteilen.

Anja Kammer: Okay. Damit haben wir drei Pattern besprochen. Was ist das nächste?

Till Schulte-Coerne: Vier, sogar. Zwei sind noch. Das sind im Prinzip die etwas moderneren Formen. Das erste von den beiden – da geht es sehr stark um das clientseitige Rendering, wie mache ich Frontend-Integration, wenn ich clientseitig wirklich rendern möchte. Und das erste Pattern dafür – es war verdammt schwer, einen Namen zu finden, ich bin auch immer noch nicht so ganz glücklich –, wir haben uns halt bei Self-Contained Systems so ein bisschen angelehnt und das Self-Contained Components genannt, weil die Idee bei diesem Pattern eigentlich ist, dass Teams im Prinzip Web Components bereitstellen. Was sind Web Components? Web Components ist so ein Sammelbegriff für zwei APIs, die der Browser bereitstellt. Das eine ist Custom Elements, das andere ist der Shadow DOM. Custom Elements bietet die Möglichkeit, dass ich JavaScript habe. Team A baut ein Stück JavaScript, was Team B einfach in seine Seite integriert, und dann kann Team B eine UI-Komponente von Team A an irgendeiner beliebigen Stelle ihrer UI instanziieren, indem sie einfach ein HTML-Element hinschreiben, was einen bestimmten Namen hat. Also zum Beispiel, wenn ich mir sowas vorstelle: Es gibt vielleicht eine, keine Ahnung, ich habe das Versicherungsportal geschrieben und jetzt möchte ich auf jeder Seite in diesem Versicherungsportal eine Chat-Funktionalität integrieren, sodass ich egal, wo ich gerade bin, immer mit dem Kundensupport chatten kann. Dann müsste ich einfach nur dafür sorgen, dass das Team, das für den Chat mit dem Kundenportal verantwortlich ist, ein JavaScript bereitstellt, das eine Komponente beinhaltet, ein Custom Element beschreibt, das im Prinzip diesen Chat implementiert. Also was zum Beispiel standardmäßig irgendwie unten rechts in der Seite so eine kleine Sprechblase anzeigt. Wenn ich drauf klicke, geht halt ein HTML-Element oben drüber auf, und da drin ist dann der Chat mit meinen Verläufen von den vorherigen Seiten und was weiß ich. So und das wäre jetzt etwas, was im Prinzip ein Custom Element einfach implementieren könnte. Das Problem, was ich dann aber habe, ist, dass wenn ich mir jetzt überlege, dass ich dieses Icon oder eben auch dieses Element, was oben drüber aufgeht, dann sind das ja auch einfach am Ende des Tages nur Elemente, die im DOM erscheinen. Und da kommt eben der Shadow DOM, den hatte ich schon mal erwähnt, dazu. Der ist im Prinzip einfach die Möglichkeit, dass man Bereiche des DOMs zurücksetzt, was das CSS-Styling anbelangt. Also dass ich eben einfach einen Teilbaum nehmen kann, zum Beispiel den Teilbaum, der mein Chat-Overlay ausmacht, und sagen kann: „Hey, alles, was außerhalb an CSS ist, soll hier drin jetzt bitte nicht gelten. Ich will wieder die Browser-Styles." Und insbesondere aber auch umgekehrt: Alles, was ich hier drin an CSS verwende, möchte ich nicht, dass es nach außen wirkt. Das sind also die beiden Hauptbestandteile von Web Components: einerseits die Möglichkeit, JavaScript zu definieren, das Komponenten beinhaltet, die ich in irgendeinem beliebigen Kontext verwenden kann, und auf der anderen Seite, dass ich Isolation von Styling habe, so dass ich diese ganzen Probleme, die wir eben bei Transklusion schon durchgekaut haben, nicht habe. Und das Pattern, um jetzt endlich mal einzukommen: Die Self-Contained Components haben im Prinzip einfach die Idee, ich habe eine Bibliothek von Komponenten, die von verschiedenen Teams bereitgestellt werden, die ich optimalerweise in Form eines JavaScripts zur Laufzeit lade. Ich sage also: Ich lade die Komponentenbibliothek meiner Kundenservice-Vertikale in meinem Kundenportal, und weil ich diese Kundenservice-Vertikale geladen habe, kann ich jetzt im Prinzip einfach diesen Chat verwenden in meiner Seite, egal was das für eine ist. Und das bedeutet halt, dass wenn jetzt diese Kundenservice-Vertikale diese Chat-Funktionalität verändern möchte – keine Ahnung, jetzt soll auch noch Spracherkennung da rein –, dann ändern die halt einfach ihre JavaScript-Komponente, und dann taucht halt überall, wo diese Chat-Komponente eingebunden ist, neuerdings der Videochat auf und nicht mehr das alte. Das ist im Prinzip wirklich sehr ähnlich zu Transklusion, in dem Sinne, dass das immer noch alles in einer Seite landet, das ist aber dadurch, dass ich heutzutage Dinge wie Isolation habe und auch clientseitiges Rendering berücksichtige, viel viel näher dran. Und das ist eben auch etwas, was heutzutage durch jedes Frontend-Framework im Prinzip unterstützt wird. Also wenn ich zum Beispiel Angular verwende, dann kann ich Angular-Komponenten einfach als Web Components exportieren. Die sind meistens nicht sehr leichtgewichtig, also da muss man ein bisschen vorsichtig damit sein, aber ich kann jede beliebige Angular-Komponente im Prinzip als Web Component exportieren, die in irgendeinen Kontext werfen, und dann läuft die da. Das ist auch alles wieder nicht so einfach natürlich, das hat alles wieder Konsequenzen, das ist alles sehr unangenehm, wenn es um Authentifizierung geht. Aber das ist auf jeden Fall etwas, was man in den Griff bekommen kann.

Anja Kammer: Mhm.

Tammo van Lessen: Entscheidend ist, glaube ich, schon noch mal zu sagen: Das ist auch hier so, dass diese Komponenten in der Hoheit eines anderen Teams liegen und auch von dort geladen werden. Also auch Bestandteil des Deployables sind und nicht zur Build-Zeit als NPM-Paket oder irgendwie so eingebunden werden.

Till Schulte-Coerne: Das ist die Idee.

Tammo van Lessen: Genau.

Till Schulte-Coerne: Und dann das letzte Pattern hatten wir in Anlehnung an die bestehenden Pattern-Sprachen Plugin-Module genannt. Das hieß früher anders, weil es im Prinzip für dieses Pattern eine Vorlage gibt, die man frontendseitig ganz häufig verwendet. Die Idee ist ganz einfach: Ich habe eine Single Page App, irgendeinem Framework nach Wahl, nehmen wir mal Angular gebaut. Dann wäre ja die Frage: Eine Angular-App besteht aus mehreren Modulen. Ich habe eine große App gebaut, die monolithisch mehr oder weniger mein gesamtes Kundenportal meiner Versicherung abbildet. Dann modularisiere ich ja diese Angular-App: Dann gibt es irgendeinen Teil, mit dem ich mein Profil pflegen kann, dann gibt es einen Teil, wo ich meine PKW-Versicherung anschauen kann, und dann gibt es vielleicht noch einen anderen Teil. Und die Idee, die im Prinzip hinter diesen Plugin-Modulen steckt, ist, dass diese Module natürlich auch zur Laufzeit von verschiedenen Quellen geladen werden können. Also dass ich halt im Prinzip einfach sagen kann: Ich habe fünf Teams, die sind alle für dieses Kundenportal verantwortlich. Jedes Team stellt im Prinzip ein oder mehrere Angular-Module bereit, die ich einfach zur Laufzeit da reinlade. Dafür gibt es halt schon technische Implementierungen – wir haben es am Anfang Module Federation genannt, weil das etwas ist, was Webpack mit der Module Federation zum Beispiel versucht zu unterstützen. Aber das hat im Prinzip nichts mit Webpack zu tun, das kann man auch ohne Webpack machen. Wir haben versucht, einen neutraleren Namen zu finden, deswegen heißt das Plugin-Modul. Kann man sich ja vorstellen: Die Idee, die wahrscheinlich mal irgendwann hinter Eclipse RCP stand mit deren Plugins, waren im Prinzip die gleichen. Ich committe mich halt auf eine Technologie, nennen wir sie Angular, nennen wir sie React, egal. Und die Idee ist halt einfach, ich lade unterschiedliche Elemente dieser UI, die verschiedene definierte Schnittstellen dann im Optimalfall implementieren. Ich lade diese Komponenten oder Module und instanziiere sie in meine Anwendung, und was genau innerhalb so eines Moduls passiert, das entscheiden die Teams, die dieses Modul bereitstellen. Und wenn ein Team, das das Modul für das Profil bereitstellt, sich entscheidet: „Hey, wir wollen jetzt hier auch noch irgendwie ein Captcha einbauen, wenn du dein Passwort ändern willst, oder wir wollen jetzt Passkeys unterstützen", dann machen die das halt in ihrem Modul. Und alle anderen betrifft das eigentlich gar nicht. Das ist die Idee bei diesen Plugin-Modulen.

Anja Kammer: Mhm.

Till Schulte-Coerne: Genau. Also: Hyperlinks, Return-URIs, Transklusion, Isolated Frames, Self-Contained Components und Plugin-Module.

Anja Kammer: Ihr hattet ja schon gesagt, sowas wie Transklusion seht ihr in der freien Wildbahn eher weniger jetzt, das ist eher so ein Damals-Ding gewesen. Welche Muster sieht man denn heutzutage implementiert, oder auch welche Kombinationen von Mustern?

Tammo van Lessen: Naja, also das widerspricht dem jetzt, aber Transklusion mit Server Side Includes benutzen schon einige unserer Kunden. Ich glaube, die clientseitige Transklusion ist sagen wir ein bisschen Respekt einflößender.

Anja Kammer: Mhm.

Tammo van Lessen: Aber das genau setzen schon Kunden von uns durchaus auch sehr produktiv ein, und auch so, dass es einfach keine Beschwerden macht.

Till Schulte-Coerne: Genau, wenn man es adressiert hat, funktioniert es. Hat halt die Restriktion, serverseitig zu sein. Was ich schon viel gehört habe, dass es auch total toll sein soll, was ich aber selber leider noch nie gesehen habe, sind wirklich diese Plugin-Module.

Anja Kammer: Mhm.

Till Schulte-Coerne: Ich habe viel darüber gelesen. Einige unserer Kolleginnen und Kollegen haben damit auch Sachen gemacht, auch teilweise zu Zeiten, wo das noch relativ unklar oder unstandardisiert war. Ich finde es persönlich ziemlich schwierig, weil ich eigentlich keine Lust hätte, mich auf ein Framework festzulegen. Ich verstehe das immer nicht, warum Leute Integrationsmechanismen auswählen, die im Prinzip proprietäre, festgelegte Bausteine haben. Das spricht aus meiner Sicht sehr dagegen. Aber wenn einem das egal ist, dann passt es. Was ich häufiger schon gesehen habe, was ich auch selber ziemlich oft mache: Ich mache auch immer noch in einigen Projekten Transklusion, aber ich mache relativ viel dieses Self-Contained-Components-Zeug. Also Web Components bauen, die man dann in andere Kontexte reinwirft – das ist etwas relativ Einfaches. Das kann man ganz gut machen, und meiner Meinung nach ist es das, was man typischerweise heutzutage macht. iFrames – klar, ganz viele proprietäre Systeme: Wenn ich irgendein ERP-System nehme und ich möchte in dieses ERP-System irgendeine Ansicht rein integrieren aus einem internen System, passiert es typischerweise nach wie vor über iFrames. iFrames ist einfach eine Technologie, die man sehr häufig sieht. Hyperlinks – ja, sowieso. Also im Prinzip kann man sich orientieren. Man kann aus diesen verschiedenen Aspekten auswählen, dafür haben wir ja genau das Paper geschrieben, und im Prinzip sind sehr viele Kombinationen denkbar. Das, was mir, glaube ich, wichtig wäre, ist, dass man sich darauf festlegt. Also: Wenn ich mich vor drei Wochen auf Transklusion festgelegt habe und damit umgehen kann, dann ist das sicher ein Muster, was auch noch die nächsten 10 Jahre vernünftig trägt. Da spricht überhaupt nichts dagegen.

Tammo van Lessen: Was dann ein spannender Perspektivwechsel ist: Wenn ich ein System oder ein System of Systems baue, dann habe ich ja eine gewisse Entscheidungsfreiheit oder kenne sozusagen die beteiligten Protagonisten. Wenn das aber über solche Grenzen hinausgeht, finde ich, wird es noch mal spannend, weil irgendeine Single Page App, die nicht darauf geachtet hat, dass Deeplinks funktionieren, lässt sich halt noch nicht mal über Links irgendwie integrieren in deine Anwendung. Und Till hatte mir das halt damals erzählt – ich glaube, Microsoft war das, und Dynamics-Komponenten man ziemlich gut transkludieren kann oder über iFrames einbinden kann, weil diese URL-Absprünge gut funktionieren. Das ist ja auch eine bewusste Design-Entscheidung, die irgendjemand mal getroffen haben muss. Also würde ich schon auch sagen: Wenn ich Systeme designe, je nach Domäne, in der ich das baue, sollte man schon vielleicht auch daran denken, wie andere das möglichst lose gekoppelt integrieren und einbinden können. Frontend-Integration – ich habe das Gefühl, das ist immer noch so ein Nischending. Wenn jemand über Integration redet, wird sofort über APIs oder irgendwelchen Datenzugriff geredet, aber man braucht in vielen Fällen halt einfach nicht, sondern eigentlich nur eine URL. Und das wäre so meine Botschaft: dass man irgendwie auch von beiden Seiten daran denkt, auch das, was man selber bereitstellt – wie kann das eigentlich integriert werden?

Anja Kammer: Ihr hattet ja gerade auch schon gesagt, wenn ich mich einmal für ein Pattern entscheide, dann sollte das halt auch langfristig haltbar sein. Aber ist es denn in der heutigen agilen Softwareentwicklung eigentlich noch nötig, mich für eine bestimmte Architektur zu entscheiden? Brauche ich überhaupt wirklich Architekturentscheidungen? Sind die so bindend, wenn ich doch jederzeit meine Applikation einfach neu schreiben lassen kann?

Till Schulte-Coerne: Solange wir über wirkliche Integration reden, musst du halt nicht eine Applikation neu schreiben, sondern mehrere. Also wenn du jetzt deinen Online-Shop gebaut hast und der basiert auf Transklusion, den eben mal so in irgendein anderes Muster zu überführen, das wird wahrscheinlich ziemlich wehtun und man würde davon abraten. Das ist ja eben genau auch der Grund, warum wir schon wirklich fest der Meinung sind: Das ist eine Liste von Ansätzen, die alle ihre Vor- und Nachteile haben, und man sich eben bewusst dafür entscheiden sollte – und zwar nicht für einen, sondern für zwei, drei vielleicht –, aber vielleicht auch explizit gegen einen Ansatz entscheiden sollte. Das, was, glaube ich, das Agile heutzutage so ein bisschen kippt, deswegen ich mir vorstellen kann, dass Frontend-Integration tatsächlich so ein bisschen aus der Mode kommen könnte, ist, dass das Agile natürlich erlaubt, dass man einfach monolithische UIs baut. Es gibt tatsächlich ein Pattern, das hat eine andere Gruppe geschrieben, das haben sie Frontend-Integration genannt, und das entspricht aber nicht unserer Definition von Frontend-Integration. Und das ist das Pattern: Ich baue eine monolithische Single Page App und integriere einfach Backend-APIs von verschiedenen Teams. Jedes Team stellt irgendeine API bereit, und dann gibt es die magische Super Single Page App, die oben drüber liegt. Und darunter gibt es halt die APIs. Und das ist etwas, das ist, glaube ich, in der klassischen Welt sehr häufig gemacht worden. Man hat aber sehr stark gesehen, dass dieses Ding am Ende die gesamte Logik beinhaltet. Die gesamte Komplexität steckt einfach nur noch in diesem Monster drin, und meine Backend-APIs tun eigentlich gar nichts mehr. Die nehmen irgendwie JSON entgegen und serialisieren das, damit das in die Datenbank geschrieben wird. Hoffentlich machen sie ganz viel Security noch und Sicherheitsprüfung. Aber wenn das so ist, dann ist halt die gesamte Logik, der gesamte Workflow – wie genau erfasse ich meine Kunden- und Vertragsdaten –, ist alles vorne in der UI drin. Und wie gesagt, ich glaube, das war schwer zu handhaben. Man könnte darüber spekulieren, ob so eine UI, so eine monolithische Single Page App jetzt in Zukunft nicht wieder dadurch attraktiver wird, dass man das Ding einfach generieren kann. Gerade wenn die Backends nämlich in der Tat Security machen – was ich ehrlich gesagt nicht glaube, dass das wirklich oft so ist, weil es gibt nie jemand zu, wenn man darüber redet. Aber die Backends, die wir so in der Praxis sehen, sind teilweise wirklich extrem anämisch, hat Stefan, glaube ich, immer gesagt. Die tun wirklich gar nichts. Die machen halt irgendwie Sicherheitsprüfung auf der Ebene: Sind die Pflichtfelder ausgefüllt? Aber wir haben ja auch fachlich übergreifende Sicherheitsanforderungen. Ein Kontobetrag darf nur erhöht werden, wenn der Kunde dies und jenes hat. Und so etwas muss natürlich auch in den Backends drin sein. Also komplexere fachliche Validierungen, die überhaupt die gesamte Berechnung – die muss ja in den APIs sein, damit man überhaupt sichere Frontend-Anwendungen bauen kann, egal ob es jetzt monolithisch oder modular sind. Aber wenn ich jetzt im Prinzip wirklich sichere Backend-APIs habe, dann kann ich das Frontend ja einfach wegwerfend generieren. Dann juckt ja keinen mehr. Dann generiert halt irgendwie Claude Code irgendwelche Unsinnigkeiten in die UI – wurscht, dann ist das ja nicht sicherheitsrelevant. Das Backend überprüft es ja eh. Das heißt, so die Art und Weise, wie KI im Prinzip in die Entwicklung einschlägt, stellt sich für mich so ein bisschen so raus, dass die Backendler relativ konservativ – und dafür immer zu Unrecht belächelt, meiner Meinung nach – mit diesen KI-Tools vorgehen, weil da zählt es halt so ein bisschen, und Frontendler immer sehr schnell dabei sind und sagen: „Ja, komm hier, generieren wir mal den Code, gucken wir uns nicht an und hauen den raus." Und das kann ich halt nur dann mir leisten, wenn ich halt einfach sage: Es ist auch wurscht, was diese Anwendung baut. Ob das wirklich so egal ist – ich kaufe das gerade selbst nicht, was ich sage, glaube ich. Ich habe einfach so zutiefst die Befürchtung, dass das genau das ist, wohin unsere Branche gerade hinsteuert, dass wir im Prinzip Wegwerf-Clients bauen, die dann eben beliebig groß sein können. Und dann trifft genau das alles, was du gerade gesagt hast, Anja, zu: Dann macht doch schmeiß rein, wir brauchen schon Frontend-Integration.

Anja Kammer: Mhm.

Till Schulte-Coerne: Aber für mich ist es eine absolut unentschiedene Frage, und ich glaube auch irgendwie, man sollte, wenn man diesen Weg geht, den auch wirklich sehr bewusst gehen und dann auch wirklich sicherstellen, dass die Backends wirklich auch sicher sind.

Tammo van Lessen: Die Frage ist ja: für was und für wen, welche Anwendung ich baue. Ich glaube, dass es ja schon diesen Trend der Citizen Developers gibt, die Low-Code, die gar nicht so gut programmieren können, die sich dann aber auf Backend-Services wie Supabase oder so etwas stützen, was einem all das schon mal bringt zumindest. Also die ganzen Fußangeln, in die man sonst tappen kann, die versuchen die mit Row Level Security oder so etwas schon irgendwie zu lösen, und dann kannst du da drauf deine Wegwerf-Frontends irgendwie relativ gefahrlos drauf bauen. Ich glaube, ist aber nicht unbedingt unser typischer Anwendungsfall in den Sphären, in denen wir uns bewegen.

Anja Kammer: Ja, wunderbar. Schön, dass ich mit euch sprechen konnte. Es war wirklich sehr spannend, ich habe einiges gelernt. Ja, bis zum nächsten Mal. Ciao.

Tammo van Lessen: Die Frage erstmal, Anja, ist ja noch, ob du auch auf der EuroPLoP Patterns präsentieren willst.

Anja Kammer: Ich überlege es mir, es hört sich auf jeden Fall methodisch interessant an.

Tammo van Lessen: Ja.

Till Schulte-Coerne: Kann ich nur empfehlen. Ja, vielen Dank, Anja.

Tammo van Lessen: Vielen Dank, Anja.

Anja Kammer: Ciao.

This summary was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

Von der Praxis zum Pattern: Warum eine Taxonomie fehlte

Tammo van Lessen, Principal Consultant bei INNOQ, und Till Schulte-Coerne, Senior Consultant bei INNOQ, erläutern gegenüber Host Anja Kammer, was zur Entstehung des Papers geführt hat: In ihren Projekten ist Frontend-Integration ein wiederkehrendes Thema – doch bisher fehlte eine belastbare Quelle, auf die man verweisen konnte. Das Paper entstand im Rahmen der EuroPLoP, einer Pattern-Konferenz im Kloster Irsee, die auf einem intensiven Shepherd-Prozess und einem Workshop-Format basiert, bei dem Autorinnen und Autoren als „Fliege an der Wand" Feedback empfangen. Till betont, dass bereits der Prozess selbst – die gemeinsame Auseinandersetzung mit dem Stoff – zu Klarheit geführt hat, die vorher nicht da war.

„Ein Pattern heißt ja eigentlich, dass man etwas beobachtet hat, was wiederkehrt, und nicht, dass man etwas Neues vorschlägt. Wir haben uns da nichts aus den Fingern gesogen."

Frontend-Integration: Eine API für die UI

Till Schulte-Coerne erklärt, was Frontend-Integration bedeutet: Ein Provider stellt einen Teil einer UI bereit, den ein anderes System zur Laufzeit integriert. Das entspricht konzeptuell einer Backend-API – nur dass statt eines HTTP-Requests ein UI-Fragment eingebunden wird. Entscheidend ist, dass die Integration zur Laufzeit stattfindet: Ändert der Provider sein UI-Fragment, müssen die einbettenden Systeme nicht notifiziert werden. Tammo van Lessen ergänzt, dass dieses Verständnis vieles aus dem SCS-Kontext (Self-Contained Systems) klarer gemacht hat: Alle Integrationsebenen – Datenbank, Business-Logik, UI – lassen sich als Schnittstellen begreifen, die unterschiedlich starke Kopplung erzeugen.

„UI-Integration, die Muster, über die wir gleich reden, sind einfach eine bestimmte Spielart einer API."

Die sechs Muster: Von Hyperlink bis Plugin-Modul

Till Schulte-Coerne und Tammo van Lessen stellen die sechs dokumentierten Integrationsmuster vor. Den Ausgangspunkt bildet der Hyperlink – für Till das „magische Integrationskonzept des Webs", das immer funktionieren sollte. Ein Sub-Pattern dazu sind Return-URIs: Beim Absprung in ein anderes System gibt man eine URI mit, die nach Prozessabschluss wieder zurückführt. Transklusion bezeichnet das Einpflanzen von HTML-Fragmenten über HTTP-Requests – klassisch per Edge Side Includes im Reverse Proxy oder clientseitig über Komponenten wie H-Include. Isolated Frames (iFrames) öffnen einen vollständig eigenen Browser-Kontext mit echter Isolation, sind aber ressourcenintensiv. Self-Contained Components nutzen Web Components (Custom Elements und Shadow DOM), um UI-Komponenten verschiedener Teams zur Laufzeit einzubinden. Plugin-Module schließlich – früher auch als Module Federation bekannt – laden ganze Framework-Module zur Laufzeit in eine Single Page Application.

„Das gesamte Web ist eigentlich ein gigantisches Frontend-Integrationsexperiment."

Forces: Autonomie, UX und Authentifizierung

Till Schulte-Coerne erläutert, dass die Musterwahl von verschiedenen Kräften (Forces) abhängt, die im jeweiligen Kontext unterschiedlich gewichtet sind. Team-Autonomie ist immer gewünscht, aber das Ausmaß variiert: Kann ein Team beliebiges CSS einsetzen, oder müssen alle eine gemeinsame Komponentenbibliothek verwenden? UX-Konsistenz ist ein weiterer Faktor – am Beispiel Amazon zeigen Till und Anja Kammer, dass auch ein minimaler gemeinsamer Nenner ausreichen kann. Als schwierigsten Aspekt benennt Till die Authentifizierung: Je höher die angestrebte Autonomie, desto aufwendiger wird Single Sign-On über Systemgrenzen hinweg. Tammo ergänzt, dass auch der einfache Hyperlink für Authentifizierungsszenarien eine valide Lösung sein kann – wenn man bereit ist, UX-Kompromisse einzugehen.

„Da ist keine Silver Bullet dabei. Es gibt ein Pattern, was ich auswählen kann, und dieses Pattern hat Konsequenzen."

Praxis und Ausblick: Welche Muster man heute wirklich sieht

Tammo van Lessen und Till Schulte-Coerne berichten, welche Muster sie im Projektalltag antreffen. Server-seitige Transklusion via Server Side Includes setzen einige ihrer Kunden produktiv ein. iFrames sind nach wie vor verbreitet, vor allem bei der Integration proprietärer ERP-Systeme. Self-Contained Components sind für Till der heutige Standard. Plugin-Module gelten als vielversprechend, sind aber durch die Bindung an ein Framework für ihn wenig attraktiv. Abschließend diskutieren die drei, welche Auswirkungen KI-gestützte Code-Generierung auf Frontend-Architekturen haben könnte: Till skizziert ein Szenario, in dem Frontends zunehmend wegwerfbar werden – was die Anforderungen an sichere Backend-APIs erhöht, aber Frontend-Integration perspektivisch aus dem Fokus drängen könnte.

„Wenn die Backends wirklich sicher sind, kann ich das Frontend einfach wegwerfend generieren. Dann ist es nicht mehr sicherheitsrelevant."