# Six Patterns for Web Frontend Integration

**Podcast:** INNOQ Podcast
**Published:** 2026-10-26

## Transcript

Hallo und herzlich willkommen zum InnoQ Podcast.
Heute sprechen Tammo van Lessen und Till Schulte-Körne über Integrationsmuster für Webfrontends.
Hallo.
Hallo Anja.
Hallo Anja.
Stellt euch doch bitte einmal kurz vor.
Ja, ich bin Tammo.
Ich bin Principal Consultant bei der InnoQ.
Bin, glaube ich, schon seit zwölf Jahren dabei und mache hauptsächlich Architektur-Dinge, die mich interessieren, ab verschiedene Stationen durchlaufen, solche Dinge.
Schon ewig bei der NOQ, länger als Tammo und beschäftige mich relativ viel mit Web-Themen, Web-Architektur, Web-Software-Entwicklung.
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?
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 irgendwo.
Also wir hatten immer das Problem, dass wir was zitieren können wollten, dass man eben einfach mal Leuten sagen kann, wenn du wissen willst, wie man Frontends integriert, welche Optionen du dafür hast, dann schau doch einfach mal da.
Und ja, da hat Tamo...
Die Europlop vorgeschlagen.
Kannst du ja vielleicht mal ein paar Töne dazu sagen, Tavo?
Ja klar.
Ich wurde nämlich auch immer darauf angesprochen.
Ich hatte auch so einen akademischen Hintergrund und meine Bekanntschaften von damals haben immer gesagt, man muss unbedingt mal zu Europlop.
Und tatsächlich das Thema Patterns war mir schon immer sehr wichtig.
Ich hatte damals so ein Aha-Erlebnis, als ich glaube ich das erste Mal dieses Buch von Hope gelesen hatte.
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.
Und man passt ganz gut zu diesen ganzen AI-Diskussionen im Übrigen, weil da ist es genauso, wenn der Kontext allen klar ist.
Aber genau, ich will nicht zu weit da abschweifen.
Genau, und wie kommen also 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 einem Architekten, von Christopher Alexander, der damals irgendwie gesagt hat, wir können doch Architektur nicht immer dem Zufall überlassen, sondern brauchen wiederkehrende Muster.
Also wir haben wiederkehrende Probleme und dafür brauchen wir wiederkehrende.
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 sowas gemacht haben.
Und daraus sind eben diese Konferenzen entstanden, die halt lustigerweise gar nicht so Konferenzen sind, wie man sie sonst in Akademia kennt, sondern einen sehr interaktiven Teil haben.
Also im Grunde läuft es so, dass man erstmal, wenn man da was einreicht, man mit einem Abstract, da 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 Sheffert 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 einer diesen Anforderungen an Patterns, da kommen wir vielleicht gleich nochmal 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 also tatsächlich ganz cool, das ist bei der Europlop im Kloster Irsee, das ist wirklich eine traumhafte Kulisse, so ein Kloster mit angebundener Brauerei.
Man hat also keinen Grund, das Gelände jemals zu verlassen eigentlich über den Zeitraum.
Es gibt aber auch einen schönen See, wenn man zehn Minuten geht.
Da waren wir ja auch.
Richtig.
Nicht nur eine Brauerei.
Genau.
Es gibt sehr viele Möglichkeiten, sich da sozusagen auszutauschen und zu inspirieren.
Und dann gibt es neben aller möglichen Kennenlernrituale erstmal dann 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.
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.
Die Fliege an der Wand, man darf nichts mehr sagen, sich nur noch Notizen machen, dreht sich auch so mit dem Rücken da zu den anderen und muss dann sozusagen das Feedback über sich ergehen lassen.
Das ist meistens sozusagen dann erstmal über, jetzt glaube ich, über die positiven Dinge und den Stil und dann über die inhaltlichen Dinge.
Und das Auditorium da 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.
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 Frontendikation 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, Till, das ist doch eine gute Idee, da mal gemeinsam uns auf diese Reise dazu begeben und das zu machen.
Und oder Till, das 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 nochmal irgendwie gemerkt.
Vorher eigentlich, ne?
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, würde ich jetzt mal behaupten, das war irgendwie nichts Neues.
Das ist ja auch eigentlich der Sinn von einem Pattern.
Also 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 ja 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 sowas 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 halt auch nochmal mit unserem Shepard.
Also wir hatten wirklich einen ganz hervorragenden Shepard, den Césare.
Ich hoffe, ich spreche den Nachnamen richtig aus.
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 Flieger 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.
Muss man sich vorstellen, da laufen nur gestandene Professoren rum und teilweise deren eigenen Studenten 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 halt 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, ich wollte eigentlich über das reden, was uns dabei klar geworden ist.
Und wenn ich mich zum Beispiel noch erinnern kann, was in so einer Diskussion mit Tambo in irgendeinem Hotelkonferenzraum mal so klar wurde, ist zum Beispiel, was ist eigentlich Frontend-Integration?
Also wir haben im Frühjahr immer über Frontend-Integration geredet.
Wir haben irgendwie immer...
gesagt, ja, hier, es gibt irgendwie Transfusion und keine Ahnung, irgendwelche Komponenten, Web-Components oder Single-Page-Anwendungen monolithisch.
Aber wir haben uns nie darüber Gedanken gemacht, wieso wir denn das eine dafür halten, dass es Frontend-Integration ist und das andere irgendwie nicht.
Und Tom und ich haben dann eigentlich irgendwann mal eine für mich ganz gute, also für mich kam es gut, Definition davon gemacht, was wir eigentlich unter Frontend-Integration verstehen.
Und das ist halt im Prinzip, dass man sagt, ein Provider stellt einen Teil einer UI bereit, die 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 die 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, was ich halt, ohne wirklich viel zu wissen darüber, wie genau das, was das genau für Funktionalitäten abbildet, wie genau da der Clickflow in diesem Teil dieser UI ist, ich kann es einfach integrieren.
Und das ist etwas gewesen, was mir eigentlich eine sehr große Klarheit gebracht hat, weil das im Prinzip Eben 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 eben das bereitstellende System, das Team, was für das bereitstellende UI-Fragment oder was auch immer das dann ist, einfach eine unglaublich hohe Autonomie hat.
Ich kann einfach entscheiden, ich möchte dort neue Funktionalitäten, neue Buttons, keine Ahnung, neue UI-Teile einbauen und muss die Leute, die mein UI benutzen, im Prinzip gar nicht großartig darü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 ersten Paper oder 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, der Provider, wie auch immer man das nennen will, 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.
Ja, das Coole war ja auch, fand ich, dass, also ganz viele Sachen haben wir in den SCS schon beschrieben, dass wir, da reden wir auch über Frontend-Integration, dass wir.
Magst du nochmal kurz erzählen, was SCS sind?
Entschuldigung, Safe Content Systems, das ist ja im Grunde einer unserer Go-To-Architektur-Ansätze sozusagen, bei denen wir das Gefühl haben, die funktionieren in vielen Fällen sehr gut.
Man kann sie vielleicht auch als grob granulare Microservices beschreiben.
Aber wir haben ganz oft Diskussionen darüber, ist das jetzt ein reiner SCS oder nicht?
Wir achten da sehr darauf, dass die Definition von SCS, so wie wir sie auf der Webseite beschreiben, möglichst rein ist.
In der Praxis machen wir, 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.
Es gibt auch API-Zugriffe, wir wollen aber viel Frontend-Integration machen.
Die Dinger sind autonom.
Aber ganz viel 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.
Es ist einfach alles 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, lose Kopplungen, starke, lose, enge Kopplungen bereitstellt, dann hat man halt plötzlich einen 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.
Dann sind wir schon bei einem sehr wichtigen Punkt.
Also anhand welcher Aspekte unterscheide ich dann, wann welches Muster am besten geeignet ist?
Also es hat bestimmt auch was damit zu tun, was ich damit erreichen will.
Teamautonomie, Performance, Konsistenz, der User Experience und so weiter.
Habt ihr euch da bestimmt Gedanken gemacht, aber erzählt mal.
Genau, wir mussten uns dazu Gedanken machen.
Also wenn man ein Pattern dokumentiert, dann funktioniert das ja typischerweise so, dass man sich an immer die gleiche Struktur...
Und das, 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 eigentlich einwirken.
Und im Fall von der Frontend-Integration gibt es halt eine gewisse Menge von...
Von Einwirkungskräften, von Rahmenbedingungen, die im unterschiedlichen Fall oder im konkreten Fall unterschiedlich sein können natürlich jedes Mal.
Baue ich einen Online-Shop, ist was komplett anderes, als wenn ich ein Kundenportal für eine Versicherung baue zum Beispiel.
Das ist einfach nicht das Gleiche.
Und gewisse Forces kehren halt wieder.
Also gewisse Dinge sind einfach immer die gleichen bei all diesen Frontend-Integrationsmustern.
Ja, 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, keine Ahnung, 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 sowas oder müssen alle dieselbe Bootstrap-Version verwenden.
Also die Unabhängigkeit ist kein Ja-Nein, wie immer, sondern das ist halt ein Spektrum, in dem man sich aufhalten muss.
Dasselbe gilt halt 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 destabilisiert.
Da gibt es natürlich auch sehr unterschiedliche Ansätze.
Die Art der Auswirkungen einer Architekturentscheidung in dem Frontend-Integrations-Thema hat halt sehr stark eine Auswirkung darauf, wie sehr ich mich festlegen muss bei bestimmten Dingen, die meine Funktionalität abbilden.
UX ist ein sehr wichtiger Punkt, meiner Meinung nach, oder natürlich ein sehr wichtiger Punkt.
Wie stark ist mein UI dann, was ja am Ende im Optimalfall aus verschiedenen Elementen verschiedener Begründung, autonomer bereitstellender Systeme gekapselt ist, wie eng ist mein UI dann am Ende des Tages doch wieder gekoppelt.
Also 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 so Aspekte gibt, die dieses Dashboard doch dann sehr stark wieder koppeln.
Zum Beispiel könnte ich ja dann einen globalen Filter für einen Zeitraum haben, den ich in diesem Dashboard anzeigen möchte.
Ich möchte irgendwo einen Filter haben oder eine Eingabemöglichkeit haben, um eine Zeitspanne einzugeben.
Und dann sollen sich in all diesen Kacheln, all diesen fünf Kacheln von den fünf verschiedenen Systemen sofort optimalerweise irgendwie alles ändern.
Da gibt es natürlich Frontend-Integrationsmuster, mit denen man sowas sehr leicht erreichen kann.
Aber das geht nicht mit jedem Frontend-Integrationsmuster.
Und ein ganz wichtiger Aspekt, der auch wirklich leider keine wirklich zufriedenstellende Antwort hat, das kann man ja hier schon mal teasern, ist das Thema Authentisierung.
Also wenn ich in einem Browser, wir reden ja über Web-Integrationsmuster typischerweise, wenn ich in einem Web-Browser 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.
Ich stimme dir da ja zu, aber das ist an anderen Stellen halt auch ein Problem.
Also ich würde nicht unbedingt sagen, dass das jetzt was ist, was dagegen spricht.
Wenn wir jetzt mal, ich weiß nicht, ob ich das jetzt darf, nehmen wir mal das allereinfachste Pattern einmal kurz raus, den Link.
Wenn ich auf eine andere Seite springe, dann muss ich mich halt zur Not neu authentisieren.
Aber dann ist es halt auch einfach erledigt und ich muss nicht hintenrum irgendwelche Verrenkungen machen, dass das irgendwie funktioniert.
Also ich finde, auch das gehört auf das Spektrum dazu, dass manche Dinge damit auch sehr viel einfacher sind, wenn man an der UX...
vielleicht an ein paar Stellen auch bereit ist, Kompromisse einzugehen.
Und das erlebe ich halt in der Praxis oft, dass diese Kompromisse oft nicht mitgedacht werden.
Und deswegen, finde ich, helfen diese Patterns aber auch, weil sie diese, wie nennt man denn das, 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.
Genau, das kann man, glaube ich, auch jetzt einfach vorwegnehmen.
Also selbst wenn man sich dieses Paper irgendwie besorgt und sich das durchliest, da ist keine Silver Bullet dabei.
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.
Authentisierung wird zum Beispiel schwierig.
Authentisierung 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.
Aber umgekehrt ist eben genau das Ziel von dem Paper auch gewesen, das in irgendeiner Form klar zu machen.
Also wenn ich das mache, welche Konsequenzen hat diese Entscheidung dann?
Und wenn die Konsequenz nicht zu meinen Anforderungen passt, dann sollte ich es tunlichst sein lassen.
Dann stell doch mal die sechs Pattern vor.
Also eins haben wir ja schon, also den Link, den Hyperlink.
Wollt ihr dazu noch etwas sagen?
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.
Und das ist tatsächlich etwas, wo ich sagen würde, ich würde...
in jeder Frontend-Architektur erwarten, dass das funktioniert.
Also wenn ich eine, Entschuldigung, ich muss mich präzisieren, in jeder Frontend-Integration im Web würde ich erwarten, dass das funktioniert.
Also 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 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.
Also ein Link bringt Dinge in der zeitlichen Ebene hintereinander.
Ich bin erst auf Seite 1, danach auf Seite 2, danach auf Seite 3.
Da gibt es aber einen sehr interessanten Sonderfall.
Das ist so ein Sub-Pattern.
Das ist quasi unser zweites Pattern, was wir beschrieben haben.
Das ist die Frage, Ich bin erst auf Seite 1, dann bin ich auf Seite 2.
Jetzt bin ich auf Seite 2 fertig.
Ja, was mache ich denn dann?
Wie komme ich wieder zurück auf Seite 1?
Das ist etwas, das haben wir auch kurz erwähnt, weil das eigentlich ein totaler, ich behaupte mal, No-Brainer ist, sowas zu machen.
Dass man sich eben die Gedanken darüber gibt, wie ein System was abspringt, also wo ich einem Link in ein anderes System folge, dem anderen System mitgibt, wie ich wieder zurückkommen kann.
wenn das andere System fertig ist.
Also stellen wir uns vor, wir erfassen gerade einen neuen Vertrag, irgendein Verkaufsdokument in irgendeinem System.
Und jetzt haben wir die ganzen Artikel hinzugeklickt und jetzt fehlt der Kunde aber.
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, was für die Kundenverwaltung verantwortlich ist und danach wieder in die Vertragsverwaltung zu dem neuen Vertrag zurückspringen.
Und das ist natürlich eigentlich relativ simpel.
Man gibt einfach beim Absprung in das andere System eine URI mit, die das Kundensystem jetzt in meinem Beispiel aufrufen kann oder wo es hin 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 versorgen muss, dass die Systeme untereinander dieselben Konventionen haben, wie man mit diesen Return-Uris umgeht.
Das kennen wir zum Beispiel, so das bekannteste Beispiel für Return-Uris kommt im Prinzip aus den Single Sign-On-Protokollen, die es so gibt.
Also 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.
Und auch sowas, passiert typischerweise über Return-URIs.
Das ist so ein sehr simpler Sonderfall.
Die Kunst bei diesen URIs ist, dass man sie halt nicht vergisst.
Also 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 eigentlich haben muss, damit das relativ einfach funktioniert.
Das ist aber ein extrem mächtiges Muster, was aber auch wieder Konsequenzen hat, natürlich.
Aber auch eins, was finde ich immer unterschätzt wird.
Also wir haben jetzt in der Praxis halt auch oft das, wenn man diese agilen Prozesse oder ich weiß gar nicht, ob es mit den agilen Prozessen zu tun hat, aber wenn jemand von der Anforderung kommt, dann wird irgendwo ein Ticket eingestellt, hier, wir müssen diesen Vertrag noch mit anzeigen.
Genau.
Und eigentlich muss man den gar nicht anzeigen an der Stelle.
Also an der Stelle hilft vielleicht die Vertikalisierung, dass man dann darüber nachdenkt, weil es plötzlich teuer was anzuzeigen, von dem man die Daten gar nicht im Zugriff hat.
Aber es ist teilweise so einfach, einfach auf einen Link zu springen.
Der öffnet sich in einem neuen Tab.
Da kann sich ein Sacharbeiter was angucken und schließt ihn halt wieder, wenn der fertig ist.
Also 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.
Du hattest gerade den Begriff Vertikalisierung genannt.
Magst du den kurz erklären?
Ja, also auch das ist ein Einschub.
Auch das ist ja was, was wir hier sehr gerne bei InnoQ machen und was mittendrein in unseren SCS-Architekturen ist, dass wir versuchen, möglichst Die Dinge, die eine hohe fachliche Kohärenz haben, versuchen zusammenzustecken in ein System und andere Systeme oder 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.
Und das kann man sich im Grunde dann wie verschiedene Vertikalen vorstellen, die halt Ende zu Ende, also von der UI bis zur Datenhaltung, mit einem Team relativ autonom an dieser Sache arbeiten können.
Und uns gefällt das halt deshalb gut, weil die Teams eine gewisse Expertise zu, was weiß ich, allen Vertragsthemen oder sowas aufbauen können und über High-Level-KPIs gesteuert werden können.
Das ist einfach selber überlegen, wie bringe ich meine Vertikale sozusagen zu einem besseren Resultat im Gesamtkontext.
Und genau, grundsätzlich geht es eigentlich darum, Dass sich die Teams nicht auf den Füßen stehen, dass man irgendwie die Komplexität von so ganz großen Gesamtsystemen zerteilen kann in Systeme, die genau eine Größe haben.
Da kann man wieder die berühmten zwei Pizzaschachteln irgendwie rausholen, mit zwei Pizzen ernährt werden können.
Ich weiß immer gar nicht, auf welche Zeiteinheit eigentlich diese Pizzaschachtel halten muss.
Und was man vielleicht noch dazu sagen sollte, vielleicht hast du es schon erwähnt, diese Vertikalen, also es geht in...
bei diesen Integrationsmustern um die Integration von mehreren Vertikalen, von ein bis zwei weiteren Vertikalen.
Ja, also jetzt in der Sprechweise würde ich das jetzt, glaube ich, sagen.
Genau, wir wollen uns jetzt nicht festlegen, dass man das jetzt nur in vertikalisierten Systemen machen kann.
Deswegen würde ich halt sagen, der Übergang zwischen zwei Systemen oder die Integration zwischen den Frontends zweier Systeme, das ist eigentlich das Interessante.
Wobei jetzt ganz konkret zum Beispiel die Return-URIs.
Und die Links natürlich auch ein hervorragendes Integrationskonzept innerhalb einer Anwendung auch sind.
Aber natürlich, normalerweise, wenn wir über Frontend-Integration reden, dann reden wir genauso wie bei allen anderen API, Backend-API-Strukturen über Integration fremder System.
Typischerweise ruft man ja auch nicht seine eigene Backend-API, auch wenn das manchmal eine gute Idee ist.
Aber das ist nicht der Standard-Use-Gase.
Ein anderes Bild, was ich hatte, als du, Till, über Hyperlinks gesprochen hast, war das Bild von Amazon und diesem unfassbar großen Menüband.
Und das je nachdem, wo ich da draufklicke, ich in einer komplett anderen UI manchmal lande gefühlt.
Das Einzige, was noch gleich ist, ist irgendwie der Banner und das Menü.
Das Amazon-Grau und Orange, das erkennt man wieder, aber der ganze Rest ist weg.
Ja, also die UI unterscheidet sich dann schon.
Das ist doch auch eine Integration über Links, oder?
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 von irgendwem anders, weil es so aussieht wie vorher.
Also man muss im Prinzip typischerweise, um diese Patterns umzusetzen, alle Patterns umzusetzen, muss man sich die Gedanken darüber machen, wie eigentlich eine konsistente UX aussieht oder wie eine konsistente UI-Komponentenbibliothek aussieht konkret, damit halt einfach man zwischen verschiedenen Elementen dieser UI immer noch...
die gleiche Firma, die gleiche Webseite eigentlich erkennt.
Obwohl das Ziel von uns ja technisch eigentlich immer ist, dass wir uns eigentlich so benehmen, als wären wir nicht zusammenhängend.
Also 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, was weiß ich was, Tailwind, keine Ahnung.
Oder alles selber schreiben.
Das soll ja alles möglich sein.
Deswegen ist es halt umso wichtiger, dass wir auf einer UI-Ebene oder UX-Ebene definieren, was macht uns denn eigentlich aus?
Was in unserer UX muss in all diesen verschiedenen UI-Fragmenten, Teilen gleich sein?
Und im Fall von Amazon ist das halt wirklich erstaunlich wenig.
Also wenn man in den Checkout reingeht, ist das Logo noch irgendwie gleich.
Aber der ganze Rest?
Ist natürlich auch Absicht.
Die wollen gar nicht, dass wenn man im Checkout ist, man irgendwo draufklickt und den Kaufen-Vorgang abbricht wahrscheinlich.
Aber das ist so ein ganz klassisches Beispiel dafür, dass da offensichtlich irgendwie linkbasiert integriert wird eigentlich.
Ich bin in einem anderen System wahrscheinlich.
Kann man nicht wissen, aber wahrscheinlich.
Das finde ich aber auch ein schönes Beispiel dafür, dass man Man braucht irgendwie eine durchgängige UX auf der einen Ebene, aber ich glaube, da geht es vor allen Dingen an, kann man vielleicht über Corporate Identity reden.
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.
Also die Account Settings Seite, wo ich irgendwie die Sprache und meine E-Mail-Adresse ändern kann, da muss man vielleicht weniger Liebe rein investieren.
Wenn ich mich jetzt aber...
komplett darauf binde, dass alles aus einem Baukasten irgendwie zusammengeleimt werden muss, dann überall das gleiche Menü drüber.
Das ist ja eigentlich auch quasi visueller Lärm.
Also wenn man sich irgendwie vorstellt, dass man in einem Kundenportal rumklickt und irgendwem 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, keine Ahnung, mein Passwort zu verändern.
dann ist die Wahrscheinlichkeit, dass ich gerade im Passwort verä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, konzentrieren können.
Und dann will ich sie ja eigentlich gar nicht mit irgendwelchem Zeug belästigen, was aus komplett anderen Systemen da die ganze Zeit rein liegt sozusagen.
Daran habe ich noch gar nicht gedacht.
Ich glaube, wir müssen ein bisschen die Kurve kriegen.
Till, was machen wir denn, wenn wir nicht Limit-Links integrieren?
Ja, also das, was wir in dem 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, wieso das traditionell immer darauf rauslief, ist, dass wir transkludiert haben.
Also Transklusion ist so das zweite, nee, das dritte Pattern, was wir beschrieben haben, im Prinzip meiner Meinung nach so ein bisschen outdated ist, was aber immer noch relativ viele machen.
Und das funktioniert so, dass wenn ich eben mir überlege, dass ein Webbrowser, wenn ich den öffne, egal ob das jetzt irgendwie eine Angular-App oder React-App oder serverseitig gerendertes HTML ist, was ich da anzeige, ja aus einem großen HTML-Baum, dem DOM, besteht.
Und die Idee bei Transklusion ist, dass ich in diesem DOM bestimmte Links habe, konzeptionelle Links, das können irgendwelche Custom Elements sein oder also irgendwelche Web-Komponenten sein oder es kann irgendeine Konvention sein in meinem HTML, die ersetzt werden und zwar durch den Rückgabewert, den ich bekomme, wenn ich diesen Link auflöse.
Also ich habe einen Link dort, der auf ein HTML-Fragment im Prinzip zeigt.
Und das, was Transkursion bedeutet, ist, dass irgendein Stück Infrastruktur den DOM, das HTML durchpasst, diese Sockellinks im Prinzip identifiziert, HTTP GET-Request gegen diese Link-Ziele im Prinzip macht und den Rückgabewert an die Stelle einpflanzt.
Das kann man an verschiedenen Stellen machen.
Das kann man zum Beispiel klassisch irgendwo im Backend machen.
Dafür gibt es dann halt...
Technologien in Backends wie Edge-Side-Includes in Reverse-Proxies, uraltes Zeug, gibt es schon seit Ewigkeiten.
Oder Server-Side-Includes kann jeder Nginx, jeder Apache schon seit Jahren, was im Prinzip einfach nichts anderes ist, als dass der Web-Server nach einem bestimmten String in dem Fall sogar guckt, der passt da auch nicht den DOM, sondern der benutzt irgendeinen regulären Ausdruck, extrahiert die URI, macht eine HTTP-Get-Request da drauf und packt den Rückgabewert an die Stelle.
Das kann man aber auch ganz wunderbar im Frontend machen.
Da können wir 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 meinen Browser reinwerfen, in meine Webseite reinwerfen.
Und dann kann ich ja eben bestimmte Link-Komponenten in meinem HTML verwenden, egal ob ich das jetzt Client-seitig generiere, das HTML- oder Server-seitig generiere.
Und dann kann ich im Prinzip Teile davon austauschen.
Also einfach genau dasselbe, was ich auf dem Reverse Proxy mache.
Link identifizieren, HTTP GET Request gegen machen und den Link durch den Rückgabewert ersetzen.
Und ja, das klingt irgendwie einfach.
Das ist auch technisch sehr, sehr einfach eigentlich.
Das kann man halt wirklich mal so eben machen.
Das hat aber unglaubliche Konsequenzen, weil das Problem halt einfach ist, dass ich HTML aus einer fremden Quelle in einen neuen Kontext reinwerfe einfach.
Und HTML kommt halt typischerweise nicht allein, sondern das hat ja auch Annahmen, die es typischerweise über die Umgebung macht.
Und so das Klassischste oder Offensichtlichste ist wahrscheinlich CSS.
Also ich erwarte halt 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 was relativ.
kompliziert ist.
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 halt 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, wieso das so wenig Leute machen.
Das liegt, wenn man kleinseitige Transklusionen macht, finde ich ziemlich auf der Hand, dass man das in der Regel will.
Aber vielleicht ist das Thema auch einfach schon so durch, dass da auch keiner mehr Gehirnschmalz reinstecken möchte.
Ja, also erklären kann man es, aber die Leute verstehen es oftmals nicht, wie jetzt HTML-Schnipsel werden gemeinsam integriert.
Normalerweise denkt man da eher so an JSON-Payload und dann wird das halt im HTML dann neu gerendert.
Aber nee, das ist einfach schon gerendert, das HTML, was da mitkommt.
Genau.
Das funktioniert halt auch gar nicht gut, wenn man HTML komplett kleinzeitig generiert.
Also 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.
Also ich kann ganz wunderbar kleinseitig in der Angular-App Sachen rein transkludieren.
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 serverseitige Pre-Rendering-Logiken und sowas aufzuziehen.
Das will ich dann vielleicht auch nicht mehr.
Obwohl Server-Side-Rendering Ich würde es immer Edge-Side-Rendering nennen, ist ja heutzutage wieder cool.
Vielleicht erlebt das demnächst auch seinen Revival ganz ausschließend wenigstens nicht.
Das war jetzt das zweite Pattern, über das ihr geredet habt.
Wenn man über Patterns redet oder Muster generell, stellt man sich doch immer die Frage, welches Problem löst denn jetzt dieses Pattern?
Welches Problem löst jetzt Transklusion gegenüber anderen?
Transklusion ist halt sehr leichtgewichtig.
Also es ist relativ simpel, das umzusetzen in der reinen Integrationstechnik und es ist unglaublich flexibel eigentlich.
Also wenn wir uns jetzt mal diese ganzen Probleme, die ich schon genannt habe, Styling und so weiter, so ein bisschen ausklammern, dann kann man sich halt in so einer ganz klassisch serverseitig gerenderten Welt vielleicht vorstellen, dass das unglaublich mächtig sein kann.
Also wir kennen Online-Shops, da funktioniert der Online-Shop im Prinzip so, dass ich eine Suche habe, also ein...
wir haben es jetzt Vertikale genannt, also eine Vertikale habe, die die Suche implementiert.
Und diese Suche, ich suche nach Toaster, keine Ahnung, die retourniert dann nicht irgendwie eine Liste von Produkten, sondern die retourniert 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-Site-Includes zum Beispiel oder kleinzeitig.
weiß ich in dem Fall nicht, 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.
Das ist ja typischerweise eine andere Artikelkache, als die ich sonst so habe.
Aber für die Artikelkache, für die Suche, möchte ich jetzt den Preis nicht mehr rechts, sondern links anzeigen und der Streichpreis soll was weiß ich wohin, dann ändern die das halt einfach.
Also das ist was 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 Laufzeit-Integrationen im Prinzip noch unter Kontrolle behält, weil halt gerade Änderungen an den Seitenaspekten, also insbesondere an dem CSS oder auch am JavaScript, was sonst noch so drumherum sind, relativ schwer abzuschätzen sind, wenn überall irgendwelche Snippets reingeworfen werden, von denen man eigentlich gar nicht so genau weiß, was sie eigentlich 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 nochmal versuchen rauszukramen und verlinken.
Aber im Prinzip ist das Thema, glaube ich, alleine durch den wahnsinnigen Hype von Frontend-seitigen Rendering-Techniken.
Also ich möchte heutzutage, also ich schon noch, bin irgendwie alt, aber die meisten Leute wollen heutzutage kein HTML mehr serverseitig machen.
Aus welchen Gründen auch immer.
Und das führt dann halt ganz häufig dazu, dass Transkursion einfach von vornherein raus ist.
Dafür war das nie gedacht.
Aber damals war es ein relativ mächtiges Werkzeug und hat, wenn man wirklich gewusst hat, was man tut und die Probleme, die das Ding induziert, dieses Ansatz induziert, sauber adressiert hat, war es wirklich eine sehr mächtige Sache eigentlich.
Anja, 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.
Also 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...
Wir haben uns in der Reihenfolge ein bisschen vertan, wenn wir von der losen Kopplung argumentieren, haben wir den iFrame eigentlich noch dazwischen.
Die Embeddable Frames sind eigentlich das Pattern, was noch da 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 sozusagen von außen, von innen man andere Schnittstelleneigenschaften hat.
Oder Till, korrigiere mich das.
Es gab auch viele Leute, die irgendwie gesagt haben, Transklusion, das sind ja eigentlich I-Frames für abgemilderte I-Frames oder sowas.
I-Frames sind natürlich auch ein Muster, was es gibt, was wir auch beschrieben haben, was ich auch nach wie vor für Super relevant halt, auch wenn es total unbeliebt ist.
Aber iframes sind halt tatsächlich das Muster.
Also was sind iframes?
Iframes sind im Prinzip einfach ein bestimmtes HTML-Element, was einfach einen komplett eigenen Browser-Kontext mit eigenem JavaScript-Umgebung und allem eröffnet und im Prinzip einfach einen Bereich in einer Webseite einfach 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 ja wirklich riesige, potenziell riesige Mengen an irgendwelchen Browser-Kontexten mit sich.
Man will ja auch nicht einen Browser aufhaben, in dem 200 Tabs auf sind.
Einige wollen das schon, also ich nicht.
Aber das Problem dabei ist halt einfach, dass irgendwann die Maschine langsamer wird, weil so ein Browser-Tab einfach was Teures ist.
Das ist viel, viel, viel...
teurer ressourcenmäßig, als wenn man einfach ein paar HTML-Fragmente irgendwo reinwirft.
Der Vorteil bei iFrames ist halt 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, denen ich nicht traue zum Beispiel dass sie sicheres JavaScript schreiben können, dass das HTML nicht irgendwelche Cross-Site-Scripting-Angriffe mit sich rumschleppt und sowas, dann bleiben eigentlich neben Links, bei denen das natürlich auch möglich ist, eigentlich nur die iFrames über, wenn ich eben genau die Anforderungen habe, die Tamo eben meinte, dass ich eben Informationen von zwei oder mehr Systemen, von zwei oder mehr Vertikalen 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 im Prinzip auch 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 eben wirklich autonom ist.
Das ist eine Anforderung, die geht in der Mobilanwelt.
typischerweise nicht so einfach.
Wenn ich aber in einer Mobilanwendung einfach quasi einen kleinen Webview, einen Mini-Browser ohne Adresszeile und alles einbinde und darin eine Seite öffne, dann kann ich eben 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 und sowas.
Das ist aber im Prinzip konzeptionell exakt dasselbe wie ein iFrame in der Website.
Mit genau denselben Vor- und Nachteilen ist auch schwergewichtig.
In der Mobilwelt kommt natürlich noch hinzu, dass das dann halt aussieht wie eine Webview, also wie ein nicht-nativer Teil der UI.
Aber das sind Dinge, die kann man dann teilweise wahrscheinlich auch beantworten.
Aber genau.
Okay, damit haben wir drei Pattern besprochen.
Vier sogar.
Zwei sind noch.
Das sind im Prinzip die etwas moderneren Formen.
Das erste von den beiden, also da geht es sehr stark um das kleinseitige Rendering.
Wie mache ich Frontend-Integration, wenn ich kleinseitig wirklich rendern möchte?
Und das erste Pattern, dafür war es 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.
Also die technische Implementierung davon sind in der Regel einfach Web Components.
Also was sind Web Components?
Web Components ist so ein Sammelbegriff.
für zwei APIs, die der Browser bereitstellt.
Das eine ist Custom Elements und 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 Komponente, eine UI-Komponente von Team A, also diejenigen, die das JavaScript bereitstellen, einfach an irgendeiner beliebigen Stelle ihrer Anwendung, ihrer UI...
instanziieren, indem sie halt 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 und trotzdem noch in der Webseite rumklicken kann.
Dann müsste ich einfach nur dafür sorgen, dass das Team, was für den Chat mit dem Kundenportal verantwortlich ist, ein JavaScript bereitstellt, was eine Komponente beinhaltet, beschreibt, ein Custom Element beschreibt, was im Prinzip diesen Chat implementiert.
Also was zum Beispiel standardmäßig irgendwie unten rechts in der Seite so eine kleine Sprechblase oder sowas anzeigt.
Und wenn ich draufklicke, geht halt ein HTML-Element oben drüber auf.
das ist dann eben irgendwo in diesem Custom-Element vergraben, geht oben drüber auf und da drin ist dann der Chat mit meinen Verläufen von den vorherigen Seiten und was weiß ich auch immer.
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 jetzt überlege, dass ich dieses Icon zum Beispiel habe 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.
Also wenn ich auf diese Sprechblase klicken würde und dann soll dieser Overlay entstehen, dann bedeutet das, dass mein Custom Element HTML-Elemente in dem DOM instanziiert.
Das heißt, eigentlich habe ich nach wie vor dieselben Probleme, die ich auch schon mit Transkursionen hatte, nur dass ich das jetzt alles kleinseitig mache, indem ich JavaScript benutze, um das HTML zu erzeugen und nicht einfach irgendwelches HTML vom Backend lade.
Und da kommt eben der Shadow DOM, den hatte ich ja eben auch schon mal erwähnt dazu.
Der ist im Prinzip einfach die Möglichkeit, dass man Bereiche des DOMs, also dieses gesamten Seitenbaums, im Prinzip zurücksetzt, was das CSS-Styling anbelangt.
Also dass ich eben einfach einen Teilbaum nehmen kann, zum Beispiel den Teilbaum, der mein Overlay ausmacht, 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, Times New Roman, Schwarz, keine Ahnung.
Und insbesondere aber auch umgekehrt, alles, was ich hier drin an CSS verwende, möchte ich nicht, dass das nach außen liegt.
Das sind also die beiden Hauptbestandteile von Web-Components.
Also einerseits die Möglichkeit, JavaScript zu definieren, was Komponenten beinhaltet, die ich in irgendeinem beliebigen Kontext verwenden kann.
Und auf der anderen Seite, dass ich eben, Isolation von Styling habe, sodass ich diese ganzen Probleme, die wir eben bei Transklusion schon durchgekaut haben, nicht habe.
Und das Pattern, um jetzt endlich mal dahin zu kommen, was wir beschrieben hatten, waren die Self-Contained Components, die im Prinzip einfach die Idee haben, ich habe eine Bibliothek von Komponenten, die von verschiedenen Teams bereitgestellt werden, die ich also optimalerweise in Form eines JavaScripts zur Laufzeit lade, ich sage also, ich lade die Komponentenbibliothek meiner Kundenservice-Vertikale in meinem, keine Ahnung, irgendwo im 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.
So und das bedeutet halt, dass wenn jetzt diese Kundenservice-Vertikale diese Chat-Funktionalität verändern möchte, ja, was weiß ich, jetzt soll auch noch Spracherkennung da rein oder sowas, dass ich mit dem Ding quatschen kann oder Videotelefonie, was weiß ich, 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 halt.
Das ist im Prinzip wirklich sehr ähnlich zur Transklusion, in dem Sinne, dass das immer noch alles in einer Seite landet.
Das ist aber dadurch, dass ich heutzutage Dinge wie Isolation habe, aber eben auch kleinstelliges 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 halt Angular-Komponenten einfach als Web-Components exportieren.
Die sind meistens nicht sehr leichtgewichtig, also man muss ein bisschen vorsichtig damit sein.
Aber ich kann halt jede beliebige Angular-Komponente im Prinzip als Web-Component exportieren, die in irgendeinen Kontext werfen und dann läuft die da magisch.
Das ist auch alles wieder nicht so einfach natürlich.
Das hat auch alles wieder Konsequenzen.
Das ist alles sehr unangenehm, wenn es um Authentisierung geht.
Also wie kommen die an die Daten?
Wie kommen die dazu, dass da irgendwelche Tokens vorhanden sind, mit denen man Backend-APIs aufrufen kann?
Das ist alles kein No-Brainer, aber das ist auf jeden Fall etwas, was man in den Griff bekommen kann und was man, glaube ich, auch relativ praktisch umsetzen kann, gerade weil modernen Frontend-Frameworks das eben auch sehr gut unterstützen.
Entscheidend ist ja, glaube ich, schon nochmal zu sagen, dass es auch hier ja so ist, 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 Bildzeit als NPM-Paket oder irgendwie sowas eingebunden werden.
Das ist die Idee.
Und dann das letzte Pattern.
hatten wir an Anlehnung an die bestehenden Patternsprachen Plug-in-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, die ist ganz einfach.
Ich habe eine Single-Page-App, irgendein Framework, irgendeine Wahl, nehmen wir mal Angular gebaut.
Dann ist 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 Plug-in-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 eine oder mehrere Angular-Module bereit, die ich einfach zur Laufzeit im Prinzip da reinlade.
Und dafür gibt es halt schon technische Implementierung.
Also 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 dann auch ohne Webpack machen.
Das sind aber eben einfach Dinge, die, ja, genau.
Wir haben versucht, einen neutraleren Namen zu finden.
Deswegen heißt es Plugin-Mechanismus.
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 Schnittstellen dann hoffentlich implementieren, verschiedene definierte Schnittstellen dann im Optimalfall definieren.
Ich lade diese Komponenten oder Module und instanziere 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 Modul für das Profil, Passwort ändern, bereitstellt, sich entscheidet, hey, wir wollen jetzt hier auch noch irgendwie eine zusätzliche Prüfung einbauen, keine Ahnung, ein Captcha, wenn du dein Passwort ändern willst oder sowas.
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.
Genau.
Also Hyperlinks, Return-Uris, Transklusion.
Isolated Frames, Self-Contains Components und Plug-in Module.
Ihr hattet ja schon gesagt, sowas wie Transkursionen seht ihr in der freien Wildbahn eher weniger jetzt.
Das ist eher so ein damals Ding gewesen oder irgendwie ein Ding gewesen, was eher so nur wenige Leute benutzt haben.
Welche Muster sieht man dann heutzutage implementiert oder auch welche Kombinationen von Mustern?
Naja, also.
Das widerspricht dem jetzt, aber Transklusion mit Server-Site-Includes benutzen schon einige unserer Kunden.
Ich glaube, die Kleinzeit-Transklusion ist, sagen wir mal, ein bisschen respekteinflößender.
Aber das setzen schon Kunden von uns durchaus auch sehr produktiv ein und auch so, dass es einfach keine Beschwerden macht.
Genau, wenn man es adressiert hat, funktioniert es.
Hat halt die Restriktion, serverseitig zu sein.
Was ich halt schon...
Wovon ich viel gehört habe, dass es auch total toll sein soll, was ich aber selber leider noch nie gesehen habe, sind wirklich diese Plug-in-Module.
Also ich habe darüber viel gelesen.
Einige unserer Kollegen haben damit auch Sachen gemacht, auch teilweise zu Zeiten, wo das noch relativ unklar war oder unstandardisiert war im Prinzip.
Ich finde es...
Persönlich ziemlich schwierig, weil ich eigentlich keine Lust hätte, mich auf ein Framework zu committen.
Ich verstehe das immer nicht, wieso 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 halt häufiger schon gesehen habe, was ich auch selber ziemlich oft mache, ich mache auch immer noch in einigen Projekten Transkursionen, aber ich mache relativ viel dieses Self-Contained-Components-Zeug.
Also Web-Components bauen, die man dann in andere Kontexte reinwirft, ist was relativ Einfaches.
Das kann man ganz gut machen und meiner Meinung nach ist es halt so.
Das, was man typischerweise heutzutage macht.
iFrames ist klar, ganz viele proprietäre Systeme oder sagen wir mal, keine Ahnung, wenn ich irgendein ERP-System nehme und ich möchte in dieses ERP-System irgendeine Ansicht rein integrieren aus einem internen System, passiert das typischerweise nach wie vor über iFrames.
iFrames ist einfach eine Technologie, die man sehr häufig sieht, ein Hyperlinks, ja eh.
Also im Prinzip kann man sich orientieren.
Man kann im Prinzip auswählen aus diesen verschiedenen Aspekten.
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 wie Tammo schon sagt, wenn ich mich vor Jahren oder vor drei Wochen, keine Ahnung, auf Transklusion festgelegt habe und damit umgehen kann, dann ist das sicher ein Muster, was auch noch die nächsten zehn Jahre.
vernünftig trägt.
Da spricht überhaupt nichts dagegen.
Der Trend, dass Leute plötzlich Frontend-seitig rendern wollen, der spricht ein bisschen dagegen.
Ich muss irgendwelchen Leuten, die noch nie irgendwie serverseitiges Rendering gemacht haben, plötzlich erklären, wie man sowas macht.
Und das sind eben Dinge, die eher auf einer weniger technischen oder architektonischen, einfach auf einer organisatorischen Ebene dagegen arbeiten.
Das, was halt wichtig ist, ist, wenn ich mich entschieden habe, werde ich es nicht mal so eben ändern, glaube ich.
Was finde ich dann ein spannender Perspektivwechsel ist, also wenn ich ein System baue oder ein System of Systems baue, dann habe ich eine gewisse Entscheidungsfreiheit oder kenne sozusagen die beteiligten Protagonisten oder integrierende Systeme oder bereitstellende Systeme.
Wenn das aber über solche Grenzen hinausgeht, finde ich, wird es nochmal spannend, weil irgend so eine Page-App, die nicht darauf geachtet hat, dass Deep Links funktionieren, lässt sich halt noch nicht mal über Links irgendwie integrieren in deine Anwendung.
Und also Till hatte mir das halt damals erzählt, ich glaube, Microsoft war das, deren Dynamics-Komponenten man, also deren ERP-System man ziemlich gut transkludieren kann oder über iFrames einbinden kann, weil diese URL-Absprünge halt gut funktionieren.
Das ist ja auch eine bewusste Designentscheidung, die irgendjemand mal getroffen haben muss.
Also würde ich schon auch sagen, wenn ich Systeme designe, Also je nach Domäne, in der ich das baue, sollte man schon vielleicht auch daran denken, wie können andere das möglichst lose gekoppelt integrieren und einbinden.
Frontend-Integration, habe ich das Gefühl, ist immer noch so ein Nischending.
Wenn jemand über Integration redet, wird sofort über, ja, da brauchen wir eine API oder einen Datenzugriff oder was weiß ich was.
Aber braucht man in vielen Fällen halt einfach nicht, sondern eigentlich nur eine URL.
Und die kann man auf verschiedene Arten und Weisen einbetten oder aufrufen oder wieder zurückspringen.
Und das finde ich aber eigentlich, 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.
Ihr hattet ja gerade auch schon gesagt, wenn ich mich einmal für einen Pattern entscheide, dann sollte das halt auch langfristig haltbar sein.
Aber ist es denn in der heutigen agentischen 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?
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 schon ziemlich wehtun und man würde davon abraten.
Das ist ja eben genau auch der Grund, warum.
warum wir schon wirklich fest der Meinung sind, nicht, dass irgendein Ansatz davon nicht gut wäre oder so, sondern dass das eine Liste von Ansätzen ist, 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 oder so.
Aber vielleicht auch gegen einen Ansatz ganz explizit entscheiden sollte.
Das, was, glaube ich, das Agentische heutzutage so ein bisschen kippt, Weswegen ich mir vorstellen kann, dass Frontend-Integration tatsächlich, also es ist so sehr ins Blaue reingedacht, aber dass Frontend-Integration tatsächlich so ein bisschen aus der Mode kommen könnte, ist, dass das Agentische natürlich erlaubt, dass man einfach monolithische UIs baut.
Also 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-API 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.
Hochkohärent natürlich sein kann, weil das alles aus einem Guss kommt, alles kein Problem, alles irgendwie Angular.
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 das, also gerade am Anfang, als Single-Page-Apps durch die Tür kam, haben das viele Leute gemacht und haben dann relativ schnell festgestellt, dieses Ding beinhaltet am Ende die gesamte Logik.
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, dass in die Datenbank geschrieben wird.
Hoffentlich machen sie ganz viel Security noch und Sicherheitsforschung.
Da drücken wir immer die Daumen, dass das so ist.
Aber wenn das so ist, dann ist halt die gesamte Logik, der gesamte Arbeitsflow, wie genau erfasse ich meine Kunden und Vertragsdaten, das ist alles vorne in der UI drin.
Und wie gesagt, ich glaube, das war schwer zu handeln.
Man könnte darüber spekulieren.
ob so eine UI, so eine monolithische Single-Page-UI 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 geht nie jemanden 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üfungen auf der Ebene.
Ja, es 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 sowas muss natürlich auch in den Backends drin sein.
Also komplexere fachliche Validierungen, die überhaupt die gesamte Berechnung muss ja in den APIs sein.
damit man überhaupt sichere Frontend-Anwendungen, egal ob sie jetzt monolithisch oder modolithisch sind, bauen kann.
Aber wenn ich jetzt im Prinzip wirklich sichere Backend-APIs habe, die irgendwie HTTP sprechen oder Websockets mit dem Frontend oder so, egal, wenn die wirklich sicher sind, weil die gesamte sicherheitsrelevante oder die gesamte relevante Funktionalität in diesen APIs sind, dann kann ich das Frontend ja eh einfach wegwerfgenerieren.
Ja, es juckt ja keinen mehr.
Dann generiert halt da irgendwie Das neue Cloud-Code, irgendwelche Unsinnigkeiten in die UI, ja, wurscht.
Ist ja nicht sicherheitsrelevant.
Das Backend überprüft es ja eh.
Das heißt so, die Art und Weise, wie KI im Prinzip in Frontend-Entwicklung einschlägt oder überhaupt in die Entwicklung einschlägt, schält 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, generier mal, den Code gucken wir uns nicht an und hau raus, den Kram.
Und das kann ich mir halt nur dann leisten, wenn ich halt einfach sage, ist auch wurscht, was diese Anwendung baut.
Ob das wirklich so egal ist?
Also ich selber kaufe das gerade nicht, was ich sage, glaube ich.
Ich habe einfach zutiefst die Befürchtung, dass das genau das ist, wo 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 mach doch, schmeiß rein, wir brauchen schon Frontend-Integration.
Aber für mich ist das 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.
Die Frage ist ja, für was und für wen, welche Anwendung ich traue.
Ich glaube, es gibt ja schon diesen Trend der Citizen-Developers, die Vibe-Coden, die gar nicht so gut programmieren können, die sich dann aber auf ein Backend-as-a-Service wie Superbase oder sowas stützen, was einem all das schon mal bringt zumindest.
Also die ganzen Fußangeln, in denen man sonst...
tappen kann, versuchen die mit Row-Level-Security oder sowas schon irgendwie zu lösen und dann kannst du da drauf deine Web-Wegwerf-Frontends irgendwie relativ gefahrlos draufbauen.
Ich glaube, es ist aber nicht unbedingt unser typischer Anwendungsfall in den Sphären, in denen wir uns bewegen.
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.
Die Frage erstmal, Anja, ist ja noch, ob du auch auf der Europlop Patterns präsentieren willst.
Ich überlege es mir.
Es hört sich auf jeden Fall methodisch interessant an.
Ja, ich würde nur empfehlen.
Ja, vielen Dank, Anja.
Vielen Dank, Anja.
Ciao.