Laravel + React: REST, Inertia oder Next.js?

hallo und herzlich willkommen an einem sonnigen tag in unserem wunderschönen webcafé und hallo

lieber Kay schön dass du auch so spät am tag noch mit mir aufnehmen möchtest hallo felix ja freut mich auch dass wir es endlich geschafft haben uns hier zusammen zu finden ja wir haben heute ein cooles thema was mich in letzter zeit so ein bisschen beschäftigt hat wir wollen über die kombination von lara welt und reakt sprechen weil wir tatsächlich ja das thema auch in unseren live projekten hatten können aber natürlich nicht starten Kay bevor ich dir erzählt habe was für einen tollen tee ich heute dabei habe und natürlich interessiert mich auch was du mitgebracht hast so jetzt bin ich ganz neugierig felix erzähl doch mal also soll ich anfangen jetzt hast du schon

so vorgelegt jetzt muss es auch bringen ich habe von tee geschwendet den salzkaramell tee dabei und das war jetzt in den letzten wochen wirklich mein lieblings thema muss ich sagen also ganz tolles zeug und ich habe jetzt auch herausgefunden warum das so lecker ist ich habe mich auf die zutaten liste geguckt und da ist nicht nur ein mix aus schwarzem tee und räubers drin sondern da sind auch salzkaramell stücke drin die eben aus zucker unter anderem stehen sahne aus der normandie gesalzene butter ist da tatsächlich auch drin und dann ist in dem ganzen ding auch noch mehr salz aus gerundet nenne ich es mal ich weiß nicht ob man so ausspricht jedenfalls aus frankreich und die

kombination ist halt super das ist so ein karamelliger tee richtig lecker ja ich sag mal sahne und butter tun da ihren rest also richtig schön rund und weich ich habe mich da rein getan also so ein bisschen wie das jetzt beschrieben was klingt das wie so ein fancy milkshake in dem eigentlich nur zucker und sahne drin ist und dann so für das alibi so eine kleine kirsch irgendwo rein geraspelt genau so ja und in dem habe ich mich jetzt wirklich die letzten wochen gütlich getan und bin großer fange von was hast du uns mitgebracht ich weiß gar nicht wo ich anfangen soll hier der ganze tisch um mir ist aufgestellt mit dingen ich habe einen frischen tee der zu ostern eingetrudelt ist der

glückstee ich lese das hier mal ab der verspricht fein herb fröhlich und beflügelnd zu sein ayurvedische kräutermischung mit zimt hopfen und orangenschale der steht hier schon an und wartet auf meine verköstigung und dann habe ich meiner freundin gesagt das gleich aufnahme ist und die hat sie es natürlich nicht leben lassen mir hier auch einen cappuccino reinzureichen der mir jetzt die nötige energie gibt hier für die kommenden drei stunden sagen wir mal bei dem thema und das allerbeste ich nehme ja gerade wieder ab habe ich so ein kleines stückchen selbstgemachten käsekuchen von ostern den ich mir

gleich irgendwann heimlich reinstellen werde und dann hoffentlich weiter sprechen kann also ich weiß gar nicht wo ich anfangen soll und natürlich noch meine obligatorische teekanne ja schön ja du hast gesagt im vorgespräch dass du nicht ganz genau weiß ob wir genug themen haben jetzt für eine folge wenn wir das so scopen auf wirklich lara well und reakt dort ist vorgeschlagen ob wir das vielleicht sogar so ein bisschen allgemeiner halten mit back end und frontend und wie man das allgemein verknüpft und was für methoden es da gibt ich glaube aber dass wir jede menge zu besprechen haben auch wenn es nur um lara well und reakt geht und würde fast sagen wir steigen mal

ins thema ein die genese war ja eine ganz andere also die herleitung ist das ständig wenn wir ja neue projekte haben wir darüber debattieren wie denn jetzt die verbindung hergestellt wird ich will jetzt noch nicht zu weit rein und wir deswegen längst so eine diskussion gehabt haben und jetzt tatsächlich heute hatte ich wieder mit einem anderen kunden die diskussion darüber wie man denn idealerweise so eine verbindung herstellt und dann haben wir aufgeschrieben boah das ist ja ein total spannendes thema lass uns darüber reden dann hatte ich mich darauf vorbereitet irgendwie ist der fokus dann kleiner geworden nur auf

react und inertia also react inertia und lara well und jetzt ist der fokus wieder groß geworden weil es

ja wirklich ein thema ist was uns in der webentwicklung jeden tag beschäftigt nämlich wie lösen wir dieses dilemma was wir in der webentwicklung haben dass wir eigentlich zwei mindestens unterschiedliche bausteine haben die miteinander reden nämlich so dieses back end und frontend und da jetzt heute den richtigen scope zu finden wird glaube ich eine kleine herausforderung aber ich bin aufgestellt mit tee also ich kann hier auch drei stunden sitzen ja herrlich jetzt schon mal die erste frage ob man überhaupt zwei bausteine haben will die frage habe ich mir auf jeden fall auch aufgeschrieben wir haben jetzt lara well und reakt so ein bisschen

hier als gegeben hingeschmissen aber bevor wir da einsteigen vielleicht noch mal eben ganz grob den scope wir beschäftigen uns ja bei uns hauptsächlich mit dem thema web anwendung und das ist ja so ein bisschen anders als wenn wir webseiten machen weil wir zum beispiel wenig so themen haben wie seo oder bei uns

geht es viel darum dass die daten extrem konsistent sind und weniger dass die jetzt zum beispiel schnell geladen werden oder groß gecashed wird und deswegen glaube ich muss man schon ein bisschen unterscheiden zwischen web anwendungen und webseiten was sagst du dazu das ist mein allererster punkt weil logischerweise sich nicht aus der technologie die anwendung ergibt sondern umgekehrt die anwendung die technologie bestimmt und genau diese unterscheidung die ich mache zwischen webseite und web anwendung ist da ganz entscheidend um zu überlegen was jetzt was ist wobei ich da vielleicht ein bisschen andere

begriffsdefinitionen im kopf habe habe das mal versucht zu verklausulieren was ich verstehe unter webseite versus web anwendung ein bisschen übertragen das konzept von einer multi page application gegenüber einer single page application das sind so die beiden schlagwörter wobei single page application das ist ja so ein kampfwort oder eigentlich so ein marketing wort in der zwischenzeit das nutzen wir auch manchmal außerhalb von dem kontext in dem ich jetzt rede und was ich damit eigentlich meine ist ganz einfach wenn ich eine webseite besuche habe ich zu jeder zeit eine relation zwischen der url die ich eingebe und dem inhalt den ich sehe

also was ich damit meine ist wenn ich mal auf die tagesschau gehe dann bekomme ich auf der ersten seite eine liste aller artikel und wenn ich dann auf ein artikel draufklicke dann ändert sich die url da steht dann artikel gleich id irgendwas und dann bekomme ich auf dieser seite hauptsächlich zu 90 prozent alles angezeigt was mit diesem artikel zu tun hat

das ist für mich so eine klassische multi page application und das ist fundamental unterschiedlich von der ganzen denkweise her zu so einer single page application ich denke da zum beispiel an sowas wie google maps wo man so eine webseite aufmacht und dann passieren ganz viele dinge und ich kann mich da ruhig navigieren und fenster aufmachen und unterseiten und unterseiten

alles bleibt irgendwie schon auf der gleichen seite aber es passieren so viele dinge dass ich gar nicht mehr eindeutig eine relation herstellen kann zwischen was mache ich da jetzt gerade für eine aktion auf der seite und was ist in der url dargestellt

ich habe in der vorbereitung das würde ich noch unterbringen das hat mich total begeistert wir haben ja in der entwicklung in der technik für alles abkürzungen und ich bin über das muss ich ablesen

ht was konzept gestoßen das ist eine abkürzung für hypermedia as the engine of application state oh mein gott und das ist so ein konzept was im jahr 2000 von irgend so einem typen den ich jetzt schon vergessen habe entdeckt

aber das sagt im prinzip nichts anderes als das hypermedia die url repräsentiert den state der anwendung das bedeutet wenn ich mir eine seite angucke dann habe ich immer eine genaue relation zwischen dem was in der url steht und dem was auf der seite passiert und wenn ich was anderes machen möchte muss ich die url ändern und dann habe ich auch eine andere auswirkung während das bei einer single page application vielleicht nicht so ist

jetzt benutzen wir natürlich gerne so ein history api wo man dann trotzdem vernünftige und sprechende wells auch in einer web anwendung hat und jetzt nicht die ganze zeit irgendwie auf einer base url rum navigiert das hat ja andere vorteile auch dass man direkt lieblings machen kann und direkt irgendwo in der anwendung springen kann aber ich denke dir geht es eher so um das konzept und dass man so versteht was macht für dich den unterschied zwischen einer spa single page application web anwendung

web anwendung und dann eben einer klassischen content website aus genau weil die entscheidende frage die wir ja heute diskutieren ist wie bekommen wir die informationen zwischen dem frontend also dem bereich in dem der user sich rum bewegt und

und dinge macht versus dem back end hin wo die daten irgendwie verarbeitet werden und das geschieht mir viel zu häufig in unseren breitengraden auch bei den anwendungen die wir machen dass wir weil wir react benutzen ganz automatisch in diesem single page application gedanken sind und dann aber auch sowas wie klassische ressourcen sachen die wir mal abbilden eine user liste mit einem einzelnen user profil

eher über sowas wie einen internen state lösen als über die url wie man es macht weil das geht natürlich in single page applications auch man kann die urls manipulieren du hast es gerade gesagt aber sich nochmal darauf zu besinnen dass es ja eigentlich schon vom browser und von der terminologie her da ganz tolle konzepte für gibt das hilft auch um zu entscheiden wie man die informationen hin und her tauscht

ja und ich bin auf das thema überhaupt gekommen weil wir eine neue anwendung bauen wollen relativ komplexes ding und um das schon mal so ein bisschen zu spoilern wir verwenden eben gerne react im frontend rest api dazwischen lara will im backend

und egal wo man sucht man findet eigentlich immer verweise auf so geschichten wie nest jest und so weiter und so fort und dann frage ich mich natürlich ist das überhaupt das richtige was wir machen also ist das noch sinnvoll ist das noch state of the art und dann sind wir da relativ tief eingetaucht du bist sowieso schon tief drin ich habe mich nochmal explizit eingelesen

ist das wirklich jetzt das richtige modell und das wollen wir heute so ein bisschen klären so in welchen anwendungsfällen ist welches modell eigentlich ganz passend ich habe als erstes mal ChatGPT dazu gefragt also ich habe den völlig neutral gefragt so nach dem motto wenn ich jetzt eine web anwendung bauen würde also ich konzentriere mich jetzt wirklich auf web anwendungen und ich würde sagen

wir gehen immer mal wieder darauf ein wie man es bei webseiten machen würde aber der fokus ist schon so ein bisschen auf web anwendungen hier habe ich gefahrt wenn ich jetzt eine moderne web anwendung bauen würde und dann bin ich von irgendwelchen frameworks und so wie würde der es bauen ja und dann kam als erstes an und sagt ja ich würde next js benutzen also react quasi mit next und dann habe ich ihn gefragt ja aber irgendwie next ist ja so kein richtiges backend und würdest du denn damit auch datenbank zugrufe machen und so ich will jetzt nicht zu viel vorweg nehmen und dann sagt er vielleicht packst du

doch nest js im backend dazu und dann habe ich ihn gefragt ja aber wenn du jetzt nest und next hast dann hast du irgendwie zwei frameworks und überschneidet sich das nicht und ist das nicht ein tierischer overhead und so und dann sagt er ah ja wahrscheinlich wäre am besten wenn nest js und react router verdient und da sieht man schon so ein bisschen dran also je mehr informationen man ihm natürlich gibt desto präziser kann das vielleicht auch sagen aber selbst ChatGPT hatte ich das gefühl ist sich nicht so ganz sicher was ist jetzt das richtige wie kombiniert man es richtig und das hat mich eigentlich beruhigt weil es gibt scheinbar ganz viele antworten auf diese frage und

ja Kay die allererste frage für mich ist erstmal warum benutzen wir überhaupt react und warum nehmen wir nicht einfach laravel im backend wenn es das so gut gefällt machen damit die ganze datenaufbereitung machen ganz normale blade templates im frontend und vielleicht

reichern wir es noch an mit wenn du zum beispiel einen konfigurator hast oder sowas dass wir da eine react anwendung einfach einbinden als modul was spricht denn gegen blade habe ich heute auch wieder gesehen felix lass mich nicht starten also vielleicht fangen wir erst mal mit sachen an die meiner meinung nach blade unterscheidet von sowas wie

die einer react anwendung und auch da wieder als disclaimer man kann alles so bauen wie man das möchte aber so im klassischen modell ist ja blade template eine abstraktion von dem view teil im mvc modell und das bedeutet es ist wirklich nur dafür da um informationen darzustellen

das heißt es ist losgelöst von dem teil der die informationen ran schafft und das bedeutet insbesondere bei laravel die informationen die ich an die view komponente übergebe die definiere ich vorher im controller oder sonst irgendwo da sage ich gerne hier ich hätte gerne diese template datei

und übergebe diese variablen und dann mache ich die template datei auf und da ist davon aber nichts zu sehen weil die hängen nur lose beieinander das heißt im blade template muss ich jetzt raten welche variablen vorher übergeben wurden und hoffen dass die sich nicht ändern da haben zwar inzwischen die idees können dann so ein bisschen an die hand gehen aber dann muss ich wieder so auf externe tools verlassen

das ist eben so ein problem von es ist irgendwie so losgelöst und wenn ich dann ein bisschen interaktives blade haben möchte dann muss ich da irgendwo nochmal separat javascript mit einbauen und dann habe ich da ja auch irgend so eine art von state wenn sich mal so ein modal öffnet oder sowas also was diese klassischen mvc sicht gesprochen ist das total sauber getrennt aber es bildet nicht mehr moderne web anwendungen an wo eigentlich eine view nicht mehr einfach nur so ein statischer block von html ist der da ist oder nicht

sondern sehr dynamische bausteine und das ist mit blade eben sehr schwer nur abzubilden so nehme ich es auch weil es nicht so dynamisch ist es nicht so responsive und ich kriege keine vernünftige auto vervollständigung so dass ich so komfortabel entwickeln könnte wie das in projekt ist was aber ein riesen vorteil natürlich wäre ist dass ich nicht diese type mismatches oder so habe also alles was ich aus laravel liefer kommt direkt in blade an und ja man hat nur ein system man hat nur php genau also im front der dann natürlich noch ein bisschen html aber

man hat jetzt nicht diesen bruch das ist glaube ich auch so der größte nachteil an laravel und react dann dass man einerseits typescript hat wenn man es dann verwendet oder javascript und auf der anderen seite hat man php das heißt man hat zwei programmiersprachen die man eigentlich beherrschen muss bei uns klappt das gut aber ich könnte mir schon vorstellen dass auch zu verwirrungen führt und gerade für einsteiger natürlich auch schwierig ist dann mit zwei sprachen zu jonglieren

das ist ja der grund warum im laravel universum in letzter zeit live wire so populär geworden ist das versucht ja so ein bisschen die dynamischen ansätze und auch diese komponenten ansätze von den ganzen klassischen frontend javascript frameworks ins backend zu übertragen mit relativ gutem erfolg offensichtlich aber genau eben mit diesem gedanken von naja eigentlich wollen wir schon diese dynamik haben die

die so ein frontend framework mit sich bringt und gleichzeitig wollen wir aber auch den tech stack haben mit laravel mit dem wir uns auskennen also da sieht man schon dass da auch von dieser seite der bedarf besteht

sollen wir uns mal angucken was die zweite variante wäre das wäre die variante die wir bisher bevorzugt haben mit laravel im backend eine klassische rest api dazwischen und im frontend haben wir dann eine eigenständige react anwendung und was mich dazu noch interessiert neben vor und nachteilen von dem modell

ist packen wir das alles in einen repository oder machen wir mehrere repositories dass wir zum beispiel ein team haben was komplett nur im frontend repository arbeitet und eins was im backend repository arbeitet können wir vielleicht so ein bisschen hintereinander machen du kannst ja aussuchen mit was wir starten

ich mache vielleicht erst mal das kürzere von beiden nämlich diese unterteilung zwischen mono und multi repo und da habe ich bis jetzt noch kein argument gesehen um das multi repo zu machen

interessant also insbesondere so in dem scope in dem wir unterwegs sind und das ist es vielleicht auch wenn man da jetzt anfängt aus dem frontend ein eigenes repository zu machen und aus dem backend ein eigenes repository zu machen

dann macht die ganze sache nur unnötig kompliziert weil es ist ja selten so dass ich individuell im frontend irgendein feature entwickelt was keinerlei auswirkung aufs backend hat oder umgekehrt es ist ja immer so ein für und wieder

ich baue im frontend irgendein feature und brauche aber aus dem backend informationen oder irgendwelche postend punkte wo ich das manipulieren kann und dann herzugehen und zu sagen okay in dem einen repository mache ich jetzt die ui und

und modelliere das gegen so eine api die es aber gar nicht wirklich gibt und dann im backend da geht es noch ein bisschen besser da kann ich schon mal die endpunkte bereitstellen aber außer testen und nichts groß damit machen das erzeugt einfach sehr viel overhead

lieber beides in eins dann kann ich gleichzeitig als entwickler das sind ja unsere leute alle geschult in beiden technologien sowohl das backend bauen als dann auch gleich das frontend dazu und dann habe ich in einem feature in einem

merce request so das komplett paket und ich habe natürlich einen riesen vorteil dass ich nie in version mismatch ab also dass ich im frontend schon was committed habe gepusht habe und im backend bin ich vielleicht noch gar nicht hinterher gekommen die api entsprechend anzupassen

und dann bekomme ich natürlich fehler das kann ich mit so mono repo natürlich verhindern und ich meine auch dass wir beim starten von einem lokalen server und so etwas praktischer wenn ich nur ein repo habe dann muss ich glaube ich weniger befehle feuern um das ganze aufzurufen

genau das ist diese ganze tool chain die es so gibt ist alles darauf ausgelegt und was jetzt bei uns in den web sachen noch dazu kommt sind einfach so was wie automatische code generierungen die gibt es ja in der

zwischenzeit auch dass ich eben nicht im frontend die ganzen types und endpunkt und alles routen nachbauen muss die ich im backend habe sondern dann baue ich die im backend mit laravel drück auf

ein befehl so laravel wayfinder ist da so ein stichwort das generiert mir dann gleich typescript dateien mit den nötigen routen die es brauchen dann ist das ganze sehr dynamisch das geht schon auch nicht so gut wenn ich da in separaten repositories

unterwegs bin ja da muss ich noch mal eben reingehen Kay bei diesen wayfinder den hast du mir erzählt dass das eben genau das macht das ist ein großer nachteil von dem set das wir haben dass man in

javascript oder in typescript letztlich die interfaces noch mal baut und im php das gleiche auch noch mal hat das heißt man muss immer gucken dass die objekte gleich sind und dass ich immer das richtig erwarte

und jetzt hast du der wayfinder kann das quasi so handelt dass ich das nur in php definiere und dann habe ich die gleichen typen quasi im frontend auch in react verfügbar ich habe das aber nicht so verstanden dass das wirklich schon so funktioniert

für die typen funktioniert es noch nicht wofür es funktioniert ist für die controller endpunkte also dass ich weiß wie die routen heißen welche methoden es da gibt und so was es gibt allerdings also laravel

laravel ist ja ein riesen ökosystem tausende tools die das irgendwie abbilden auf verschiedene art und weise da gibt es welche die direkt laravel auslesen und daraus automatisch so types generieren gibt aber auch welche die sagen okay du hast eine restschnittstelle die lese ich einfach aus und generiere das daraus also mittel und wege gibt es da das ist jetzt alles was wir heute sagen nicht so dass das exklusiv nur für den

ein oder die andere route gilt aber es sind alles vorteile die man doch hat wenn man es zusammenlegt ja und wir schicken unseren disclaimer den wir jedes mal haben hinterher dass wir natürlich so aus unserer erfahrung jetzt sprechen können aber natürlich haben wir weder die zeit noch die kapazitäten jetzt jedes einzelne laravel plugin auszuprobieren

ich weiß gar nicht nur für wayfinder schon mal verwendet haben aber auch mit den ganzen anderen sachen also da werden ganz sicher jetzt hörer und hören kommen und sagen oh da gibt es aber doch dieses und warum macht ihr das nicht so und wir machen es bei uns so schreibt uns gerne jeden tipp in die kommentare oder per e mail an podcast

da sind wir total happy wenn wir da noch input kriegen aber das was wir aus unserer erfahrung sagen können das können wir natürlich nur preis geben und kann mit dem monorepo das hörte sich so an als würdest du immer nur ein frontend für ein backend bauen und dann ist natürlich ein monorepo natürlich super klasse weil ich das direkt verknüpft

jetzt ist ja ein großer vorteil von dieser rest api dazwischen und dieser wirklich sehr sauberen api die aus laravel rauskommt die wirklich nur daten liefert dass wir mehrere font ends ansprechen können und wenn ich dann

nen crm habe das noch irgendwie daten abrufen will oder eine mobile app oder eben meine klassische web anwendung dann kann ich überall die gleiche api benutzen und dann ist natürlich dieser monorepo ansatz da muss man

zumindest in frage stellen ob dann nicht sinnvoll ist das backend als eigene repo zu haben oder man sagt ich habe eben ein haupt frontend mit meiner web anwendung bau trotzdem eine saubere api wo andere anzapfen können und da habe ich dann eben diese downsides dass es vielleicht ein version mismatch geben kann dass die api natürlich nachgezogen werden muss dass es separate repos sind

was hast du da für gedanken genau also diese ganze monorepo monolog den ich da gerade präsentiert habe das gilt wirklich nur für so dieses klassische setup nämlich wir haben ein backend ein frontend vielleicht noch so ein bisschen externe api anbindung aber eben

ein relativ überschaubares konstrukt wenn dann natürlich das projekt größer wird und noch handy apps für android und ios und noch eine desktop anwendung und weiß ich nicht was alles dazu kommt dann hast du vielleicht im backend auch noch mehrere einzelteile die sich um unterschiedliche

bausteine kümmern dann alles in ein repository zu werfen das ist natürlich dann quatsch also da ist dann schon sinnvoll das zu trennen und auch die einzelnen bausteine dann so zu designen dass sie auch alleine funktionieren also wie du gesagt hast so ein backend das mit rest interagiert das braucht nicht mal irgendeinen konsumenten

damit man so als geschlossenes system machen kann okay ja ich würde gerne noch mal auf die vorteile eingehen von dieser ja eigentlich ist ja die rest der api die dazwischen hängt die die ganzen vorteile mit sich bringt und ich glaube wir haben jetzt hier schon vieles angerissen für mich ist wirklich das a und o dass wir eine absolut saubere api haben und das ganze ist im prinzip headless

das heißt egal was ich vorne dran stelle ob das jetzt ein reakt ist oder ob ich später mal was anderes verwende die api ist immer gültig also wenn die daten sauber sind die kommen wir liefern die als jason aus dann wird es immer funktionieren egal was ich im frontend der vorschnelle jetzt kommt das nicht täglich vor dass man den frontend wegwirft was aber schon oft vorkommt ist dass dann ein kunde ankommt und sagt ich habe jetzt hier noch eine power bi lösung und ich brauche ein paar daten von euch und dann können wir sagen ja die endpunkte gibt es ihr könnt die direkt anzapfen und ihr kriegt saubere daten raus genau wie wir die in der web anwendung auch haben das sind live daten

und ja ihr könnt mit den gleichen daten arbeiten und wir haben letztlich keinen aufwand den wir da reintun müssen damit wir noch daten zur verfügung stellen was eben zum beispiel nirscher zumindest von haus aus nicht so ist

ja genau also ich fange mal an der klarsten ecke an wenn man wirklich eine große anwendung baut von der man schon absehen kann wie du gesagt hast da sind vielleicht auch third party anbindungen interessant

eine riesen anwendung die soll immer weiter wachsen wir haben schon tausend module im kopf die es geben soll das soll erweitert werden noch und nöcher vielleicht ist eine app im spiel dann meiner meinung nach führt an so einer wirklichen rest schnittstelle

nicht dran vorbei dass man wirklich klar trennt ok das ist jetzt unser backend das funktioniert total autark und redet mit der welt nur über jason endpunkte und wir haben losgelöst davon ein frontend das tut was es will

man muss aber auch berücksichtigen dann baut man eigentlich zwei anwendungen gleichzeitig nämlich wir bauen zum einen das backend komplett als geschlossenes system nur über diese api endpunkte und wir bauen ein komplettes frontend als separate anwendung die zufällig mit dem gleichen backend redet und was wir dann berücksichtigen müssen ist dass wir im frontend sehr viel boilerplate

boilerplate und arbeit damit haben diese beiden systeme die dann total separiert sind wieder zusammenzufügen das bedeutet sowas wie bei jeder einzelnen informationen die ich anfragen möchte muss ich eben einen request machen

und das kann man wenn man möchte mit so einer zeile im code und fetch request machen aber ehrlicherweise in großen anwendungen steckt da deutlich mehr hinter da muss man gescheites error handling machen da muss man verschiedene fail states abbilden das ist nämlich das was wir bei der webentwicklung leicht übersehen ist es diese interaktion zwischen frontend und backend ein sehr aufwändiges konstrukt ist das bekommen wir nie so mit weil es meistens gut funktioniert besonders wenn wir lokal entwickeln

aber sobald man es dann mal live veröffentlicht hat da sieht man auf einmal wie viele unterschiedliche bausteine da so zusammentragen und das heißt bei jedem request den ich mache auch wenn ich ja so eine webseite aufrufe habe ich eigentlich immer drei states von diesem request nämlich ich lade gerade irgendwas es hat geklappt idealerweise dann kann ich das ergebnis einfach anzeigen oder es hat nicht geklappt und dann kann es eine million gründe haben warum es nicht geklappt hat bei dem der nutzer möglicherweise was machen kann möglicherweise

möglicherweise aber auch nicht und diese drei states bei so einer single page application immer wieder für jeden request abzubilden ist halt sehr viel aufwand an und für sich das ist ja alleine der grund warum es so viele tools dafür gibt so viele unterschiedliche bibliotheken die sich eben damit beschäftigen weil die einem dann schon sehr viel arbeit da abnehmen aber im letzten endes saubere lösung mit dieser rest schnittstelle aber man muss sich eben vergewissern dass man weiß dass man zwei separate anwendungen baut

Ja, total. Was ich mal total charmant finde, vor allem auch so aus Datensicht, ist, dass wir die komplette Logik eigentlich ins Backend verschieben. Also alles, was irgendwie Logik macht, Fachlogik, Datenbankzugriffe, Rechte, Prozesse und so weiter, das kann man im Frontend manchmal so ein bisschen ergänzen, dass man ein bisschen früheres Feedback bekommt, aber eigentlich ist alles, was irgendwie mit Datenverarbeitung zu tun hat, im Backend.

Und das finde ich natürlich super charmant, weil das natürlich auch heißt, wir können am Ende das Frontend leichter austauschen und wir können andere Frontends anbinden, die die gleiche Logik verwenden können. Und sei das jetzt irgendwie ein Generieren von der PDF oder so, das ist natürlich total praktisch, wenn ich das nicht im Frontend habe, sondern wenn ich das zentral im Backend habe und überall dann nutzen kann. Und das finde ich einen der Riesenvorteile, dass man wirklich eine ganz klare Trennung zwischen eigentlich Design, Optik, Ausgabe hat und der Fachlogik dann im Backend in Laravel.

Das gilt ja eigentlich für die React-Anwendung, die man dann baut, auch schon. Nämlich, dass es da diesen klassischen View-Bereich gibt, also wirklich die klassische React-Komponente, wie man sie kennt, wo die Daten da gezeigt werden, wo man vielleicht so ein bisschen minimales Date-Management hat, um kleinste Veränderungen im UI anzuzeigen.

Aber eigentlich, wenn man es sauber macht, braucht man da auch schon irgendeine Art von Mittelsmann, der sich allein um dieses ganze Fetching kümmert. State-Management habe ich gerade angesprochen.

Wenn man es ja wirklich nativ macht, braucht es eigentlich in jeder Komponente die Daten lädt. Erstmal einen State, der sagt, lade ich gerade was oder nicht. Dann vielleicht noch einen State, der Error-Handling hat.

Dann brauche ich irgendeine Art von Fetch-Funktion, die muss ich aufrufen. Da muss ich mit einem Try-Block das abändern und sowas. Da kommt sehr viel Logik rein, die man eigentlich auch nicht in der eigentlichen Komponente haben möchte, sondern dann auch wieder irgendwo auslagern.

Es gibt ja nicht ohne Grund dafür auch zig State-Tools oder State-Bibliotheken, die sich damit beschäftigen. Sodass man wirklich mit diesem Ansatz, den du gerade gesagt hast, im Backend dieses MVC-Pattern hat, wobei der View-Teil eigentlich nur durch so eine JSON-Response abgebildet wird.

Aber im Frontend habe ich auch wieder ein MVC-Pattern, weil ich da nämlich den View-Teil habe, der ist dann deutlich größer, aber auch irgendeine Art von datenverwaltenden Teil.

Das heißt eigentlich auch da wieder doppelte Logik. Aber natürlich, wie du sagst, deutlich modularer, flexibler und bulletproof.

Ich habe jetzt so ein paar Einschübe da noch. Da muss man mal sagen, ob das für dich jetzt schon passt. Und zwar das Erste ist, wir reden immer nur über eine REST-API jetzt. Die Frage ist, was ist denn mit den so modernen Websockets oder vielleicht sogar mit so Geschichten wie GraphQL?

Und wenn wir diese Fetch-Abfragen machen, du hast jetzt Fetch immer genannt, das ist ja diese native JavaScript-Funktion letztlich. Da gibt es ja auch Alternativen mit Axios, sehr beliebt. Und ich meine, React-Router geht zumindest so ein bisschen in die Richtung. Ich glaube, React-Router muss man sogar noch mal separat hier nennen, weil das ja sich schon fast zu einem Framework entwickelt, auch von React ja selbst als Alternative zunächst empfohlen.

Ja Kay, warum sollte ich denn überhaupt Axios benutzen? Ich habe das in letzter Zeit nie verstanden, weil Fetch macht doch inzwischen so viel. Da kannst du doch schon aborten und alles das, was Axios vorher gemacht hat, kann ich doch mit Fetch machen. Ich muss mir natürlich eben eine kleine eigene Komponente schreiben, die so ein bisschen Error-Handling dann tatsächlich auch macht und dazwischen steht. Aber eigentlich brauche ich doch kein externes Paket dafür, oder? Naja, du hast es dir jetzt schon selber beantwortet. Axios ist natürlich jetzt im Moment so ein großes Kampfwort, weil die ja jetzt gerade so einen dramatischen Hack hatten und alle sagen, oh Gott, Axion ist des Teufels.

Wir wollen jetzt gar nicht so sehr auf den rumreiten. Das ist nur, glaube ich, so das verbreitetste Tool. Aber du hast es schon im Prinzip angedeutet. Aber das ist ja eigentlich die Aussage bei jedem Paket, das man sich reinholt, ist ja, naja, aber die kochen auch nur mit Wasser. Wir können es doch einfach selber bauen.

Und das stimmt schon. Die Frage ist, an welcher Stelle, insbesondere wenn die Anwendung dann komplexer wird, du eigentlich Axios komplett nachbaust, wo du es doch gleichfertig erst nehmen kannst.

Also du hast gerade schon Board Controller angesprochen. Also das bedeutet, Requests, die geschickt wurden, abbrechen, bevor man ein Ergebnis bekommt.

Zum Beispiel, weil man eine Seite gewechselt hat und auf einmal die Ressource nicht mehr braucht. Genau. Oder Timeouts. Genau. Bei größeren Anwendungen ist das wichtig, dass man eben Requests auch abbricht, wenn man sie nicht mehr braucht, damit sich da nicht so viel anstaut. Das muss man bei Fetch jedes Mal selber implementieren. Das nimmt sowas wie Axios einem vielleicht schon automatisch ab. Anderes ist das, was ich gesagt habe, wenn ich das mit klassisch Fetch mache, dann muss ich mir erstmal überlegen, wie ich so Standard-Header mitliefer, die ich bei jedem Request brauche.

Also zum Beispiel Accept-Header, Content-Header, Authorization-Headers. Da gibt es für Fetch keine Lösung, dass ich das irgendwo separat konfiguriere und sage, hey, guck mal, bei jedem einzelnen Request brauche ich diese und jene Header,

sondern bei jedem einzelnen Fetch-Request muss ich das mitschicken. Was schon wieder bedeutet, ich baue mir irgendeine kleine Helper-Funktion, die das mitliefert, womit ich schon Axios halb wieder nachgebaut habe. Eine andere Sache ist, ich habe das gerade auch gesagt, wenn man nur mit Fetch arbeitet, dann braucht man in React noch irgendwelche lokalen States,

in denen man den Status der Abfrage gerade speichern kann. Also wird es gerade geladen, damit ich dem User so einen kleinen Spinner anzeigen kann? Hat es einen Fehler gegeben? Dann brauche ich das irgendwo als Variable, damit ich da vielleicht was anzeigen kann. Das sind dann auch so Sachen, wenn ich nur Fetch verwende, muss ich das alles selber bauen oder es in eine Helper-Funktion auslagern, damit ich es als Custom Hook wiederverwenden kann. Naja, oder ich benutze halt ein Package, was das schon gleich macht. Also es stimmt schon, dass Fetch an sich funktioniert. Wir arbeiten ja auch viel damit, aber je komplizierter die Anwendungen dann werden

und je smoother das auch für den Nutzer werden soll, desto mehr fängt man dann an, einfach die Funktionalität nachzubauen, die andere einem schon geben. Und damit meine ich jetzt nicht, benutzt Axios, sondern ein Äquivalent, vielleicht ein React-maßgeschneidertes Framework-Komponente, die sich damit beschäftigt. Und weißt du, ob React Router oder NextJS einem sowas auch anbieten und schon abnehmen oder würde man trotzdem beispielsweise in Axios verwenden? Ja, genau. Die nehmen einem das nicht ab. Was die einem nur abnehmen, sowohl NextJS als auch React Router zum Beispiel, oder es gibt ja auch, wie heißt es hier, diese TAN-Stack, TAN-Router.

Oh Gott, da kommt jetzt das Bingo in meinem Kopf. Naja, die geben dir nur Hooks, wo sie sagen, schau mal hier, diese Funktion wird gefeuert, wenn du eine neue Seite wechselst. Das wäre jetzt hier der total gute Platz, um irgendeinen Request zu machen. Aber den eigentlichen Request muss man dann schon selber machen. Also die haben da keine eingebauten Tools, da kannst du dann auch Axios verwenden oder Fetch oder sonst irgendwas. Das Elegante daran ist nur, dass es eben dieses State-Management rausnimmt und die sagen, okay, wenn dieser Hook funktioniert, dann geben wir das Ergebnis des Hooks in die Komponente rein

und du kannst es einfach anzeigen. Wenn es nicht funktioniert, haben wir vielleicht sogar ein übergeordnetes Fehlermanagement, wo wir dann eine passende Seite anzeigen oder sowas. Und für den Loading State haben wir vielleicht auch schon automatisch ein Skeleton, was angezeigt wird oder sonst irgendwas. Okay, das heißt aber abschließend, Axios kann man schon verwenden, tut nicht weh, ist nicht zu viel Overhead. Ja, wenn es nicht gerade gehackt wird, dann ist das ganz fantastisch. Ja, eine Sache, da muss ich jetzt noch rumhalten, die finde ich nämlich bei Fetch ganz störend. Was heißt störend? Da haben sich bestimmt tolle Leute was beigedacht.

Und zwar ist es so, wenn man mit nativen Fetch einen API-Request macht und da ein serverseitiger Fehler zurückkommt, sagen wir mal 400 oder 500 irgendwas, dann ist das aus der Sicht von Fetch kein Fehler in dem Sinne von, dass die Funktion trotzdem normal funktioniert und dann kannst du in sowas wie response.success gleich true oder false nachschauen, ob der Request geklappt hat oder nicht. Und wenn man dann ein sauberes Error-Management in seiner Anwendung haben möchte, mit normalen Fehlern und diesem Exception-Path, dann muss man da wieder eigene Exceptions drumherum rappen, um zu sagen, okay, wenn ich einen Fetch-Request in einem Try-Block mache,

dann fehlt auch dieser Try-Block und der Catch-Block springt an, wenn in dem API-Request von Fetch irgendwas fehlschlägt. Und das ist zum Beispiel auch so eine Sache, die Axios einem direkt abnimmt. Wenn da ein Fehler in dem Request geworfen wird, dann wird da direkt ein gescheiter Fehler geworfen, mit dem ich agieren kann. Weil Fetch sich denkt, ja, die eigentliche Funktion hat ja funktioniert, nur dass das Ergebnis des Servers nicht zu dem passt, was der war. Das ist ja nicht mein Problem, so sinngemäß. Und was sagst du zu WebSockets und GraphQL im Vergleich zu einer REST-API? Gibt es Anwendungsfälle oder ist eins davon totaler Quatsch?

Ich habe auch meine eigene Meinung dazu, aber ich lasse dich erst mal. Ich finde, REST-API auf einen Stapel mit GraphQL zu stellen, kann man schon machen. WebSocket ist so ein bisschen was Separates. REST-APIs funktionieren ja idealerweise so, dass ich eine Ressource abfrage. Auch da wieder per URL weiß ich genau, was ich für ein Ergebnis erwarten würde. Und dann bekomme ich ein Ergebnis, was zu dieser Ressource passt. Das bedeutet, wenn ich slash user gleich 5 abfrage, dann bin ich mir relativ sicher, dass ich als Antwort alle Informationen bekomme, die mit diesem User zu tun haben. Vielleicht noch, wenn der Server ein bisschen vorausschauend ist,

werden irgendwelche Relationen dazu nachgeladen. Wenn ich jetzt allerdings auf einer Seite 5 unterschiedliche Ressourcen brauche, da haben wir wieder dieses Dashboard-Konzept von gerade, dann kann ich 5 separate API-Requests machen zu 5 unterschiedlichen Endpunkten und bekomme 5 unterschiedliche Antworten. Aber das ist halt auch 5-fache Last von dem Server. Geht aber nicht anders, weil im REST-Konzept immer diese Relation zwischen Ressource, die ich antworte und antworte. Und GraphQL versucht das ja zu lösen, indem es nicht sagt, wir haben 100 verschiedene Endpunkte in so einer Anwendung, die unterschiedliche Ergebnisse zurückgeben

und der Server entscheidet, wie diese Ergebnisse aussehen, sondern im Prinzip stelle ich einen fancy Datenbank-Query an den Server über einen Endpunkt und der Server antwortet mir genau in dem Schema, den ich erwarte. Und das hat den großen Vorteil, dass ich eben einen Request machen kann, wo ich 10 unterschiedliche Dinge abfrage, die gar nichts miteinander zu tun haben müssen und der Server kann mir darauf antworten. So grob gesagt ist die Idee zwischen den beiden. Vielleicht müssen die Leute hier so ein bisschen abholen. Bei GraphQL schicke ich quasi ein Objekt mit, das die Datenstruktur enthält, die ich als Rückgabe erwarte.

Also ich kann sagen, ich schicke ein Objekt, wo ein User drin ist mit einer bestimmten ID. Ich kann sagen, ich habe vielleicht noch irgendwie eine Company und als letztes noch irgendwelche statistischen Daten oder so. Und dann bekomme ich vom Server idealerweise genau dieses Objekt letztlich ausgefüllt mit Daten zurück und kann mir so im Prinzip mein eigenes Ergebnisschema aus dem Frontend zusammenbauen. Genau. Da habe ich als Client ein bisschen mehr Kontrolle darüber, was ich vom Server bekomme. Und WebSocket ist ja nochmal eine ganz andere Geschichte. Vielleicht auch da nochmal ein kurzer technischer Abriss.

Bei den beiden Varianten, die wir gerade beschrieben haben, ist es immer so, ich weiß, was ich möchte, stelle eine Anfrage, bekomme ein Ergebnis und dann ist wieder Schluss. Und wenn ich eine neue Information haben möchte, muss ich wieder eine Anfrage stellen, bekomme wieder ein Ergebnis. Und was dahinter steckt, ist relativ viel Overhead, weil erstmal eine Verbindung zum Server aufgebaut werden muss. Da geht es auch sowas wie HTTPS-Handshakes, SSL-Zertifikate austauschen. Wir betrachten das immer aus unserer Sicht als ein Request, der da geschickt wird. Aber auf Netzwerkebene ist da ja ganz viel hin und her für jedes einzelne Request.

Dann muss sowas wie Authentifizierung jedes Mal ausgetauscht werden. Weil wirklich jeder Request für sich steht. Und WebSocket versucht das zu lösen, indem es sagt, wir machen eine Verbindung, halten sie die ganze Zeit offen und beide Seiten können Informationen da rein schicken. Und das ist insbesondere spannend für Informationen, die vom Server kommen. An diesem klassischen Client-Server-Backend kann ich als Client immer nur Anfragen an den Server schicken und der aber nicht zurück, weil ich derjenige bin, der das initiiert. Und das bedeutet zum Beispiel, wenn sowas wie ein Chat ist, wo ich jede Sekunde auf die Antwort von meinem Gesprächspartner warte, muss ich in diesem klassischen Modell jede Sekunde fragen, hey, gibt es neue Nachricht, gibt es neue Nachricht, gibt es neue Nachricht, gibt es neue Nachricht, auch wenn die ganze Zeit nichts passiert, weil der Server nicht von sich aus sagen kann, hey, schau mal, hier ist eine neue Nachricht, zeig die mal an.

Und WebSocket löst das eben dadurch, dass ich als Client von Anfang an eine Verbindung aufbaue zum Server und sage, hey, schau mal, hier drüber können wir reden und dann kann der Server nur dann, wenn auch eine neue Nachricht reinkommt, sagen, hey, schau mal, neue Nachricht, jetzt musst du irgendwas machen.

Und deswegen betrachte ich das ein bisschen losgelöst von den anderen beiden. WebSocket ist dann wirklich stark, wenn man Realtime braucht und wirklich ständig neue Nachrichten kommen.

Ist allerdings auch relativ aufwendig zu implementieren, weil der Server halt zu jedem einzelnen Client eine Verbindung aufhalten möchte. Also wer sich mal so Preise bei Pusher angeschaut hat zum Beispiel, das ist so ein Anbieter, der einem das ein bisschen abnimmt, der hat gesehen, dass die Leute sich das sehr viel kosten lassen.

Da ist es doch in den meisten Fällen einfacher, tatsächlich doch mit so einer Art Polling-Strategie vielleicht alle fünf Sekunden nur nachzufragen beim Server.

Da ist ja in der Theorie PHP jetzt auch nicht so ganz der richtige Lieferant für so ein WebSocket, weil PHP ja eigentlich immer nur eine Datei durcheiert und dann bist du fertig, während so ein Node.js, glaube ich, den Prozess offen hält.

Genau. Und dann in der Theorie zumindest geeignet heißt, ich bin mir sicher, da gibt es auch PHP-Implementationen für, aber das ist natürlich so eine kleine Downside. Genau. Es muss halt die ganze Zeit ein Service am Server laufen und auch überwacht werden. Also so ein bisschen wie so ein Q-Worker zum Beispiel auch. Und das sind halt alles zusätzliche Bausteine, die man an so eine relativ einfach zu wartende Web-Anwendung dran baut, wo man sich schon gut überlegen muss, ob es das wert ist.

Jetzt haben wir ja eine große Web-Anwendung, die wir in letzter Zeit gebaut haben, auf WebSockets konzipiert und auch gebaut.

Und da ist die Idee gewesen, dass wir ganz viele Verkehrsdaten haben, die ständig reinkommen und die ich im Prinzip live vom Server gepusht haben will.

Das ist ja dieses Push-Pull-Prinzip, was du eben gesagt hast. Und dann fanden wir das total intelligent zu sagen, wir machen alles in dieser Anwendung eben über WebSockets. Insgesamt auch wunderbar. Ich würde es aber nicht wieder machen, weil diese klassischen REST-Anfragen, die wir eigentlich dabei haben, also ich habe eine Ressource, ich will eine Tabelle darstellen mit Benutzern oder so.

Das machen wir jetzt da in dem Fall auch über WebSockets dann. Klappt auch. Aber das ist irgendwie in der REST-API, in der klassischen API ist das knackiger. Du machst einen Fetch, bekommst dein Ergebnis zurück, kannst das Ergebnis verwenden. Und beim WebSocket hatte ich das Gefühl, dass das immer so ein bisschen schwammiger war. Kay, du kannst das bestimmt technisch noch besser greifen. Während das natürlich für diese Verkehrsdaten, also zum Beispiel ein Zustand von einem Schild oder so Verkehrsmesswerte, das anzuzeigen, ist natürlich klasse.

Von daher wäre, glaube ich, im Nachhinein ein Hybrid aus beiden Lösungen für mich der bessere Ansatz gewesen. Ich weiß nicht, wie du das siehst. Ich sehe das auch so, genau. Der Vorteil von so einer Einzel-Request-basierten Geschichte, das kann ja auch GraphQL sein, ist eben, das Internet, seitdem es sich gibt, hat sich darauf spezialisiert.

Das heißt, da gibt es Tools nöcher und nöcher, da gibt es Best Practices, da gibt es alleine schon was wie HTTP-Status-Codes. Das bedeutet, wenn ich eine Anfrage an den Server schicke und irgendwas nicht geklappt hat, dann sehe ich schon anhand des Status-Codes ungefähr, was es gewesen ist.

Und das ist einfach super flexibel, super dynamisch in dem Sinne von unendlich viele Tools, die darauf aufbauen und alleine schon mit diesen Status-Codes umgehen, weil das einfach so eine verbreitete Geschichte ist.

Bei diesen Web-Socket-Geschichten ist das Problem, es ist nicht so modular. Das bedeutet, du schickst ja über diesen Web-Socket-Kanal eine Anfrage an den Server und da gibt es schon viele unterschiedliche Standards davon, wie so eine Nachricht aussehen soll.

Und dieser Standard sieht auch nicht zwangsläubig vor, dass du eine Antwort bekommst. Das heißt, da wird es dann schon knifflig, aus irgendeiner Antwort, die der Server vielleicht schickt, herauszufinden, ob das eine Antwort auf die Anfrage ist, die du gerade geschickt hast.

Und wenn ja, wie sieht diese Antwort aus? Dann musst du für jeden einzelnen Fehlerfall, wo du bei REST vielleicht einfach nur auf den Status-Code achten müsstest, um zu schauen, was ungefähr schiefgelaufen ist, aus der Nachricht, die du kommst, herausidentifizieren, was denn da eigentlich das Problem ist.

Also kurzum, für so klassische REST-Anwendungen ist es so viel einfacher, einfach eine REST-Abfrage zu stellen, als das auch noch über Web-Socket zu schieben.

Ich stimme dir zu, für sowas, wo du dann wirklich eine Echtzeit-Anwendung brauchst und vielleicht Live-Verkehrsdaten, die sich wirklich jede Sekunde ändern, da ist sowas wie Web-Socket dann wieder stark.

Deswegen stimme ich dir zu, so ein Hybrid ist eigentlich das Beste, sich zu überlegen, okay, auf den meisten Seiten brauche ich einmal die Informationen, die dann auch länger gültig sind, die hole ich mir dann per normaler Restschnittstelle.

Und wenn ich dann wirklich mal eine individuelle Seite habe, wo vielleicht ein Chat drauf ist, das ist so das gängigste Beispiel, oder irgendeine Google-Maps-Karte zum Beispiel, wo ich Echtzeit-Daten brauche, für diese spezifische Seite mache ich dann eine Web-Socket-Verbindung drauf und hole mir das, was ich brauche.

Das entlastet auch den Server, weil der dann nicht für jeden einzelnen Klienten eine Web-Socket-Verbindung halten muss die ganze Zeit. Guck mal, jetzt haben wir schon einen Podcast im Podcast gemacht, aber ich brauche noch einen Take zu dir zu GraphQL. Ich habe noch nicht rausgehört, bist du da Fan von, bist du kein Fan von, ist es anwendungsbezogen? Wir haben es noch nicht benutzt, ehrlich gesagt. Ich sehe schon den Appeal, das ist, glaube ich, insbesondere dann stark, wenn man eine größere Trennung hat zwischen Front- und Backend.

Wir haben das am Anfang kurz zitiert, so wie wir vorgehen in den Anwendungen in unserer Größenordnung, haben wir einen Entwickler, der damit beauftragt, einen Feature zu bauen.

Und dann baut er sich sowohl die Backend-Seite davon, den HTTP-Endpunkt, als auch den Frontend-Endpunkt und weiß genau, was dazwischen ihn abgeht und kann dann das Backend so designen, wie er es gerade braucht.

Das führt dann zwar dazu, dass es da möglicherweise mehrere Endpunkte gibt, die ein bisschen ähnlich sind, aber nicht ganz gleich, wenn die Anwendung komplizierter wird.

Aber es ist so sehr aus einem Fluss. Während diese GraphQL-Geschichte insbesondere dann spannend ist, wenn große Anbieter unendlich viele Daten zur Verfügung stellen, wo sie nicht für jeden Anwender im Vorhinein absehen können, was die damit wohl machen können.

Bei so einer klassischen Anwendung gebe ich als Server ja vor, welche Endpunkte es gibt und was sie zurückliefern. Und als Klient, als Anwender bin ich dann darauf beschränkt, die auch so zu konsumieren. Und dann brauche ich vielleicht fünf verschiedene Informationen und muss dann fünf unterschiedliche Requests machen. Da ist dann sowas wie GraphQL total stark, weil ich dem Anwender, von dem ich nicht weiß, was er vorhat, sagen kann, hier ist im Prinzip meine Datenbank, kurz gesagt.

Und wenn du mir eine passende Anfrage stellst, gebe ich dir genau das, was du möchtest. Also für solche Fälle ist es total stark. Ich glaube, das lassen wir mal so stehen. Ich würde mit dir gerne noch auf die anderen Methoden eingehen, wie wir eben Laravel mit einem Frontend verknüpfen können. Und wir haben jetzt mehrfach schon Inertia gesagt. Und ich glaube, wir müssten die Leute ein bisschen abholen, was Inertia ist, wo der Gedanke ist. Und ich werfe einfach nochmal zum Start rein, dass Inertia selbst sagt, dass es ein moderner Monolith ist. Und jetzt waren ja lange die Microservices so gehypt, wo wir nur bedingten Fan von waren.

Das ist natürlich jetzt auch wieder total anwendungsfallbezogen. Aber an sich ein monolithischer Ansatz schon auch interessant sein kann, ohne eine API-Zwischenschicht jetzt bei Inertia. Aber Kay, ich lasse dir den Vortritt, dass du einmal vielleicht kurz erklärst, was Inertia überhaupt will. Ja, ich finde es ganz lustig zu sehen, dass Inertia im Laravel-Ökosystem ungefähr zur gleichen Zeit aufgeploppt ist,

wie Livewire, habe ich beide kurz schon angeschnitten. Es geht im Prinzip darum, diese Kluft zwischen Frontend und Backend zu überbrücken. Und beide haben unterschiedliche Ansätze. Livewire, habe ich gerade schon gesagt, geht eher so den Laravel-Weg, in dem ich alles mit PHP und Blade mache. Das aber so aussieht wie eine React-Komponente und sich auch dynamisch verhält. Und Inertia ist ein bisschen das andere Kind, ein bisschen das ungeliebte Kind, glaube ich, wenn man sich die Aufmerksamkeit... Inzwischen ja sehr geliebt, oder? Inzwischen geht es schon, aber es gab eine Zeit, da hatte ich das Gefühl, Inertia ist so ein bisschen so, ach ja.

Weil eben, und das ist, glaube ich, ein wichtiger Punkt, viele Laravel-Entwickler eben Laravel-Entwickler sind. Die sind PHP-Entwickler, die entwickeln Laravel, PHP, vielleicht noch HTML und CSS, aber eben kein Frontend. Und so wie wir aufgestellt sind, können wir auch eine React-Anwendung bauen, aber das ist eben nicht gegeben. Und deswegen ist der Schritt schon nahe zu sagen, okay, wir bauen etwas, was möglichst aussieht wie React in Laravel nach, damit Leute viel benutzen können.

Aber Inertia ist eben das gleiche Konzept, nämlich zu sagen, ja, wir wissen, dass wir alle Laravel als Backend benutzen. Und ihr benutzt jetzt auch irgendein Frontend. Das kann View sein, das kann Svelte sein, das kann React sein. Wir wollen aber möglichst diese Friktion reduzieren, die ich gerade genannt habe. Und was das in der Technologie macht oder in der Wirkung macht, habe ich gerade auch schon kurz zitiert. Meine React-Komponente sieht aus wie eine React-Komponente. Und als Props bekomme ich die Informationen rein, die ich in der Seite anzeigen möchte. Und auf der anderen Seite, in der Laravel-Komponente, mache ich eine Inertia-Response, so heißt es.

Man kann sich das vorstellen wie eine klassische Blade-Response. Das heißt, ich gebe ihm an, welche Datei er gerne anzeigen soll. Nur dass es jetzt keine Blade-Datei ist, sondern es ist jetzt eine React-Komponenten-Datei. Und ich gebe ihm an, welche Informationen da übergeben werden. Genauso wie ich das bei einer Blade-View auch machen würde. Und das Inertia im Hintergrund macht die Magie von, wenn ich auf einen Link klicke, fragt der im Hintergrund die Informationen ab. Und dann kann man wirklich im Browser sehen, okay, der fragt ab, welches Template ich da verwenden soll und welche Informationen da gegeben werden sollen.

Und die setzt es automatisch in meine Komponente ein. Das bedeutet, ich kann wirklich React nicht als App bauen, sondern als Template-Engine benutzen. Ich brauche also eigentlich kaum Boilerplate drumherum. Ich brauche kein eigenes Routing. Ich brauche kein eigenes Autorisierungsmanagement. Keine globalen State-Management. Ich kann, wenn ich das möchte, jede Komponente so als Happy-Path-Template benutzen, indem ich einfach nur ganz stumpf die Informationen oben reinbekomme und die verwenden kann. Und das macht natürlich total viel her, zu sagen, wir haben eben nicht eine separate Frontend-Anwendung,

wo wir relativ viel Boilerplate haben für diesen MC-Teil, habe ich am Anfang darüber gesprochen, sondern wir reduzieren React eigentlich nur auf eine fancy Template-Engine, die meiner Meinung nach deutlich besser funktioniert als Blade und haben eigentlich das Beste aus beiden Seiten. Ich glaube, der große Vorteil von Inertia ist ja, dass du viele Sachen in Laravel verlagern kannst. Du machst Routing in Laravel, du machst die ganze Authentifizierungsgeschichte in Laravel, du machst sowas wie Form-Validation und sowas. Das ist ja, glaube ich, dann alles Laravel in dem Fall. Und natürlich super easy und vor allem für Leute, die sich mit Laravel auskennen, natürlich total praktisch.

Und das hat aber genau die gleiche Downside eigentlich, weil wir haben ja eben lang und breit darüber gesprochen, warum so eine saubere API so toll ist. Die gibt es natürlich in dem Fall eigentlich gar nicht, oder? Ja, also das ist die Frage, wie man es baut. Weil ehrlicherweise, das ist jetzt schon sehr technisch fokussiert, aber das Einzige, was sich ändert, wenn du mit Inertia arbeitest, ist, dass du als Response für deinen Controller eben eine Inertia-Response hast. Das ist das Einzige, was sich ändert. Der Rest ist alles gleich. Und wir haben es ja eh so, dass wir eigentlich in dem Controller,

wo diese Inertia-Response stattfindet und das an die URL gekoppelt ist, dass wir da nicht die Logik drin haben, die eigentlich dahinter steckt. Also irgendwelche Datenbankabfragen, irgendwelche Datenverarbeitungsmaßnahmen, sondern das kappeln wir aus in separate Klassen, sag ich mal. Sodass es wirklich losgelöst ist und im Controller nur diese Verbindung hergestellt wird zwischen der URL, die ich aufrufe, vielleicht Validierung, Autorisierung und der Response. Und das bedeutet aber umgekehrt, wenn ich jetzt so eine Inertia-App habe und gleichzeitig allerdings auch eine API brauche für irgendwas,

dann habe ich zwar ein bisschen mehr Aufwand, weil ich eine zweite Controller-Methode machen muss, aber dadurch, dass ich die Logik selber eh schon ausgelagert habe, spricht auch wenig dagegen, die Logik dann einfach wiederzuverwenden oder vielleicht sogar den gleichen Controller nehmen, die gleiche Methode und nur über einen HTTP-Header zu sagen, ich will jetzt gerne eine JSON-Response oder ich möchte jetzt gerne eine Inertia-Response oder sonst irgendwas. Also da ist der Overhead ehrlicherweise gar nicht so groß. Das heißt, du nimmst jetzt das gleiche Objekt, was du sonst als Inertia-Response ausgeben würdest

und sagst jetzt, das ist aber eine API, eine JSON-Response, habe dafür einen eigenen Endpunkt und kann dir darüber auch dann anfragen von einem externen Tool bestenfalls. Genau. Jetzt muss ich mal gerade überlegen, habe ich mir heute noch durchgelesen, diese ganze Inertia-Magie funktioniert deswegen, weil da eben standardmäßig schon so ein Inertia-Header gesetzt ist. Ich bin mir jetzt gar nicht sicher, ob wenn man diesen Header nicht setzt, ach nee, dann wird es einfach als statische Webseite ausgegeben. Naja, aber man kann auf jeden Fall da relativ einfach was programmieren, dass man eben nicht so Vendor-Logged ist auf diese Inertia-Geschichte.

Hat Inertia was mit Server-Site-Rendering zu tun? SSR? Vielleicht, wenn man möchte. Machen wir das Thema auch noch auf. Ja, das müssen wir spätestens bei Next.js glaube ich gleich mit reinbringen, weil das ja eine der großen Stärken ist, denke ich. Ja. Aber ich bin mir nicht ganz sicher, wie das bei Inertia aussieht. Ich habe mir Inertia vor ein paar Wochen mal intensiver angeguckt, habe die Hälfte schon wieder vergessen und war eher so auf dem Trip. Ich würde es gerne verwenden, weil das halt überall total propagiert wird und gesagt wird, das ist eben der neue heiße Scheiß. Und ich bin aber am Ende zum Schluss gekommen,

dass es für uns nicht so wahnsinnig gut funktioniert in dem Web-Anwendungskontext, wo wir so sind, weil ich so das Gefühl habe, da wird schon viel Frontend, Backend vermischt. Und ja, ich habe mir dann die Code-Beispiele angeguckt und so und es basiert schon sehr viel darauf, dass man vorher weiß, was für Daten man eigentlich benutzt. Und genau wie du dann sagst, in dem Moment, wo ich ein Dashboard oder sowas habe, weiß ich es aber eventuell noch nicht ganz genau oder wo ich so dynamische Inhalte habe wie ein Chat und so weiter. Und dann fange ich trotzdem an, da was drum herum zu bauen. Jetzt kann ich da nicht so irre aus Erfahrung sprechen,

weil ich in letzter Zeit weder wahnsinnig viel mit Laravel noch mit Inertia gemacht habe. Da bist du sicherlich fitter. Aber das waren so Vorbehalte, wo ich gedacht habe, ich bin mir nicht ganz sicher, ob das auf unseren Anwendungsfall so gut passt. Das ist ja immer so ein bisschen die Krux an neuen Technologien. Selbst wenn sie in der Theorie besser ist, hat man in den Technologien, die wir schon verwenden, schon einfach so einen Wissensvorsprung durch so viele Projekte, die wir haben, auch durch so viele vielleicht noch allerkleinste Fallstricke, über die man mal im Verlauf von so einer Anwendung drüber stolpert.

Wenn man sich im Internet so eine Demo zu so einer To-Do-App anschaut, dann denkt man sich, boah, das ist ja das coolste Framework der Welt. Aber nur wenn man dann wirklich mal eine reale Anwendung gebaut hat mit total spezifischen Kundenanforderungen, wo man denkt, hä, was ist das denn? Erst dann stellt man fest, wo dann doch vielleicht im Detail die kleinen Stolpersteine. Aber ich will mich jetzt nicht hier hinstellen und sagen, das oder das oder das ist so, wie wir es immer machen müssen, weil es wirklich für jede einzelne Anwendung, und deswegen hast du am Anfang auch gesagt, kann der ChatGPT nicht sagen, was der richtige Weg ist,

für jede einzelne Anwendung so individuelle Anforderungen, dass man es wirklich jedes Mal selber unterscheiden muss. Ja, wir können die Leute, glaube ich, nur ermutigen, auch in der Scheibe mal auszuprobieren und mal zu gucken, passt das für die eigene Anwendung und passt das zum eigenen Tech-Stack. Ich glaube, viel mehr Tipps können wir dazu gar nicht geben. Wo wir aber vielleicht noch was zu sagen können, ist Next.js. Kay, ich bin so verwirrt immer gewesen zwischen Next, Nuxt, Nest. Und da wird das auch alles noch anders geschrieben. Next.js wird alles klein mit Punkten dazwischen. Nest.js wird groß vorne und JS groß und alles zusammen.

Und Nuxt, da ist gar kein JS mehr drin, wird aber groß geschrieben. Ist ja ein View-Framework, glaube ich, so was wie Next für View. Total verwirrend. Ich glaube, das müssen wir jetzt hier nicht auflösen. Aber Next.js jedenfalls ist ein Framework, glaube ich, kann man so nennen, für React, was ja selbst nur eine Bibliothek ist, während Angular ja selbst ein Framework sein will. Deswegen gibt es sowas für Angular nicht. Ja, Next.js, Kay. Was macht Next.js und macht das Sinn, es zu verwenden? Und für wen macht es vielleicht Sinn? Ja, es fällt alles darauf hinaus, auch mit Next.js, wenn man diese Kluft hat, die ich schon jetzt mehrfach besprochen habe,

von welcher Seite man sich nähern möchte. Und während Inertia, wie gesagt, eher so der Laravel-Weg ist, diese beiden Bereiche zu verbinden, ist Next.js eben der React-Weg, das zu verbinden. Also kurz gesagt, Next.js ist ein Server, ein Backend, was irgendwo auf einem System läuft, dauerhaft, die ganze Zeit. Node.js, ne? Genau. Und als Backend für deine App fungiert. Und das ist im Prinzip die ganze Magie, die dahinter steckt, richtig runter trivialisiert. Das bedeutet allerdings, wenn wir es so einsetzen, wie wir das machen, nämlich immer noch mit einem dedizierten Laravel-Backend dahinter, hast du nicht nur ein Laravel-Backend, was die Datenbank behält,

sondern auch noch ein Next.js-Backend und eine React-Frontend. Und das bedeutet, wenn du in React-Frontend Informationen darstellen möchtest, dann stellt der die Anfrage an das Next.js. Und das Next.js hat selber keine Information, stellt auch wieder eine Anfrage an das Laravel-Backend. Und das wiederum holt die Daten vielleicht aus der Datenbank. Also das macht eigentlich nur so einen Schritt dazwischen. Das ist eher dafür da, wenn man wirklich dieses Next.js als einziges Backend verwendet, wo dann auch schon direkt die Datenbank-Interaktionen, Storage-Interaktionen, sonst irgendwas drin stattfinden.

Dann ist es stark. Aber so benutzen wir es ja eben nicht. Man spricht ja bei Next.js auch immer so vom Backend vor Frontend. Das heißt, du hast eigentlich ein spezielles, kleines Backend, was für dein Frontend die richtigen Daten ausliefert, aber eben normalerweise für ein spezielles Frontend. Das heißt, du hättest eigentlich ein Backend vor Frontend für eine App und willst ein Backend vor Frontend dann für eine Website und machst dir da eigentlich deine kleinen eigenen Backends. Und das ist auch genau der Punkt, der mich so ein bisschen stutzig macht, weil ich denke so, wir haben mit Laravel,

also in unserem Fall jetzt ja schon ein Backend oder vielleicht nennt man Nest.js als Backend. Am Ende egal. Und will ich dann irgendwie noch eine Schicht dazwischen haben, kommt mir für mich so ein bisschen sperrig vor. Nein, für uns das Quatsch. Was das natürlich mitbringt, ist dann eben das eben schon angesprochene SSR, also Server-Site-Rendering, was ja gerade in dem Webseiten-Bereich angeblich Vorteile hat. Also in dem Moment, wo ich die Seite aufrufe, auch wenn das jetzt so Single-Page-Application-mäßig ist oder ein React-Frontend, bekomme ich eben mit einer Server-Site-gerenderten Seite

schon ganz viele Informationen, ich sage mal, wie so Meta-Text, wie so ein Title und so ein bisschen die Webseiten-Struktur und vielleicht den Haupt-Content, bekomme ich eben schon vorgerendert angezeigt, habe das direkt verfügbar, ist angeblich für SEO vor allem besser, weil die Sachen eben nicht mit JavaScript nachgeladen werden, habe ich mich so ein bisschen reingenerdet und das will ich jetzt hier nicht zu weit austreten, aber Google sagt selbst, eigentlich ist SSR besser, aber wir können auch JavaScript rendern und von der Geschwindigkeit macht es eigentlich auch keine Unterschiede, weil ob ich das jetzt gerade auf dem Frontend,

die Seite direkt lade ohne Inhalte und dann die Inhalte per Request lade oder ob ich in dem Request, der initial stattfindet, schon meine Inhalte mitkriege. Also ich bin mir nicht ganz sicher, ob das performanstechnisch so einen großen Unterschied macht, konnte ich zumindest besser nicht so richtig feststellen. Und ich finde, man holt sich da halt so einen riesen Overhead rein. Man braucht eben serverseitig da noch Komponenten, man trennt Backend und Frontend nicht mehr so klar. Ich bin ja jetzt nicht so ein Riesenfan von, jetzt bauen wir im Wesentlichen Web-Anwendungen, wo SEO halt nicht so wahnsinnig relevant ist,

aber ich kann mir eigentlich beim besten Willen nicht vorstellen, dass es so einen riesen Unterschied macht. Das ist eigentlich auch wieder ein eigenes Podcast-Thema für sich. Kurz gesagt, die Idee von Server-Site-Rendering ist, dass du Arbeit, die du sonst im Client hättest, wieder in den Server zurücknimmst. Bei der Single-Page-Application ist es so, wenn ein Nutzer die Seite lädt, dann schicke ich dem fünf tollen JavaScript, weil ich im Prinzip die komplette clientseitige Anwendung ich initial einmal mitschicken muss. Dann sitzt er da auf so einem riesen Pod JavaScript, vielleicht mehrere Megabyte im Worst Case.

Und dann kommt für jedes Mal, wenn er eine Information, das ist wirklich nur das Template für die Anwendung, und jedes Mal, wenn er dann eine Information haben möchte aus dem Backend, muss ich wieder einen separaten Request machen. Das bedeutet, da ist relativ viel Arbeit up front. Das ist der Hauptteil, weil ich erstmal dieses riesen JavaScript-Paket runterladen muss. In der Zwischenzeit ist die Seite weiß, weil da nichts an sich draufsteht. Dann muss ich das JavaScript auseinanderbauen. Das dauert auch eine Weile im Browser. Also alles auf technischer Ebene sind das ja doch signifikante Zeiten,

die da zusammenkommen. Das fällt uns im Zeitalter von Glasfaser und 5G vielleicht nicht so auf. Dann hat er die App entpackt. Dann muss er vielleicht die App an sich erstmal rendern. Dann hat er eine Komponente gemounted. Das stellt fest, wir brauchen noch eine Userliste. Dann muss da wieder noch ein HTTP-Request stattfinden. Und erst dann hat man ein Ergebnis für den Nutzer. Das ist schon im Detail, wenn man da wirklich eine riesen Anwendung hat, wo es wirklich um so Millisekunden Kennzahlen für Nutzerinteraktionen geht, ist das schon ewig lange. Plus, wenn es vielleicht für Mobile funktionieren muss,

in Gebieten, wo nicht so schönes Internet stattfindet, auf dem Land oder sonst irgendwas, dann ist das schon sehr viel Arbeit. Und die Idee von Server-Site-Renderings, eigentlich, da sind wir wieder full circle, in die gute alte Zeit zurückzugehen, wo früher der Server auf eine Anfrage einfach das fertige Ergebnis geliefert hat. Das war schön. Genau. Da muss der Client eigentlich nichts weiter machen, außer so eine HTML-Seite darzustellen. Und das können die ziemlich gut. Und bei jedem Seitenwechsel habe ich dann die Seite zwar wieder weiß, aber dafür bekomme ich dann so schön auf einen Schlag

alles, was ich brauche. Das ist so die Idee, die dahinter steckt. Aber die Downsides von nicht Server-Site-Gerendert, die treten ja immer nur genau dann ein, wenn ich das erste Mal die Seite lade. Weil dann habe ich dieses riesen JavaScript-Paket und dann habe ich diesen ganzen initialen Load. In dem Moment, wo ich dann auf der Single-Page-Application eine Seite zum Beispiel wechsle, habe ich eigentlich viel weniger Load, als bei einem Server-Site-Gerenderten, weil ich dann eben nur noch die Informationen nachlade, die ich ergänzen möchte. Und da müsste ich doch eigentlich in dem Schritt performanter unterwegs sein.

Oder ist Server-Site-Gerendering da intelligent? Naja, aber ich glaube eher, bei den künftigen Abfragen ist ja nicht das, was am meisten Zeit kostet, dass ich komplexes HTML versus JSON-Response runterlade, sondern eher, dass im Hintergrund ein Server ist, der eine Datenbankabfrage machen muss, der die Ergebnisse vielleicht formatieren muss. Und das habe ich ja so oder so. Also ich glaube, diese eigentliche Zeitersparnis durch, es wird weniger Bytes hin- und hergeschoben, der ist, glaube ich, irrelevant. Aber ja, da, wo wir unterwegs sind, ist das eben nicht so dramatisch zu sagen, hier, du bekommst initial so ein Bundle,

weil wir Anwendungen für Kunden machen, die meistens auch nur kundenseitig benutzt werden. Da ist auch sowas wie, ja zum Beispiel, dass manche Geräte kein JavaScript unterstützen, kein Problem, oder dass JavaScript aus Berechtigungsgründen nicht aktiviert ist von den Companies oder sowas, alles für uns kein Problem. Und deswegen arbeiten wir ja auch so, wie wir es machen und sagen einfach, hier ist das Bundle, da haben wir vielleicht noch so ein bisschen Splitting drin, wenn wir gut drauf sind. Aber für uns funktioniert das, während Server-Side-Rendering dann halt wirklich erst für noch größere Seiten ist,

wo es wirklich auf jeder einzelne so eine Byte und jeder Millisekunde Ladezeit ankommt. Ja, sehr spannend, Kay. Ich würde fast sagen, wir können hier bestimmt noch eine Stunde über das ganze Thema sprechen. Du darfst gerne noch Themen ergänzen, wenn du noch was in deinem Skript hast. Ja, es ist ja erst eine rum. Also ich glaube, was ich so als Takeaway mit rausgeben möchte, ist eben wirklich nochmal zu überlegen, was für eine Art Anwendung baue ich da gerade. Nochmal auf dieser Relation zwischen dem, was ich darstellen möchte und der URL praktischerweise hinweisen, weil ich es auch bei uns oft genug merke,

dass wir eigentlich so eine klassische Multi-Page-Application in React nachbauen, wo man sagt, okay, auf dieser Seite ist nur die Nutzerliste und auf dieser Seite ist nur das einzelne Nutzerprofil, aber das in der URL oder sonst irgendwie gar nicht dargestellt wird. Dafür gibt es so viele magische Möglichkeiten, dass der Browser einem da so viel Hilfe schon abnimmt und dann wirklich zu überlegen, was ist hier der richtige Weg und auch gerne mal auszuprobieren. Also ich bin jetzt auch immer mehr dabei, dass ich glaube, in künftigen Projekten werden wir mehr von diesen Tools einsetzen, bestimmt auch mal inertia,

weil die Vorteile doch recht erschlagend sind. Es ist allerdings nicht was für jede Anwendung. Also wirklich, wie immer bei solchen Entscheidungen, genau überlegen, was brauche ich. Und ich hoffe, wir haben in der Folge heute genug Stichpunkte gegeben, um mal deine, liebes Zuhörers, Google-Suche zu bereichern. Total. Es gibt ja so viele andere Möglichkeiten noch. Wir haben ja in letzter Zeit viel, auch mit Filament zum Beispiel, gearbeitet. Als Frontend für Laravel-Anwendungen haben wir natürlich heute bewusst ausgeklammert, weil wir gesagt haben, wir wollen wirklich mal gucken, wie man ein React mit Laravel verknüpfen kann,

weil das eine Frage ist, die für mich eben sehr spannend war. Aber natürlich gibt es ganz viele andere Möglichkeiten und für jeden Anwendungsfall bestimmt einen ganz eigenen Kosmos an Tools, den man verwenden kann. Für jedes Projekt gibt es ein eigenes Framework fast. Ja, und das ist natürlich total schlau, für jedes Projekt einen anderen Text-Stack zu verwenden, damit man auch ja verwirrt ist und man sich in fünf Jahren total ärgert. Das wollen wir natürlich auch vermeiden. Ich esse jetzt noch als Finale dieses Stück Käsekuchen, was mich hier die ganze Zeit so anschaut. Ja, Kay, ich würde sagen,

ich lasse dich und deinen Käsekuchen mal alleine und danke dir für die ganzen Insights heute. Bitte schön. An das ein oder andere Thema knüpfen wir bestimmt an. Hier sei nochmal darauf hingewiesen, dass wir einen neuen Instagram-Kanal haben, wo immer noch nichts drauf veröffentlicht ist, glaube ich. Aber es werden so spannende Inhalte kommen, dass es sich jetzt schon lohnt, es zu abonnieren. Das ist unter at webcafépodcast. Alles klein, alles zusammen. Findet ihr bestimmt. Hat auch unser Podcast-Cover. Und Podcast-Cover ist nochmal ein eigenes Thema. Da sind wir dran, dass wir da ein schöneres machen.

Vielleicht ist das in dem Moment, wo das hier veröffentlicht wird, ja schon dann erstellt. Naja, Kay, für heute lassen wir es mal. Genießt die Sonne noch, genießt den Feierabend und wir hören uns in spätestens zwei Wochen. Hat mich gefreut, Felix. Tschüss. Mach's gut. Ciao, ciao.