Self-contained Systems und Frontend-Integration – Teil 2

Also sind offensichtlich Single Page Apps zumindest als Makroarchitektur-Entscheidung nicht das, was wir eigentlich benötigen. Wie machen wir es denn dann? Also was ist das, wie wir jetzt definieren, wie sich die verschiedenen Self Contained Systems integrieren.

Till: Ja, ich meine, wir reden ja über Webanwendungen, insbesondere eben im Kontext von Self Contained Systems ja ganz explizit. Wir reden über Webanwendungen, und wenn ich das tue, dann gibt es ein Konzept, das nennt unser Kollege Stefan immer “das magische Integrationskonzept des Webs”, und das ist der Link. Also, wenn ich unterschiedliche Dinge integrieren möchte, zum Beispiel von einem System auf Informationen eines anderen Systems verweisen will, dann tut es in vielen Fällen auch einfach ein Link: Hier geht es zu den Vertragsinformationen, dann klicke ich da einfach drauf. Wahrscheinlich entspringen jetzt schon in vielen irgendwelche negativen Gefühle: Wie kann der heutzutage noch über Links reden? Das ist irgendwie so was, was ich ganz häufig in dem Kontext erlebe. Nur weil es ein altes Konzept ist, optimistische Menschen würden sagen, ein bewährtes Konzept ist, ist es nicht automatisch schlecht, eigentlich. Natürlich reicht das nicht für alle Anwendungsfälle. Also, Self Contained Systems oder der Ansatz, den ich eben präferieren würde, wie man ihn jetzt auch immer nennt, bedeutet aus meiner Sicht nicht, dass wir massive Abstriche oder vielleicht überhaupt Abstriche an unsere Ansprüche, die wir zurecht heutzutage an moderne Web APIs, also Webanwendungen, haben, dass wir da irgendwelche Abstriche machen müssen, sondern ich erwarte natürlich, dass das moderne Anwendungen sind. Das heißt, ich muss irgendwie ein Konzept haben, um Inhalte von anderen Systemen zu integrieren. Und etwas, was dann eben völlig offensichtlich zum Beispiel auch ist, aber einen unheimlich schlechten Ruf hat, ist dann so etwas wie ein IFrame. Ein IFrame ist ja eigentlich nichts anderes als ein Link, der seine Antwort direkt in einem seperaten Browserfenster in der Seite einbettet. Das hat einen wahnsinnig, für mich subjektiv gefühlt, einen wahnsinnig schlechten Ruf in unserer Branche. Man fragt sich eigentlich immer: Warum? Das kann eine von vielen Optionen sein. Wenn ich jetzt irgendwie hingehen würde und immer sagen würde, IFrames sind die universelle Waffe und alles, was du machen möchtest, machst du damit, das ist natürlich auch Quatsch. Aber es ist eine Option, die existiert.

Falk: Ich glaube, dass ist so ein bisschen auch der Grund, warum das so einen schlechten Ruf hat. Weil das eigentlich immer so ein bisschen der Hammer war, mit dem die Leute all ihre Nägel bearbeitet haben. Aber es liefert einem eine Sand Box und es reduziert das Problem von Integration von verschiedenen Versionen auf Null.

Eberhard: Genau, das wäre jetzt das, was mich noch mal interessieren würde: Also bei einem IFrame sind die Vorteile offensichtlich, wie du gerade sagtest, dass ich eine Sand Box habe. Also wird de facto wird nichts geteilt. Ich könnte jetzt also ganz anderen JavaScript-Code haben und ein ganz anderes HTML und so.

Till: Richtig. Du kannst auch deinen JavaScript-Code durch irgendeinen Programmierfehler grundsätzlich völlig zerschießen und irgendwelchen totalen Unfug machen. Du blockierst damit nicht das Einbetten ins System und umgekehrt. Das ist ein unheimlich hoher Wert. Du hast zum Beispiel auch Isolation, was die Sicherheit anbelangt, etwas, was wir halt häufig vergessen. Es gibt/gab - ich weiß nicht, ob es wirklich noch einer ernsthaft versucht - Versuche, Code innerhalb eines Fensters, innerhalb eines Browserfensters, wirklich aus Sicherheitsaspekten zu isolieren. Also, hinzugehen und zu sagen: Unser Code, der hier ausgeführt wird, beinhaltet irgendeine Logik, irgendein Geheimnis, irgendein Passwort, das möchte ich vor dem Zugriff von anderem Code in demselben Fenster, weil ich da vielleicht noch Google Analytics integriere oder was weiß ich, möchte ich das auf jeden Fall schützen. Das ist alles Augenwischerei. Das kann nicht funktionieren, wenn du wirklich Code auf einer richtigen Codeebene echte Trennungen in einem Browser willst, dann gibt es leider nichts anderes als den IFrame.

Eberhard: Aber was ist denn das Problem damit? Wenn das so viele Vorteile hat und so eine klare Isolation bringt, müsste es doch eigentlich ein super Konzept sein.

Falk: Ja, es ist halt eigenlich relativ hässlich und es hat den wahnsinnigen Nachteil, dass es eigentlich primär immer irgendwie auch auf einer Breiten- und Höhenangabe angegeben ist. Das heißt, man kann hier schon versuchen, die in eine gewisse Dynamik zu ziehen, aber im Endeffekt muss ich dann doch wieder introspizieren, wie groß dieses Fenster eigentlich sein soll, damit der Inhalt entsprechend dargestellt wird und halt in einer Umgebung, wo wir heute ja nicht mehr von einer statischen Webseitenbreite ausgehen, sondern wo wir eine Webseite haben, die responsive für verschiedenste Geräte und Browsergrößen funktionieren muss, funktionieren IFrames halt an vielen Stellen sehr, sehr schlecht, nur noch.

Eberhard: Also, das heißt, es ist primär ein Designproblem tatsächlich im Sinne von einem Webdesignproblem.

Till: Genau. Das kann man halt irgendwie auch alles adressieren, dann verliert es aber plötzlich so ein bisschen den einfachen Character. Ich hab schon von mehreren Leuten gehört, die halt wirklich auf IFrame basierend echt Gehirnschmalz investiert haben, und eben genau diese Probleme adressiert haben: Also ein IFrame hat zum Beispiel eine Höhe, die, wenn man nichts tut, von außen vorgegeben ist, nicht von innen. Aber Responsive Design bedeutet, dass sich die Größe eines Elements aus dem Element selbst ergibt und eben gerade nicht von außen vorgegeben wird. Und was dann eben die Konsequenz ist, wenn ich das nicht adressiere, dass ich am Anfang ein IFrame habe, da passt noch alles rein, und dann schließe ich zwanzig Verträge mehr ab und plötzlich habe ich dieses Scrolling im Scrolling drin, und das kann ich halt auf einem Mobiltelefon dann irgendwie völlig vergessen.

Falk: Und es gibt schon das Gefühl, häufig, dass man in dem User Experience Konzept-Bericht: Man merkt als Kunde relativ häufig, dass man in einer anderen Anwendung, in einer eingebetteten Anwendung interagiert, und das möchte man häufig nicht haben.

Till: Deswegen. Also ich möchte das auch gar nicht, auf gar keinen Fall, wir drehen da jetzt ja schon lange drum. Das mache ich auch gerne, weil es halt einfach auch wieder so ein unterschätztes Ding ist, was irgendwie diesen Schmuddelruf hat. Wenn man aber viele Leute fragt, warum eigentlich, dann kommt nicht aus der Pistole geschossen: Des- und des- und deswegen, ich sollte es einfach auf der Liste der Möglichkeiten haben.

Wenn ihr nichts hinzuzufügen habt, würde dann ich auch zur nächsten Option gehen: Was ich zum Beispiel auch noch machen kann, was eigentlich konzeptionell sehr ähnlich wäre, wäre, dass ich den Inhalt dieses Links, also, wenn ich am Anfang einfach nur einen Link hatte, ich war auf der Kundenansicht und da stand “zu der Vertragsübersicht”, dann kann ich auf diesen Link klicken, dann kann ich das als IFrame modellieren, die Verträge einbetten in einem eigenen Fenster. Was ich aber natürlich auch machen kann, ich benutze einfach zum Beispiel Ajax, löse diesen Link unten drunter auf und transkludiere, nennen wir es vielleicht einfach mal so, den Inhalt der Antwort einfach an die Stelle, wo vorher der Link war. Man nennt das häufig auch Link Replacement. Das ist ein deutlich nahtloserer Vorgang, eigentlich, der aber natürlich technische Fragestellungen mit sich bringt, weil ich plötzlich mein DOM, mein HTML-Dokument, was vorher unter der Hoheit meines eigenen Self Contained Systems war, mit Inhalten von jemand ganz anderem, von dem ich eigentlich auch gar nicht so genau weiß, was er mir da eigentlich schickt, erweitere. Das ist etwas, da kann ich nicht einfach sagen, hier, benutz die und die Bibliothek, um das zu machen, sondern da muss ich eben auch ganz bestimmte Rahmenbedingungen festlegen, unter welchen das funktioniert. Ich habe da mal einen Blogpost drüber geschrieben, falls das irgendjemanden interessiert, können wir vielleicht auch in die Shownotes tun. Das ist keine Raketenwissenschaft, aber man muss schon ein bisschen wissen, was man dafür tut: Wie man das angeht, und wenn man das machen will, was eben Vorteile hat bezüglich dieser Nahtlosigkeit, da muss ich eben bestimmte Fragen beantworten, was eben einfach vorher geschehen sollte.

Eberhard: Kannst du so ungefähr sagen, welche Fragen das sind? Also müssten wir uns jetzt irgendwie darauf einigen, dass wir alle jQuery benutzen?

Till: Genau. Du kannst dir ganz einfach vorstellen: Du holst dir von einem anderen System eine Tabelle. Du holst dir ja vor allem das HTML. Du ziehst dir von einem anderen System eine Tabelle mit deiner Vertragsübersicht. Und wenn du die jetzt bei dir drin hast, und du hast, zum Beispiel, in deinem System kein Styling vorgesehen für diese Tabelle, dann sieht die halt irgendwie schlecht aus. Das heißt, du musst halt in deinem System in irgendeiner Form Styling oder bestimmte Informationen, teilweise auch Funktionalitäten, vorhalten, damit du Inhalte von jemand anderem auch ordentlich darstellen kannst. Das kann man so lösen, dass man sich auch diese Informationen von dem anderen System in irgendeiner Form holt, man kann ja das CSS theoretisch im ganz extremen Fall einfach einbetten in die Antwort. Dass einfach das System selber dafür sorgt, dass es sich ordentlich stylt. Das hat Vorteile, das hat Nachteile, würde ich auch normalerweise so nicht empfehlen. Auf der anderen Seite könnte ich mich halt vielleicht vorher mit dem anderen System einigen: Welche Inhalte sind überhaupt erlaubt einzubetten, das finde ich irgendwie den pragmatischeren Weg. Zum Beispiel, wir erlauben Tabellen, wir erlauben Bilder, aber wir erlauben nicht Datepicker oder so etwas. Irgendwie so etwas.

Falk: Komplexe Elemente.

Till: Komplexe Elemente vielleicht. Und das wären halt Dinge, die muss ich einfach vorher adressieren; das ist aber letzten Endes eine Entscheidung, die ich treffen muss.

Falk: Was da, glaube ich, ganz wichtig ist, dass wir im Prinzip verstehen, dass HTML die Interface-Implementierung für ein Komponenten-Interface bildet. Und das sind diese Komponenten, die tendenziell dazu neigen, eher in diesem Bereich zu sein, dass man sie positiv teilen kann. Das sind halt die, die in der Regel aus unseren zentralen Repositories kommen. Der Vorteil ist hier, dass man die im Prinzip schon zur Build-Zeit testen kann, an der Stelle. Ich kann eine Referenz zu einem Repository schon zur Build-Zeit herstellen und gucken, ob das funktioniert, was ich da integriere, und kann halt eben diese Interfaces testen. Das ist dann ein dramatischer Vorteil und, selbst wenn ich etwas kaputt mache, selbst wenn die Tabelle zum Beispiel noch in einem anderen HTML-Element gewrappt ist, oder wenn die Tabelle eine Spalte weniger hat, als ich das noch vorher erwartet habe, dann geht in der Regel nicht das ganze System direkt den Bach runter. Dann habe ich kleinere Styling-Fehler, dann ist vielleicht irgendwo mal ein Button jetzt links anstatt rechts oder vielleicht ist es auch wirklich mal so, dass ich einen Button nicht benutzen kann, weil jemand das JavaScript, welches dahinter steckt, leider total verdengelt hat. Aber in der Regel ist der Schaden relativ minimiert auf diese Komponente, die ich einbette.

Eberhard: Ich glaube, das ist ein ganz spannender Punkt, wenn ich das richtig verstanden hab: Die Aussage, dass wir eigentlich darüber sprechen, dass wir dort eben so was wie eine Schnittstelle haben.

Till: Richtig, wir haben eine Schnittstelle im Frontend, für die genau dieselben Fragestellungen gelten wie für Schnittstellen im Backend. Also die Fragestellung der - ich rede auch bei Backend-APIs ungern von Versionierung, aber alle nennen es irgendwie so - die Fragestellung, wie ich solche Sachen dann immer noch lose kopple, sind genauso zu beantworten, wie sie im Backend zu beantworten sind.

Eberhard: Ja genau. Versionierung, also dass irgendwie jemand etwas ändert, was zurückkommt…

Till: Genau. Was eben keine Tabelle mehr liefert, sondern ein Bild. Und das kann ja Auswirkungen für mich haben. Muss vielleicht nicht, wenn ich das vorher ordentlich gemacht habe, und vorher diese Schnittstelle nicht in Stein gemeißelt habe, sondern mich um flexible Rahmenbedingungen gekümmert habe, aber es ist natürlich was anderes. Und ob ich das will oder nicht, das ist halt eine Frage, die muss ich beantworten.

Eberhard: Wäre denn diese Frage nach dem Styling, von dem ihr gerade geredet habt, wäre das auch ein Teil dieser Schnittstellenabsprache, dass wir darüber reden, wie…

Till: Auf jeden Fall. Das gehört dazu. Funktionalität auch. Wir wollen ja nicht irgendwelche toten Inhalte integrieren, sondern wir wollen natürlich, dass auch von einem anderen System Dinge kommen, die vielleicht irgendwelche moderneren Dinge tun. Meinetwegen, vielleicht ist es ja eine Angular-App. Das wär so ein klassischer Fall: Vielleicht ist das, was ich darüber bekomme, die Angular-App aus dem anderen System und die transkludiere ich mir dann da rein. Dann initialisiert die sich, das wäre aus meiner Sicht zum Beispiel völlig in Ordnung. Das hat vielleicht Dinge, die man da berücksichtigen muss, ich will auf gar keinen Fall den Eindruck vermitteln, als wäre das trivial. Wenig in der Softwareentwicklung ist trivial. Aber nichtsdestotrotz ist das halt etwas, was durchaus ein praktikabler Weg sein kann, wenn ich ihn denn möchte.

Eberhard: Das Einbetten von einer solchen Angular-App, wäre meine Vermutung, würde ja dazu führen, dass ich dann in der Seite, in der ich gerade bin, eben nicht zum Beispiel eine andere Angular-Version benutzen kann. Ist das so?

Falk: Ich sehe das an der Stelle ein bisschen kritisch. Ich sehe das als sehr komplexe Komponente an, deshalb sehe ich das eher als kritisch.

Till: Ich würde da auch nicht zu tendieren.

Falk: Für mich würde das bedingen, dass dieses Angular Framework ein Teil der zentralen Asset-Komponente ist, die man zur Build-Zeit geladen hat, und es würde für mich bedingen, dass man ähnliche Interfaces auch schon bei sich benutzt. Weil, es ist an der Stelle halt eben schon so, dass wir eigentlich an solchen Stellen eher nicht Code dynamisch nachladen wollen, weil dieser Code dann wieder zur Laufzeit geladen wird. Wir würden dann im Prinzip das gleiche Spielchen spielen, wie wir das bei den Single Page Applications gerade negativ benahmt haben.

Till: So wie es eben schon war, ich finde es diskutierbar und Falk findet es undiskutierbar. Das ist halt einfach wirklich eine Abwägungsfrage, das ist auf gar keinen Fall für mich erste Wahl.

Falk: Bei CSS finde ich das aber eigentlich ganz spannend: CSS ist eigentlich häufiger das, was man auf jeden Fall braucht. JavaScript kann dabei sein oder nicht, das ist aber eher optional. CSS ist eigentlich immer irgendwie ein zwingender Bestandteil: Die Komponenten, die ich nachlade, müssen auch irgendwie aussehen. Da ist es eigentlich ganz interessant, dass die Frontend-Entwicklergemeinde eigentlich das immer schon richtig gemacht hat. Die hat nämlich versucht, Komponenten composable zu halten und unabhängig von den Textstylen und ähnlichen Geschichten. Da gibt es eigentlich relativ viele Wege, solche Elemente möglichst stabil, sozusagen, mit Aussehen zu befüttern.

Eberhard: Okay, mit CSS an der Stelle. Was kann ich denn noch machen?

Till: Also, ich habe jetzt rein über die Frontendaspekte geredet, das war ja auch eigentlich der Aufhänger, aber natürlich gibt es auch andere Möglichkeiten, dieses Link Replacement zu machen. Ich habe jetzt eben darüber geredet, dass wir das mit Ajax machen mit irgendeiner fancy Komponente, die wir überall benutzen, aber es gibt auch Technologien, die auch wieder uralt sind, ja, auch total unspannend, die das letzten Endes nicht im Applikationsserver machen, aber in so einer vorgelagerten Backend-Komponente. Das könnte zum Beispiel so etwas sein wie Server Side Includes, ein uraltes Konzept. Das diente früher dazu, auf Webservern in eine statische Seite den Inhalt einer anderen statischen Seite zu inkludieren. Das reicht uns hier an der Stelle offensichtlich nicht, weil wir eben natürlich nicht einfach nur statische Inhalte inkludieren wollen. Es gibt aber eben so etwas wie Remote Server Side Includes, wo ich dann eben einfach, anstatt dass ich da einen Dateinamen hinschreibe, letzen Endes einen URI hinschreibe und dieser Webserver oder Reverse Proxycache - oder wie wir den auch immer nennen wollen - da letzten Endes hingeht und diese Referenz auflöst, genau wie wir es eben im Frontend getan haben, und dann anstelle der Referenz den Inhalt der Rückgabe einbettet. Also Server Side Includes wäre der eine Name dafür, Edge Side Includes ist halt ein anderer Standard dafür. Server Side Includes kommen so aus der Webserver-Ecke, Edge Side Includes kommen mehr so aus der Reverse-Proxy-CDN-Ecke, es ist aber konzeptionell eigentlich das Gleiche: Ich ersetze einen Link in meinem Backend durch den Inhalt seiner Rückgabe. Und das bedingt genau die gleichen Probleme wie eben: Wenn der Rückgabewert nicht ordentlich gestylt ist, dann habe ich hier ein Problem. Das Schöne ist dabei, wenn ich das für die eine Sache beantwortet habe, zum Beispiel für client-seitige Transklusion, dann kann ich genau dieselben Antworten auch für die backend-seitige Transklusion benutzen, weil es halt wirklich genau gleich ist, eigentlich.

Falk: Was man sich hier so ein bisschen vor Augen halten muss ist, dass wir bei Self Contained Systems ja auch über Verantwortung reden und wir hier die Verantwortung für die Transklusion in eine Infrastrukturkomponente setzen. Das heißt, wir verschieben die tendenziell zwischen die Self Contained Systems oder unter die Self Contained Systems oder wo man das auch immer in seiner Layer-Architektur hinzaubern möchte. Das heißt, wir haben an der Stelle ein bisschen weniger Kontrolle und wir sind ein bisschen mehr darauf angewiesen, dass die Leute, von denen wir die Inhalte beziehen, ihren Job richtig machen. Weil ein Teil für Transklusion, der häufig dann vergessen wird, ist, dass man einen Edge Side Include oder einem Server Side Include auch ein Fallback mitgeben kann. Das heißt, wenn dieser Service mal nicht erreichbar ist, und ich diese Inhalte nicht beziehen kann, wäre es schon sinnvoll, wenn ich an der Stelle auch einen sinnvollen Inhalt reingebe.

Eberhard: Das wäre ja bei dem, wenn ich so Link-Replacement mache, da hätte ich halt den Link immer noch. Das heißt, wenn da das Backend-System nicht funktioniert oder irgendwas…

Till: Die Frage, ob das aus Styling-Aspekten dann das ist, was du da willst, weil letzten Endes ist da der Fallback schon natürlicherweise da, das ist halt das Nette daran.

Eberhard: Ich hab da übrigens eine Frage noch, sozusagen zu einem technischen Detail: Wie ist das denn, wenn ich jetzt ein httpd habe, also ein Apache oder ein nginx oder einen IIS oder so was: Die können das alle mit ihren Server Side Includes?

Falk: Genau, nginx ist bei Server Side Includes, Apache braucht, glaube ich, einen Varnish oder ähnliches, da bin ich mir, ehrlich gesagt, gerade nicht ganz sicher.

Till: Ich weiß jetzt nicht, ob Apache wirklich Remote Server Side Includes kann. Server Side Includes, die klassischen, kann es auf jeden Fall. Aber ob es Remote Server Side Includes ist, weiß ich nicht, ich habe schon ewig kein Apache Projekt mehr gemacht. Nginx kann das auf jeden Fall, wir haben eine sehr große Self Contained Systems-Architektur beide gesehen, die sehr, sehr stark darauf setzt, und das funktioniert auch, soweit ich das zumindest mitbekommen habe, ganz gut. Das ist auf jeden Fall eine alte Technologie, alle Leute lachen sich wieder kaputt: “Sind das nicht IFrames für Arme? blablabla.” Hab ich alles schon gehört. Aber das ist halt eine Option, die einfach da ist und die man einfach ziehen kann.

Eine spannende Frage dabei, ich weiß nicht, ob du die jetzt gestellt hättest, ist: Wann nimmt man denn was? Wir haben jetzt hier das alles aufgezählt, und wann ich einen Link benutze und wann ich etwas inkludieren muss, das ist offensichtlich eine fachliche Anforderung. Wenn jemand unterhalb der Kundendetails die Vertragsdinge einfach sehen will, dann reicht der Link halt einfach aus fachlichen Aspekten schon nicht. Da brauche ich nicht großartig drauf einzugehen. Aber wann nehme ich denn jetzt ESI, SSI, also diesen backend-seitigen Ansatz, und wann mache ich es im Frontend? Das ist halt eine spannende Frage. Ich habe mal dazu tendiert, das so zu formulieren, dass ich eigentlich fast gar keinen Grund sehe, es im Backend zu machen. Dann wurde ich dann durch die Community eines besseren belehrt, das stimmt auch, weil es eben Aspekte gibt wie Search Engine Optimisation, die eben einfach darauf basieren, dass Inhalte in dem direkt vom Server retounierten Inhalt drin sind. Wenn ich Sachen gut cachen kann, also zum Beispiel, wenn es um die Frage geht: Wie inkludiere ich die Navigationsinhalte, die Hauptnavigationsinhalte, dann wären für mich auch potentiell solche Sachen wie SSI, Remote SSI oder ESI eine Option, weil, ich möchte ja nicht die Seite laden und dann kommt die Hauptnavigation erst nach 500 ms, sondern man erwartet einfach, dass die schon von vorneherein da ist.

Falk: Was für mich hier ganz wichtig ist in der Frontend-Integration, ist, wenn wir darüber reden, dass wir Links auflösen, über JavaScript, über Ajax oder ähnliches, dann reden wir davon, dass wir grundsätzlich irgendwo in diesem zentralen Konzept zur Build-Zeit schon wussten, was denn da kommen kann. Ich muss diese Information aus CSS, das JavaScript, das Behavior muss ich eigentlich schon haben. Außer ich gehe wieder in die Richtung, dass ich asynchron JavaScript mache. Aber grundsätzlich, gerade bei CSS, ist es in der Regel so, dass man so was dann gerne schon haben möchte.

Bei der Integration von SSI ist es halt eben so, dass das Laufzeit-Transklusion ist, bei der ich nicht zwingend wissen muss, was da so kommt, und das entscheide ich auch nicht in der Vertikalen. Das heißt, wenn eine Vertikale neue Inhalte injekten möchte, sozusagen, das ist halt eher ein Push-Prinzip: Die schieben mir neue Inhalte via Server Side Include unter, dann kann ich mich dagegen auch gar nicht wehren. Also, ich kann jetzt nicht in meiner Vertikalen sagen, im Applikationscode: Okay, diese Links laden wir nicht mehr nach, sondern das sind Informationen, die müssen immer up-to-date sein. Also zum Beispiel, wenn wir eine große E-Commerce-Plattform haben, die ihren Produktkatalog in der Hauptnavigation traversierbar macht, dann gibt es eine Vertikale, die hat ein sehr, sehr starkes Interesse, dass da die Inhalte drin sind: Dass nicht auf alte Produkte verlinkt wird, dass nicht noch in der einen Vertikale noch irgendwie für Winterartikel geworben wird, obwohl wir schon Sommer haben. Das sind so klassischerweise solche Inhalte, wo eine Vertikale die Verantwortung dafür hat, dass in allen anderen Vertikalen immer die richtigen Inhalte da sind. Und da reden wir sehr, sehr stark davon, dass wir so ein Push-Prinzip brauchen, wie das Server Side Includes oder Edge Side Includes anbieten. Weil bei diesen Link-Transklusionen reden wir eigentlich eher immer von einem Pull-Prinzip: Ich hole mir die Inhalte und stelle die dann entsprechend nach.

Eberhard: Wenn ich jetzt sagen würde, okay, ich baue dieses Ding, was halt irgendwie diese Hauptnavigation erzeugt, dann habe ich es, ehrlich gesagt, noch nicht ganz verstanden. Weil für mich sieht es eigentlich danach aus, als wäre jetzt nur die Frage, wie ich mir die Inhalte hole. Also, entweder ich mache es halt auf dem Client mit JavaScript-Code oder ich mache es halt auf dem Server mit Server Side oder Edge Side Includes. So oder so wäre es ja so, dass diese Komponenten, no matter what, immer die aktuelle Version laden.

Falk: Ja, aber eben in der Regel dann halt, da der Schnittstellenkontrakt sich zur Laufzeit nicht ändert. Bei der Transklusion ist das häufig eher so, dass ich das zumindest auch in der Applikation nicht mehr mitentscheiden kann, ob ich das gerade will oder nicht. Also, bei Transklusion ist die Entscheidung der Applikation schon abgegeben an die Infrastruktur. Das heißt, ab da entscheidet wirklich der ausliefernde Dienst, ob ich das noch mitnehme oder nicht. Und das ist halt eben bei der Link-Transklusion ein anderer, da entscheide ich halt in der Applikation, ob ich was mit dem Inhalt anfangen kann. Ich kann den ja gar nicht mehr verwerfen.

Till: Du hast die Möglichkeit, Code selber da reinzuschieben, ne? Du bist ja kein…du musst ja nicht magisch einfach jeden Link ersetzen. Ich weiß nicht, ob es wirklich viele Beispiele gibt, wo das jemand macht. Aber du könntest eben ganz explizit sagen, jetzt entscheide ich mich hier an der Stelle, um auf Falks Beispiel zurückzukommen, jetzt entscheide ich mich an der Stelle…keine Ahnung, ich bin im Checkout-Prozess, ganz explizit dafür, dann doch die alten Winterinhalte anzuzeigen und nicht die aktuelle Sommermode. Und das könnte ggf. sinnvoll sein. Also du hast einfach einen größeren Hebel, wenn du client-seitig inkludierst, ich glaube, für die meisten unserer Kunden ist die Unterscheidung nicht…

Eberhard: Ist das tatsächlich so? Weil, ich hätte jetzt gedacht, dass ich, also wenn wir jetzt bei dem Beispiel bleiben, der Checkout-Prozess würde eine HTML-Seite erzeugen, in dem Includes drin sind, in dem Edge Side oder Server Side Includes Fall, und das könnte er ja auch einfach nicht tun oder da eine andere URL reintun.

Till: Ja, aber dann eben nicht mit JavaScript-Code im Client, dann müsstest du da halt einfach anderes HTML ausliefern. Ich würde Falk da an der Stelle auch ein bisschen widersprechen. Die Entscheidung ist ja auch nicht so wichtig. Was aber elegant ist, das könnte man vielleicht nochmal sagen, die Frage ist ja: Wer wartet eigentlich? Und mein Argument, warum man prinzipiell den Client lieber integrieren lassen sollte und nicht das Backend, ist halt einfach, wenn du im Client integrierst, dann lieferst du das, was relevant ist, den Inhalt, zuallererst aus, und dann lädst du - keine Ahnung - den Warenkorb nach. Wenn du das auf dem Backend machst, wenn du Edge Side Includes machst oder Server Side Includes, dann wartet halt der Proxy Server und kann mit der relevanten Antwort auch dann erst rausrücken, wenn er seine ganzen Inhalte im Backend zusammengesucht hat. Und das ist halt ein riesiger Unterschied. Und es ist einfach sehr elegant, wenn man dem Client diese Warte-Operation überlassen kann. Das ist halt auch, völlig unabhängig von der jeweils eingesetzten Technologie, heutzutage wirklich schon ganz häufig so, dass man eben einfach versucht, die Hauptinhalte, die Primärinhalte, wirklich auch superschnell zu transportieren und dann eben den ganzen Randkram, wenn man so will, Zusatzkomponenten dann etwas später nachlädt.

Eberhard: Damit ich die Seite, zumindest in einer groben Version, möglichst schnell sehe. Das bedeutet, also, was wir jetzt ja diskutiert haben, Links, ich würde sagen, eine Webanwendung ohne Links zu bauen, ist sportlich und wahrscheinlich nicht möglich…

Till: Formulare gehören da übrigens auch dazu. Also ich würde es vielleicht nicht unbedingt empfehlen, aber auch Formulare können Inhalte zwischen unterschiedlichen Systemen hin- und herschicken. Das induziert natürlich Probleme, deswegen - wenn es geht - sollte man es nicht tun, aber es ist aus meiner Sicht konzeptionell absolut vergleichbar.

Falk: Was wir aber hier noch ganz kurz festhalten müssen, ist, wir haben ja hier eben schon mal die verschiedenen Konzepte besprochen, das sind alles Transklusionskonzepte für dynamische Daten, ne? Wir reden hier immer von wirklich den Inhalten aus anderen Vertikalen, die wir eben einbetten wollen.

Eberhard: Ok, wir würden also in einer Webanwendung typischerweise Links haben. Wir hatten jetzt über IFrames gesprochen, das haben wir jetzt gerade nicht besprochen, das heißt, wäre eure Erwartungshaltung, dass wir IFrames nur in Ausnahmefällen nutzen, wäre das so oder wie würdet ihr das sehen?

Till: Wenn man sie einsetzen will, dann sollte man sich auf jeden Fall gut damit auseinandergesetzt haben. Also, es ist nicht so, dass es einfach irgendwie technisch gesehen die einfachste Lösung ist, sondern auch da muss man Gehirnschmalz reinstecken. Ich kenne das aus der Realität relativ wenig, muss ich ehrlich sagen, also die anderen beiden Ansätze - ESI und Ajax Replacements - sind irgendwie bei mir deutlich, also in meinem Projektalltag irgendwie präsenter, ich möchte halt einfach nur darauf hinweisen, dass es eine Option ist, die auch gar nicht mal… also, die auch wirklich echte Vorteile hat, die wirklich auch an vielen Stellen interessant sind.

Eberhard: Ok, das heißt, die Erwartungshaltung wäre, dass wir in einem typischen Projekt eben sowohl über Ajax-Sachen Link-Replacement betreiben, wie auch über ESIs oder über SSIs oder würde man sich für genau eins entscheiden?

Falk: Ich glaub, dass das eigentlich so ist, dass man die alle kennen und alle in Betracht ziehen muss, weil das sehr, sehr stark von der Anforderung abhängt, die man gerade wirklich bei der eigentlichen Integrationskomponente vornehmen möchte, welche da die richtige Wahl ist. Ich glaube auch, dass man sehr stark diese Dinge kombinieren kann und sollte. Also, man muss sich nicht in der Makroarchitektur grundsätzlich für ein Transklusionskonzept entscheiden, sondern man muss sich eigentlich bei der einzelnen Komponente entscheiden, welche Rolle da wichtig ist. Zum Beispiel, dieses Konzept auch: Ich entscheide, wann ich das nachlade. Auf manchen Seiten ist es vielleicht sehr, sehr wichtig, eine Komponente schon immer in diesem kritischen Pfad einzublenden, dass also quasi der Server immer schon entscheidet, dass diese Komponente gerendert wird, in einer anderen Vertikale ist das aber vielleicht eher ein optionaler Inhalt, der später nachgeladen werden darf. Ne, also auch da muss man eigentlich überlegen, dass man Inhalte auch auf verschiedene Arten transkludieren darf.

Eberhard: Ok, gut. Wir würden halt wahrscheinlich mehrere von diesen Ansätzen sehen. Iframes vielleicht etwas weniger, aber die anderen Ansätze werden wir wahrscheinlich alle sehen, wobei es wahrscheinlich nicht sinnvoll ist, dass man ESIs und SSIs kombiniert.

Till: Oder auch wenn man sich halt über irgendeine Art unterhält, wie man dann z.B. mit den Assets umgeht. Das wäre jetzt das, wo wir, glaube ich, als nächstes drauf kommen, so auf die statischen Inhalte, die, darüber haben wir ja gerade schon geredet, die müssen einfach vorhanden sein. Da muss man sich für einen Ansatz entscheiden. Natürlich möchte ich auch keinem ans Herz legen, dass er dann für Link-Replacement mit ESI fünf unterschiedliche Arten und Weisen hat, wie man dann letzten Endes an das Styling oder an irgendwelches Verhalten dieser Komponenten kommt, ja? Das will man nicht, normalerweise. Es kann sein, dass man das später machen muss, weil einfach die Systemlandschaft wächst, meinetwegen, das ist halt so, aber am Anfang würde ich das auf gar keinen Fall jemandem empfehlen, da mehr als nur eine Variante zu verwenden.

Eberhard: Das wäre jetzt aber genau die Frage. Also, irgendwie brauchen wir jetzt vermutlich gemeinsame Assets, ich vermute mal, das wäre so etwas wie…ja, was gehört dazu? CSS, irgendwelche Images…

Falk: Fonts, ganz klassisch JavaScript, aber eben in der Tat auch das Verhalten von Komponenten.

Eberhard: Da hatten wir ja jetzt grade eben diskutiert, dass eigentlich es nicht so super schlau ist, Code nachzuladen.

Falk: Ich glaube, dass wir grundsätzlich… Also anders: Es gibt die Anforderung, erstmal grob, - die hast du auch eigentlich so schön reingeworfen - wir wollen ja irgendwie schon, dass die Sachen gleich aussehen. Wir reden aber in der Regel nicht darüber, wie hoch da die Toleranz ist, dass Dinge auch für Momente unterschiedlich aussehen sollen. Also, wir reden nicht darüber, wann sie quasi gleich aussehen sollen. Und da muss man im Prinzip, glaube ich, sich auch aussuchen, was man gerne tun möchte, damit die Anwendung gleich aussieht, also welches Integrationskonzept man nimmt. Man hat im Prinzip einerseits die Wahl eben zu sagen, man nimmt eine zentrale Kernbibliothek, die einem all diese Dinge liefert, und baut die zur Build-Zeit ein, kompiliert die mit in diese Vertikale ein und nimmt die quasi mit in die Verantwortung und jede Vertikale macht das so. Das führt aber eben dazu, dass rein theoretisch, da Versionsunterschiede erlaubt sind zwischen diesen Vertikalen, das heißt, das ist üblicherweise so, gerade in der produktiven Entwicklung, dass in der Design-Abteilung entschieden wird, wir möchten jetzt gerne, dass ein neues Logo ausgespielt wird. Oder wir möchten gerne, dass Knöpfe jetzt runde Ecken haben anstatt eckige oder Farben ausgetauscht werden. Dann kann es passieren, dass einzelne Vertikalen zeitlich gesehen nach anderen Vertikalen dieser Bibliothek anziehen und entsprechend auch noch, während sie noch die alte Bibliothek haben, noch die alten Werte anzeigen. Also, Versionsunterschiede können erlaubt sein. Wenn das nicht der Fall ist, muss man sich da ein anderes Konzept überlegen und da kann man halt eben zum Beispiel auch mit Transklusion arbeiten. Dann kann man halt eben sagen: Das zentrale Assets-Projekt liefert immer ein Transklusions-Snippet an, das die aktuellste Version mitliefert. Und dann ziehen alle Versionen, alle Vertikalen sozusagen, immer die aktuellste Version an, bringt aber eben ganz, ganz drastisch eigene Probleme mit sich.

Till: Genau, es ist ja halt einfach ein Reflex, den wir häufig gesehen haben, dass man eben von einem sehr krassen Sonderfall ausgeht: Ich nehme immer das Weihnachts-Layout, wir haben ja gerade auch Weihnachtszeit, dann muss halt auf das Logo oben die Nikolausmütze drauf. Und daraus ergeben sich häufig die Entscheidungen dafür, wie man diese Assets integriert. Also zu sagen: Hey, ich will ja am 1.12.2016 um genau 9 Uhr in all meinen Systemen - Falk sagt jetzt immer Vertikalen, ich tendiere da auch zu, aber wir wollen ja eigentlich über Self Contained Systems reden - also in all meinen Systemen genau zum gleichen Zeitpunkt die Nikolausmütze oben auf das Logo tun, deswegen müssen sie offensichtlich alle das gleiche CSS inkludieren. Also, das ist ja etwas, das man häufig irgendwie so hört, wenn einfach alle das gleiche CSS inkludieren und alle das gleiche JavaScript inkludieren, was so Link Replacement macht, dann habe ich ja offensichtlich kein Problem, das stimmt halt so nicht. Sondern das, was wir am Anfang gesagt haben, über Bibliotheken und die Einsetzbarkeit von der selben Bibliothek in unterschiedlichen Versionen und in unterschiedlichen Vertikalen, das gilt auch für Frontend-Bibliotheken. Und sowas wie die Assets, die CSS-Snippets, das JavaScript, was ich sharen möchte, oder Bilder und Fonts, das sind Bibliotheken. Und wenn wir eine Bibliothek im Backend mit Recht irgendwie managen, und versuchen mit den Versionen umzugehen, mit Abhängigkeiten umzugehen, dann sollten wir genau dasselbe auch für Frontend-Bibliotheken tun. Genau dieselben Dinge, die für Backend-Bibliotheken gelten, gelten aus meiner Sicht eben auch fürs Frontend.

Eberhard: Gut, also das heißt, ich würde jetzt eine Bibliothek definieren, in der die Assets drin sind, das wären halt CSS, Fonts usw. Ich habe jetzt noch nicht verstanden, wie ich dann überhaupt dafür sorgen kann - das ist ja etwas, was ich offensichtlich dann reinbaue in mein System - ich habe noch nicht verstanden, wie ich denn überhaupt in die Situation kommen kann, dass ich eben diese Nikolausmütze plötzlich um 9 Uhr in alle Projekte irgendwie reintue. Also, dazu müsste ich ja jetzt alle Projekte genau um 9 Uhr neu bauen, neu deployen usw., das ist ja unrealistisch.

Till: Wie schaltest du denn in all deinen Backend-Systemen, in deinem eCommerce-System um 9 Uhr die Kampagne live? Also, Kampagne ist ja etwas, dafür fühlen sich Backend-Leute verantwortlich, ja, was machen wir dann? Wir erfinden das Konzept von Feature Toggles, zum Beispiel, vielleicht. Das heißt: Warum sollte ich, ne, da käme ja auch keiner auf die Idee, nur weil es jetzt die Kampagne gibt ‘Skimützen für 13.99 €’ mit irgendwelchen Auswirkungen überall, kommt doch auch keiner auf die Idee zu sagen: Hey, wir deployen alle unsere Systeme, um am 1.12. um 9 Uhr mit dem neuen Stand. Sondern dann baust du halt ein Feature Toggle ein, testest das ordentlich vorher, jeder in seiner eigenen Verantwortung. Genau, das sind die Prinzipien, auf die wir alle so stehen, jeder baut das ein, jeder baut die Nikolausmütze ein, testet das bei sich schon irgendwann im November, und dann schalte ich halt um 9 Uhr das Feature-Toggle live, was einfach dafür sorgt, dass ich von dem alten in das neue gehe.

Falk: Aber das ist nicht das, was wir sehen. Das ist, glaube ich, auch ein bisschen das, wo Eberhard dann hinwill. Was wir im Moment eigentlich klassischerweise sehen, ist, dass die Leute eher die Konzepte benutzen, die wir gerade in der Link-Transklusion, oder die wir gerade in der Tranklusion erklärt haben. Dass die eher versuchen, das möglichst weit nach vorne zeitlich zu schieben in den Stack, und das heißt, wir sehen im Moment relativ häufig, dass die Leute Referenzen auf Script-Tags und Link-Tags in Transklusions-Snippets für SSIs und ESIs stecken. Das heißt im Prinzip, wenn ein Asset Release erzeugt wird, schieben wir ganz aktiv über die Infrastrukturkomponente nginx, Varnish, was auch immer, schieben wir unsere neuen Referenzen auf die Link-Tags und auf die wirklichen Dateien in die Anwendung hinein, und erzeugen dann quasi das Release um 9 Uhr für die neuen Assets oder schalten das scharf, und erzeugen damit in jedem neu eingehenden Request in den einzelnen Services dann Referenzen auf die neuesten, geupdateten Assets.

Till: Das ist eine sehr gute Antwort, wenn ich nur das Problem der Nikolausmütze hätte. Dann kann ich das machen. Dann ändere ich einfach um 9 Uhr meine Assets, aber wenn du halt irgendwie versuchst, an den Assets - also ich war mal in so einem Projekt - und wenn du dann eben hingehst und versuchst, an diesem zentralen Asset-Projekt irgendetwas zu machen, dann musst du dich eben sehr gut auskennen, weil du eben ja eigentlich gar nicht abschätzen kannst, was die Auswirkungen deiner Änderungen sind. Du schiebst anderen Vertikalen, wenn du in diesem Asset-Team bist, anderen Systemen plötzlich Dinge unter, die sie vorher noch nie gesehen haben. Das solltest du dann sehr verantwortungsbewusst tun. Es ist nicht so, als ginge das überhaupt nicht. Ich glaube halt, dass kann man vielleicht in so 'nem B2C-Kontext auch diskutieren, dass man das tatsächlich braucht. Aber gerade für internere Systeme, die einen interneren Charakter haben, oder B2B, würde ich halt von so etwas immer Abstand nehmen, weil das einfach sehr, sehr viel Intelligenz erfordert, die man sich eigentlich dadurch sparen kann, dass man einfach akzeptiert, dass unterschiedliche Vertikalen Assets in unterschiedlichen Versionen verwenden und man dann letzten Endes einfach die Probleme, die sich daraus ergeben, über andere Mechanismen, wie zum Beispiel Feature Toggles, adressiert.

Falk: Ein ganz kurzer negativer Aspekt, den wir eigentlich bis jetzt nicht erwähnt haben, zu diesem ESI- und SSI-Ansatz, ist halt eben auch, dass in der… also das ist gerade auch für die technischen Zuhörer wirklich vielleicht auch interessant, man an eine Sache meistens nicht denkt, man hat in der lokalen Entwicklung dann auf einmal den Zwang, das nachzuturnen, was man in Produktion macht. Man muss auf einmal lokal eigentlich auch ein nginx starten und SSIs richtig konfiguriert haben, damit ich die Assets aufgelöst bekomme. Das ist erstaunlich komplex und führt erstaunlich häufig dazu, dass die Ramp-Up-Phase für neue Entwickler unglaublich lang und schwierig wird.

Eberhard: Gut. Dann fällt mir eigentlich als abschließende Frage nur ein - das sind alles 'ne Menge interessanter Konzepte und die sind sicherlich sehr hilfreich - wie fange ich denn jetzt tatsächlich an? Wenn ich jetzt sagen will: Ok, ich will halt mein System genauso Frontend-integrieren, wie wir das jetzt die ganze Zeit diskutiert haben, was mache ich jetzt konkret?

Falk: Meiner Meinung nach sollte man… Also das, worüber man sich zuerst Gedanken machen muss, ist, glaube ich, wirklich der statische Anteil, also die Basis, nämlich dass ich gerne möchte, dass die Services, die gleich aussehen sollen, auch die gleichen Dinge teilen dürfen. Das heißt, wenn wir das zur Build-Zeit machen wollen, muss es irgendwo ein zentrales Repository geben, das Releases erzeugt. Also, ich muss eine Frontend-Bibliothek haben, die analog zum Beispiel zu Bootstrap oder ähnlichem - das heißt jetzt nicht, dass man dieses Bootstrap nehmen muss, man kann das auch sehr, sehr gut selber erzeugen - aber wenn, je nachdem, wieviel Arbeit man da hineinstecken mag, kann man auch einfach das vorgefertigte Bootstrap nehmen, das customizen und released das in Version auf zum Beispiel in CDN, also auf eine zentrale Plattform, die dafür sehr, sehr stark geeignet ist, eben das auch gut auszuliefern, was man da so an statischen Assets hat.

Till: Und eben auch ganz wichtig: Man released das unter seiner Version. Wir kennen das ja vielleicht, wenn wir zum Beispiel irgendwie JQuery oder Bootstrap aus dem Netz über einen CDN-Dienst verwenden wollen, dann kann man meinetwegen auch vielleicht irgendwie die latest-Variante immer nehmen, aber typischerweise verwendet man dann einen Link, wo diese Version drinsteht, und das ist eigentlich schon das, was Falk mit Build-Zeit meinte. Also wenn zum Beispiel mein Team, was verantwortlich ist für dieses Look & Feel, wir nennen es mal Asset-Team, wenn dieses Team eben eine neue Version jetzt mit Weihnachtsmütze gebaut hat, dann schiebt sie die halt letzten Endes unter eine andere URI. Da geht sie hin und sagt: Wir nehmen Bootstrap, wir darauf bauen auf und wir releasen die Version 1.0. Und dann gehst du halt zu deinen Teams und sagst: Liebe Teams, ihr könnt das jetzt benutzen, müsst ihr nicht, solltet ihr aber vielleicht. Und das bedeutet dann, dass die Teams in irgendeiner Art diesen Link anpassen müssen, was aus meiner Sicht wirklich super wichtig ist, das tun sie in ihrer eigenen Verantwortung. Das machen sie dann, wenn sie das für richtig halten. Und das ist halt etwas, ja, das würde ich halt wirklich jedem empfehlen. Wenn man jetzt wirklich bei Null starten sollte, dann würde ich wirklich empfehlen, man wählt diesen CDN-Ansatz - man muss das ja nicht ins freie Web schieben - man kann das halt einfach in irgendeinen Webserver legen und das dann CDN nennen oder nicht, das ist egal. Man legt es einfach in irgendeinen Webserver unter seiner Version und alle anderen binden das einfach dadurch ein, dass sie genau diese Datei referenzieren, ich erzwinge aber eben nicht, dass es immer die aktuellste ist, sondern ich lasse auch alte Versionen da auch potentiell unendlich lange liegen.

Falk: Was halt schon Sinn macht, ist halt, sich schon so etwas wie ein CDN mal anzugucken, zumindest, was der technisch anbietet, weil man sich zumindest über Caching von solchen Sachen Gedanken machen muss. Man muss sich darüber Gedanken machen, dass man CORS-Header setzt, weil man gerade für Font-Loading im JavaScript-Bereich diese Header braucht, sonst werden diese Fonts nicht benutzt. Also solche Geschichten muss man sich da mal angucken, deswegen ist das ein ganz guter…

Eberhard: CORS?

Falk: Cross-Origin Resource Sharing ist das. Normalerweise ist man eigentlich an die eigene Domäne gebunden, wenn man dynamische Inhalte nachlädt, und das erlaubt halt eben auch das Nachladen von einer fremden Domäne.

Till: Ich würde da wirklich auch einen Schritt zurückgehen! Falk ist sehr stark in diesem eCommerce/B2C-Denken verhaftet, glaube ich. Für die meisten der Kunden, die ich so kenne, spielt das keine Rolle! Ich kann halt einfach alles letzten Endes unter derselben Domäne betreiben, hab diese ganzen Probleme nicht, lege es halt einfach in einen Webserver. Und dann kann ich halt im nächsten Schritt hingehen und mir mal überlegen: Hey, warum setzt denn der Webserver, obwohl sich die Datei ja gar nicht ändert, ja, wenn ich sie einmal unter Version 0.1.1 abgelegt habe, bleibt die Datei ja immer gleich. Das heißt, das erste, was ich intuitiv tun müsste, wäre, dass ich die entsprechenden HTTP-Header setze, dass der Browser, wenn er sie einmal geladen hat, sie nie wieder lädt, weil sie wird sich nicht mehr ändern. Und genau so etwas sollte man konfigurieren, muss man vielleicht in einem internen Szenario gar nicht tun (sollte man auch da tun, keine Frage), aber nichstdestotrotz ist das halt etwas… das ist eigentlich alles… wenn man eben Anforderungen hat, die wirklich hoch skalieren, dann werden auch solche Sachen kompliziert. Ich würde halt wirklich für den Einstieg empfehlen, das so einfach wie möglich zu machen, eben dieses zentrale Assets-Ding zu bauen, das Kompilat irgendwohin zu legen und allen Leuten zu sagen: Benutzt das und fertig.

Eberhard: Unterscheidet sich das jetzt signifikant von dem, wie ich normalerweise Webdesign und -entwicklung machen würde?

Falk: Genau das ist vielleicht das Geheimnis. Eigentlich empfehlen wir quasi, SCS so zu bauen, wie man normale Web-Monolithen gebaut hat, nur halt eben geteilt, dass man eben die anderen Self Contained Systems als andere Webseiten betrachtet, die man halt eben entsprechend verlinkt und…

Till: Du hast ja früher auch mal Google Maps eingebunden, auf deiner Homepage. Dafür ist das Web da! Da gibt es auch nichts, was wir neu erfinden müssen, sondern das ist etwas…Google Maps benutzt übrigens zur Inklusion IFrames unten drunter, hat vielleicht eine JavaScript-API. Aber fast alle echt fremden Inklusionen oder Transklusionen passieren über IFrames, nur so am Rande, das ist halt genau das, was das Web kann, weswegen wir das so lieben, weswegen wir das so machen wollen. Und wenn wir jetzt unfassbar viel Engineering-Power da reinstecken müssten, nur um irgendwie zwei Systeme voneinander zu trennen und sie vorne wieder zu integrieren, dann wär der Ansatz irgendwie Mist. Wenn das nicht einfach, also wenigstens im Kern einfach ist, wenn die Konzepte nicht einfach sind, dann machen wir potentiell da auch was falsch.

Eberhard: Das wäre für mich jetzt noch die Frage, also wir haben ja diskutiert, dass wir eben Integration machen können über Links oder Ajax oder sowas. Wir haben jetzt bei den ersten Schritten nur gesprochen über ein gemeinsames Asset…

Till: Das waren die statischen Inhalte, da könnte man vielleicht auch noch über sowas wie 'ne Hauptnavigation reden, man kann zum Beispiel eine Hauptnavigation einfach inkludieren in andere Systeme im extremsten Fall, indem man in das Paketmanagmentsystem der Wahl, welches das jetzt auch immer ist, einfach einen HTML-Schnippsel als Datei reinlegt, was einfach jeder da reinrendert. Das wäre eine der einfachsten Möglichkeiten, um zum Build-Zeitpunkt letzten Endes Inhalte zentral irgendwo definieren zu können und sie überall anders verwenden zu können.

Eberhard: Das wäre sozusagen so ähnlich wie ESIs, nur dass ich zum Build-Zeitpunkt HTML-Dateien da reintue.

Falk: Kommt aber dann halt eben auch mit dem kleinen Geschmäckle dazu, dass man halt eben rein theoretisch in verschiedenen Versionen eine Navigation hat. Dass rein theoretisch in der einen noch ein Link referenziert wird und in der anderen halt nicht mehr.

Till: Keiner verspricht irgendeine Silver Bullet, alle Ansätze haben irgendwelche Vor- und Nachteile, aber es muss - und da scheint mir wirklich an der Sache wichtig zu sein, das zu betonen - nur, weil das an der Stelle einfach ist, nur weil das an der Stelle Konzepte sind, die wir seit 20 Jahren…ach, was weiß ich wie lange kennen, muss das nicht unbedingt die falsche Antwort sein.

Falk: Ich glaube auch gerade, wenn man sich dann so Grundprinzipien zugrunde ruft wie ‘Cool URIs don’t change’, haben wir halt ein Prinzip, wo wir gerade in der Hauptnavigation sagen können: Naja gut, dann wird da halt noch eben ne Kategorie verlinkt, die wir eigentlich nicht mehr bewerben wollen, aber sie sollte ja noch erreichbar sein. Also, eigentlich können wir halt quasi eher so mit einem Deprecation Pattern dahin kommen, dass eben diese Navigationen umgestellt werden und danach erst die Links ausgeschaltet werden. Dann ist alles ok.

Eberhard: Aber das bedeutet, dass der Fokus aus eurer Sicht eher auf diesen Asset-Projekten und diesem Team liegen muss…

Till: Im ersten Schritt muss man das gerade machen.

Eberhard: Ja ok. Und dann würde man sich über ESIs oder Ajax oder was…

Till: Richtig. Und dann - oder meinetwegen auch parallel - wenn ich die Power dazu habe, im einfachsten Schritt kann ich halt auch einfach erstmal mit Links anfangen. Ja, also wenn es halt wirklich um das Bootstrapping geht, dann benutzt Links, wenn das nicht mehr reicht, dann benutzt meinetwegen Iframes, ja? Weil ich natürlich auch immer irgendwelche tollen Sachen gewinne, wenn ich das nächste etwas komplexere Konzept erreichen möchte, aber das muss ich halt, wenn ich wirklich von der grünen Wiese starte, auch überhaupt erstmal umsetzen, ne? Und dann ist es halt vielleicht echt sinnvoll, wenn man einfach erstmal den einfachen Standardkonzepten angibt, die einfach seit zig Jahren so existieren, und dann einfach dafür sorgt, dass man eben einfach mit der Zeit dann wächst.

Falk: Was wir uns vielleicht auch vergegenwärtigen müssen, ist, wie gesagt, Self Contained Systems: Wir tun das, um Systeme zu entkoppeln und jeder Schritt, den wir in Richtung Tranklusion gehen und auch in Transklusion über Infrastruktur gehen, gehen wir wieder einen Schritt zurück. Und das heißt, wir sollten diese Schritte nur tun, wenn die Notwendigkeit dafür da ist.

Eberhard: Genau. Gut. Also wäre eigentlich die Ansage: Fangt mit Links an, schaut, was ihr zusätzlich braucht on demand und ihr müsst euch halt um Assets kümmern, weil das eben…

Till: Das ist zwingend! Ohne geht es nicht. Man muss sich zum Beispiel auch um so ein Thema wie gemeinsamen Login kümmern. Das hat jetzt mit unserem Frontend-Thema vielleicht wenig zu tun, aber es gibt eben, wenn ich Dinge zerschneide, Dinge, die ich auf dieser Makroebene klären muss, und zum Beispiel ist der Login ja vielleicht noch etwas Frontend-verwandt, weil ich mich halt im Frontend einlogge. Ich kann mich nicht auf jedem System separat einloggen, sondern diese Konzepte müssen einfach vorher da sein, ich muss das irgenwie gelöst haben, ich muss genau da auch wieder adressieren, wie ich von dem einen Login-Verfahren irgendwann nochmal auf das andere wechseln kann und und und… Da gehört halt dieser Asset-Kram ganz, ganz zentral dazu.

Eberhard: Gut!

Falk: Eine Sache hätte ich vielleicht noch, das ist wirklich entscheidend. Der Till hat schon das Asset-Team eingeworfen, das sich um sowas pflegt. Worüber man sich da Gedanken machen muss, ist da definitiv ein Organigram sozusagen, wie denn eigentlich die Leute aus den einzelnen Services an diesen zentralen Assets mitarbeiten. Weil es halt in der Regel Bedarf gibt, an diesen Komponenten, und am Anfang sind die vielleicht auch nur in 'ner eigenen Vertikale oder in einem eigenen Service notwendig, ich möchte die aber gerne irgendwann anderen Services zur Verfügung stellen und spätestens da sollten die eigentlich in dieses zentrale Repository wechseln. Das heißt, ich muss mir an so einer Stelle halt schon dann auch initial klarmachen, dass alle Leute an diesem zentralen Repository mitarbeiten dürfen und sollen.

Eberhard: Gut. Dann würde ich sagen: Vielen Dank. Es war interessant und ja…viel Spaß noch. Bis bald!

Till: Tschüss!

Falk: Tschüss!