Full Stack Dart

Hallo und herzlich willkommen, liebe Programmierer-innen zu einer neuen Programmierer-Folge, einem Deep Dive zum Thema Full Stack Dart. Worum es da geht, sprechen wir gleich. Ich bin Dennis, versuche ein bisschen durch das Gespräch heute zu führen und habe zwei bekannte Stimmen im Raum mit mir sitzen. Einmal –. Das bin ich, der Jojo. Den ihr aus den wöchentlichen News kennt und aus dem einen oder anderen Deep Dive. Und wir haben den Gabriel. Gabriel, auch dich, wenn man guter Zuhörer oder eine Zuhörende hier im Podcast ist, dann kennt man dich vielleicht auch schon. Zwei Mal warst du jetzt, glaube ich, schon dabei. Bist seit Anfang des Jahres Teil von LOTUM und gemeinsam seid ihr im Topics Team und Projekt. Das ist ja eines unserer Spiele, das wir im Jahr 2020 komplett neu geschrieben haben und da jetzt auf Flutter setzen. Und daher rührt ja auch die ganze DATE Expertise, die ihr euch über die Jahre aufgebaut hat bzw. Das ist eher in Richtung Jojo. Gabriela hat DATE auch vorher schon in anderen Kontexten bzw. Auch in Flutter, aber auch dort in anderen Kontexten noch eingesetzt. Wie geht es euch heute? Mir geht es gut. Danke für deine Nachfrage. Du bist gut hierher gekommen, oder? Ja, alles gut. Bist du heute aus Mönchengladen gereist? Ja, genau. Sehr gut. Die Bahn hat dich nicht durchgelassen. Sehr gut. Extra für den Podcast. Ja, zum Glück hat sich das ganz gut ergeben, dass du hier vor Ort warst. Also deswegen ist es cool, dass wir das natürlich hier zusammen vor Ort aufnehmen können und nicht irgendwie in einem Remote Setup. Und dir Jojo? Mir geht es auch gut. Halbwegs entspannt. So nach einem langen Wochenende. Sehr schön. Ich frage euch beide die gleiche Frage. Full Stack Dart. Einen Satz maximal. Was verstehst du darunter? Gabriel? Dart im Backend und im Frontend? Für mich auch natürlich Dart im Backend und Frontend oder vielleicht auch in verschiedenen anderen Bereichen. Man hat ja im Projekt-Kontext oftmals, das ist ja schon mehr als ein Satz, nicht nur das Backend und das Frontend, sondern so ein bisschen auch irgendwie drumherum. Aber auch dafür ist letztendlich DATE eine sehr geeignete Sprache. Okay, cool. Dann würde ich sagen, für alle, die noch nicht so viel Kontaktpunkte hatten zu DATE, fangen wir einmal an, noch mal ganz kurz einen Abriss zu geben, was DATE überhaupt ist. Wir haben vor Ewigkeiten, Januar 2021, also schon mehr als zwei Jahre her, schon mal eine Einführung zu DATE gemacht, Folge 81 unseres Podcasts, da noch mal ein bisschen tiefer einzusteigen, aber hat sich auch mit Sicherheit ein bisschen weiterentwickelt noch in der Zeit danach. Trotzdem lasst uns versuchen, gemeinsam mal einen ganz kurzen Abriss zu machen, was Dart eigentlich ist, wo es herkommt, wofür es geplant vielleicht war, wofür es heute eingesetzt wird. Wer möchte von euch? Ich beginne mal. Also DATE ist ja eine Programmiersprache, die im Jahre – jetzt muss man sich auf jeden Fall auf die DeepDive-Folge bezogen, also es ist schon relativ alt war, weil sie eigentlich ja mal für einen ganz anderen Kontext gedacht war. Das ist eigentlich entstanden, dass Google eigentlich einen Ersatz für JavaScript im Browser gesucht hat, weil eben da letztendlich natürlich auch diese Typ-Unsicherheit oder einfach nicht die vorhandenen Typen, also so als Problem erkannt wurden und sie eigentlich diese Programmiersprache geschaffen haben, einen Ersatz zu finden. Und gefühlt hatte ich auch Dart damals schon so auf dem Schirm, hatte mir das angeguckt und es gab ja zum Beispiel auch mal eine Chrome Version, die nannte sich Datum, die halt irgendwie diese Runtime auch integriert hatte im Browser, aber hat nie letztendlich dieses Promis eigentlich erfüllen können, dass da irgendwie so von den Entwicklern mal als Ersatz für JavaScript genutzt wurde. Und deswegen ist halt so dieses ganze Projekt wirklich Dat als Runtime, als Engine im Browser zu verankern, dann doch relativ schnell wieder eingeschlafen und man hat sich eher vom Team darauf konzentriert, dass man die Möglichkeit schafft, Datcode zu js Code zu entwickeln. Es gab zum Beispiel auch Projekte wie Angular Dat, die einfach versucht haben, das Angular Framework dann eben auf DATE umzusetzen. Das konnten wir dann über diesen DATE to. Js Compiler im Framework, ja im Web, dann auch ausführen. Und dann hat natürlich DATE jetzt durch Flutter, dieses Cross Platform Framework, was wir ja auch schon mehrfach hier thematisiert haben und auch in den News eben aufgreifen, natürlich dann ganz anderen Aufwind bekommen. Und für mich war erst mal auch Flutter vielleicht eine Technologie, die ich erst mal gar nicht so ernst genommen habe. Im ersten Schritt war ich gesagt: „Oh, die nutzen ja DATE, das ist ja eine tote Programmiersprache. Wir setzen auf so eine tote Programmiersprache und hatte erst mal auch so die Fragestellung, warum nutzen Sie DATEV? Und ist es letztendlich nur aus dem Kontext, dass es halt ein Google Produkt ist oder eine Google Entwicklung? Und sie nutzen jetzt für dieses Google Framework auch diese Sprache. Aber als ich mich dann so ein bisschen eingelesen habe, habe ich dann festgestellt, dass Sie ja DATE aus 20 Programmiersprachen ausgewählt haben. Also haben sich wirklich die Konzepte von verschiedenen Programmiersprachen angeguckt und einfach dann entschieden, dass DATE ihnen das beste Feature Set bietet, darauf letztendlich dieses Flutter Framework aufzubauen. Natürlich hat es wahrscheinlich den Vorteil gehabt dadurch, dass natürlich DATEI von einem Google Team entwickelt wird, dass ja auch bestimmte Eigenschaften wie das Wegfallen von einem New Konstruktor, also von New Keyword für die Konstruktoraufrufe dann weggelassen werden konnte, was ja das Flutter Team sich gewünscht hat, einfach besser diese Widget-Bäume definieren zu können. Also das hat wahrscheinlich auch einen gewissen Faktor natürlich in der Entscheidung letztendlich mit beeinflusst. Aber ja, so durch unsere tägliche Arbeit mit DATEV haben wir natürlich auch die Vorzüge selber irgendwie am eigenen Leibe oder durch unsere tägliche Arbeit einfach erfahren. Also für mich ist einfach so, DATE ist einfach sehr, sehr flexibel in den Möglichkeiten, wo man es ausführen kann. Und das war immer sozusagen der große Fokus, auf den sich das Team dann committed hat zu sagen, zum einen natürlich auf diesen virtuellen Maschinen ausgeführt werden. Also die DATEV-Form ist etwas, was sehr ähnlich letztendlich wie eine JavaScript VM funktioniert und einfach auch sehr performant Code ausführen kann und dort natürlich auf verschiedenste Systemen dann ausgeführt werden kann. Datev kann aber genauso natürlich Head of Time zu Maschinen Code kompiliert werden, was dann zum Beispiel auf den mobilen Endgeräten zum Einsatz kommt oder auch natürlich auch in Server Umgebung zum Einsatz kommen kann, wenn man das möchte. Da kann man auf beides setzen. Und ich habe eben die Möglichkeit dazu JavaScript zu transpilieren und das dann im Web auszuführen. Und bald auch zu Word und Web Assembly. Stimmt. Das ist natürlich auch ein interessanter Anwendungsfall, der bald kommen wird und wo sie jetzt sehr stark dran sind, auch irgendwie Definitionen zu erweitern. Gerade diese Garbatch Collection für Wlassum, die jetzt kommen wird, ist halt erforderlich, damit man endlich so eine dynamische Programmiersprache wie DATE mit Garbatch Collection eben dann auch in der Wlassum Runtime ausführen kann. Also initial für was anderes gedacht, populär geworden jetzt durch Flutter. Ist das mittlerweile komplett verknüpft miteinander? Also ist DATE und Flutter Entwicklung praktisch ein paralleler Strang und DATE ist hauptsächlich für Flutter und das sind da, wo die Features entstehen? Oder gibt es noch irgendeinen großen anderen Bereich, der Einfluss darauf nimmt, wie sich die Sprache aktuell weiterentwickelt? Also es sind eigentlich komplett unterschiedliche Teams, die selbstständig arbeiten und selbstständig auch Entscheidungen treffen. Wie DATE weiterentwickelt wird, ist nicht vom Flutter Team alleine irgendwie bestimmt, sondern die haben auch noch andere Nutzer in Google. Zum Beispiel Engie oder DATE wird heute noch in Google benutzt und von dem her ist es auf jeden Fall nicht ein Monolith oder ein Produkt, was nur noch an Flutter hängt, sondern ist immer noch eine Sprache, die separat weiterentwickelt wird und auch separat eine Zukunft hat. Ich glaube natürlich schon wird das stark von der Flutter Community beeinflusst. Also wahrscheinlich ist Flutter das x-fache größer als Engu oder Dart. Aber das sind, glaube ich, die Haupteinflussnehmer letztendlich auf die Sprache. Also man merkt schon, dass letztendlich sehr viele auch der Feature-Request natürlich von Leuten kommen, die mit Flutter Projekten arbeiten. Aber gerade wenn man sich das Ökosystem anguckt, es gibt ja bei Daten letztendlich dieses Pub-Dev, was so eine Package Registry ist, wo halt einfach dann Bibliotheken bereitgestellt wird, dass natürlich ein Großteil von dem, was man dort findet, eigentlich Utility Functions oder welche Funktionalität für Flutter ist und alles andere eher ein sehr kleiner Bereich ist und vielleicht auch vor Jahren mal entwickelt wurde. Also auch die Backend-Entwicklung, die Möglichkeit zu schaffen, dass man halt auch Server mit Daten programmieren kann, das ist schon vor Jahren entstanden, hat aber gefühlt jetzt sehr lange Zeit geschlafen und erfährt eigentlich durch die Beliebtheit von Flutter und auch vielleicht auch die Notwendigkeit von Flutter entwicklern. In irgendeiner Form ein Backend bereitzustellen, jetzt wieder deutlich ein Aufwind. Das ist vielleicht eine ganz gute Überleitung zu dem, was ja heute eigentlich Thema ist, weil Daten ist ja wie gesagt die Programmiersprache, worüber heute eher ein bisschen tiefer sprechen wollen, ist Full-Stack DATE. Das heißt DATE jetzt nicht nur in dem Flotter Projekt einzusetzen, sondern vielleicht auch noch in mehr Bereichen. Warum würde man das machen? Einfach nur, weil man dann irgendwie das cool findet und hat irgendwie Spaß an Dart und dann lass mal einfach überall probieren, wo es geht oder was ist die Motivation dafür ist. Das ist natürlich der Hauptgrund. Also natürlich ist es so, dass man wirklich gefühlt sehr viel Spaß hat an der Dart-Entwicklung. Und ich merke es zumindest immer, wenn ich irgendwie im Privaten JavaScript Projekt zurückkehre, dass ich schon sehr viel des Komforts, den man vielleicht in DATEV hat, dann vermisst. Und ich glaube, der Vorteil, den man einfach hat, darüber nachzudenken, dass es sinnvoll ist, dass man natürlich die Möglichkeit schafft, dass man eine einheitliche Programmiersprache zwischen seinem Flutter Client Projekt und den Code-Teilen im Backend hat. Und da ist es oftmals vielleicht auch gerade das Problem, dass manche semantische Ausdrücke sehr ähnlich zwischen DATEV und JavaScript sind, sodass man dann schnell durcheinander kommt, wenn man zum Beispiel sein Backend in Java oder JavaScript schreiben würde und es natürlich eigentlich einfacher ist, wenn man dann die gleiche Programmiersprache in beiden Kontexten vorfindet. Also das bedeutet einfach weniger, sagt man immer, Mentalload für den Entwickler, dass er einfach beim Wechsel zwischen Frontend und Client Code jetzt nicht unterschiedlich Programmiersprachen hat, sondern die gleichen, die gleiche Syntax hat und zum anderen auch natürlich die gleiche Runtime Bibliothek. Das ist nämlich der andere große Vorteil, dass es da eben die Möglichkeit gibt, diese Runtime Bibliothek ist halt was ganz anderes. Also in JavaScript gibt es natürlich ganz viele Packages, die so kleine Funktionalitäten bieten und da ist dann natürlich sehr viel ähnlicher wie ja, Kottland zum Beispiel, wo du ja auch eine sehr ausgereifte Runtime Bibliothek hast, wo sehr viele Funktionalitäten einfach von dieser Bibliothek abgedeckt werden und du deswegen dich auf einer höheren Ebene, sagen wir, deine Probleme, Aggregationsfunktion, Listenfunktion oder irgendwas kümmern musst und nicht gucken musst, was ist das entsprechende Package, was ich jetzt im JavaScript Umfeld habe, was ich erst mal dann einbinden muss. Und das heißt, dieses Pub-Dev, wo man die Packages hat, das ist kein Flutter Ding, sondern das gehört zu DATE. Ich glaube, das gibt es schon, schon bevor Flutter angefangen hat, DATE zu nutzen und ist nicht auf Flutter erst angewiesen oder gekommen mit Flutter. Ja, genau das ist eigentlich vorher schon mit DATE entstanden. Ich glaube nicht direkt irgendwie zusammen mit der Veröffentlichung von DATE und der initialen Intention, aber schon sehr zeitnah danach. Und jetzt setzt natürlich auch das gesamte Flutter Ökosystem eigentlich auf diese Package Registry, aber eigentlich ist sie für die grundlegende Sprache erstmal geeignet und auch natürlich kompatibel, wegen Mieke. Ein weiterer Grund, warum natürlich vielleicht DATE noch im Backend interessant ist, ist einfach auch die extrem gute Performance. Also es ist einfach so, dass dieser, ich glaube er heißt Lars Back, der ist ja auch der Gründer der Hotspot VM gewesen und der damals sozusagen im Google Team auch diese DATE VM genutzt, dann geschrieben hat. Und man hat einfach, wenn man sich bestimmte Benchmarks anguckt, eine sehr ähnliche Performance zu einer GO Runtime, was ja viele Entwickler von GO oder Liebhaber von GO sagen: „Ey, du hast einfach eine überragende Performance in dem Bereich, aber dass man dann realisiert, du kannst eigentlich mit Daten einer Sprache, die vielleicht einem schon eine andere Ebene, vielleicht einen anderen und objektorientierteren Zugang bietet, eben die gleiche Performance erreichen. Und das macht natürlich auch den Einsatz im Backend-System einfach interessant, weil wir natürlich dort davon profitieren, wenn wir einfach eine Sprache haben, die einfach sehr performant läuft und einfach möglichst wenig Ressourcen für jeden Request benötigt. Ihr arbeitet ja beide an dem Projekt 4 Bilder in Wort und da gibt es natürlich die Haupt-App und da die mit Flutter gebaut ist, ist da klar, dass da da drin ist. Aber soweit ich es mitbekommen habe, habt ihr auch versucht, viele andere Bereiche da Dart rein zu pressen. Ich bin ja immer ein bisschen vorweggegangen, einfach da über Nacht bestimmte Sachen umgeschrieben und dann so dem Team präsentiert. Habt ihr jetzt also ist das. Alles, was mit dem Projekt zu tun hat und Software, also wo Software entwickelt wird, ist es alles in DATE oder gibt es noch irgendwelche Bereiche, die ausgeklammert sind? Es ist also wir versuchen es eigentlich in alle Bereiche reinzubringen. Es gibt natürlich noch so ein paar Shell Skripte, die zu Beginn des Projektes entstanden sind, aber da sind wir auch in letzter Zeit gerade sehr viel dazu übergegangen, auch die zu überführen. Und eigentlich versuchen wir wirklich alles, was irgendwie möglich ist, irgendwie in DATEV Code. Also so was auch. Oder könnt ihr mal auflösen, was dann dazugehört neben der Flutter-App, also in welchen Bereichen ihr es jetzt schon einsetzt? Genau. Wir haben die verschiedensten Flutter Apps. Wir haben ja zum einen den native Client, also die ursprünglich für Bilder eine Word App, aber natürlich auch die Web Client, wo wir dann einfach diese Transferier Möglichkeiten verwenden. Aber das sind beides eben Flutter Ausprägung oder Ausprägung des gleichen Flutter Projektes. Dann haben wir dort natürlich jetzt alles, was mit dem Backend zu tun hat. Also da haben wir auch eine Microservice Architektur, die aber sehr reduziert ist auf die Hauptfunktionitäten. Also wir sind auch eigentlich Freunde davon eher zu einem Monolith zu gehen und sagen so was wie ein API Server ist wirklich ein Service, aber es gibt so was wie einen Image Service, der zum Beispiel sich für das Dropen von Bildern zuständig fühlt und das ist einfach ein getrenntes System. Also da sind alle Services in Daten inzwischen implementiert. Wir haben aber auch einen Bereich, wo wir selber unseren Code verwalten wollen oder das Projekt verwalten wollen. Das heißt, ein eigenes CLI gebaut haben. Weil natürlich gibt es da auch Tools. Ich glaube, da gehen wir später noch drauf ein, was es eigentlich für Möglichkeiten gibt, so ein Repository zu verwalten, wo wir aber auch gemerkt haben, da ist natürlich auch super zugänglich, sich eigene CLI-Tools zu schreiben. Es gibt, glaube ich, auch verschiedene Packages, die es inzwischen so ein bisschen anbieten und genau diesen Ansatz verfolgen. Da war auch auf einer der letzten Google Flutter Konferenz ein ganz interessanter Talk, dass eigentlich jedes Projekt seine eigene CLI verdient, halt einfach dem Benutzer da eine bessere Usability einfach zu schaffen. Und da hat man natürlich mit so einer ausdrucksstarken Sprache und vielleicht der gleichen Sprache, die ich auch in anderen Kontexten verwende, besseren Zugang, als wenn ich sage: „Okay, jetzt muss ich doch wieder irgendwie ein Shell Script bauen und mich vielleicht erst mal in die Syntax ein bisschen reinarbeiten. Ich war nie so ein Freund von Shell Script und habe vielleicht auch nicht so wie Gabriel da einfach so ein tiefes Wissen drin. Deswegen kommt mir das sehr gelegen, dort das Gleiche nutzen zu können. Und was wir jetzt auch noch gebaut haben, ist eigentlich noch ein anderer großer Bereich, wo es darum geht, die Daten von dem Projekt zu verwalten, also das, was eigentlich unter der Haube an Datenverwaltung passiert, wo unser Content Team so eine Art Admin Tool hat und dass wir dafür natürlich auch wieder ein Flutter Projekt haben, aber eben sehr stark darauf fokussiert, dass man einfach nur eine Menge von Daten darstellen kann und verarbeiten kann. Und ja, fast jedes Skript, also was wir auch noch haben, sind irgendwie eigene Bild Skripte, wo wir aktiv in den Bild Prozess der Flutter Projekte eingreifen, was wir eben komplett auf Daten aufgesetzt haben oder dass wir auch ein Tool haben, das nennt sich Fast Track, das haben wir irgendwann auch glaube ich mal in der News Folge irgendwiegeteilt, was eigentlich die Funktionalität von Fast Land, Open Source. Hat. Sehr viel zu tun. Aber war für uns halt einfach ein besserer Weg, als zu sagen: „Okay, jetzt habe ich hier diese Rubi Scripte. Ich glaube, Fast Land ist eine Rubi geschrieben und wir haben halt doch so spezielle Anforderungen an unseren Bildprozess, so viele Variablen und Eigenschaften, die verändert werden müssen. Je nachdem, weil noch mal zur Erklärung: Wir haben eine App, die in acht verschiedenen Sprachen und damit letztendlich in acht verschiedenen Apps ausgeliefert wird, weil wir einfach sehr viel Content, eben Bestandskonten mit in die App reinpacken und deswegen es halt sinnvoll war, weil jedes Land seine eigenen Rätsel braucht, dass man das eben auch von den Apps trennt. Und das war damals die einzige Möglichkeit, dass sicher vor zehn Jahren für Bild ein Wort gegründet war, das gut zu unterteilen und deswegen muss man da sehr viel letztendlich die Projekte anpassen. Und das ist auch letztendlich alles ein DATE Tool, dieses Fast Track, worüber dann letztendlich dann die Play Store API angesprochen wird oder die App Store Connect API angesprochen wird, unsere Builds dann zu pushen und diesen ganzen Release Prozess für uns als Entwickler einfacher und überschaubar zu machen, dass man alle Apps, zum Beispiel alle acht Apps parallel ausrollen kann. Genau. Und wenn man sich natürlich so ein Datenprojekt anguckt, dann ist es natürlich sinnvoll zu sagen: „Hey, wenn ich überall die gleiche Programmiersprache habe, dann macht es ja vielleicht auch Sinn zu sagen, ich packe das alles unter ein Repository, damit ich da auch diese Möglichkeit habe, Code zu teilen und auf einer gleichen Basis arbeite. Wir haben immer noch so ein bisschen die Trennung, weil wir doch im Client dadurch, dass wir allein unterschiedliche Plattformen ansprechen, da schon so eine sehr große Diversität haben. Wir möchten trotzdem so eine gewisse Trennung zwischen: Was ist das Backend? Was ist das Frontend? Vielleicht geben wir auch irgendwann dazu wirklich ein riesiges Mono-Repo zu haben, wo man dann einen Sharedfolder mit Modellen oder ähnliches hat. Aber erst mal war es für uns der Schritt zu sagen: „Wir möchten lieber dann noch mal eine Trennung haben, die Komplexität, die die einzelnen Teilbereiche jetzt schon haben oder diese beiden Bereiche, Backend und Frontend, noch ein bisschen auch von der logischen Struktur abzubilden und zu trennen. Genau. Und für diese Monorepos ist es eigentlich so, dass man da sich auch natürlich überlegen muss, wie verwaltet man das? Also wie ist das möglich, so ein Monorep zu bearbeiten? Und da gibt es, glaube ich, ein Tool, wo du auch aktiv mitarbeitest. Das nennt sich MELOS. Und ich glaube, das ist sehr inspiriert eigentlich von Lerner. Und Lerner ist vielleicht euch Entwicklern aus dem JavaScript entfällt vielleicht mehr ein Begriff, ist ja. Letztendlich ein. Tool, mit dem man Mono-Ripos verwalten kann. Also Mono-Ripo, das kennt man natürlich schon ein bisschen mehr, ist einfach ein GitHub-Repository oder von irgendeinem Versionskontrollsystem, wo man sagt, man hat da nicht nur ein Projekt drin, sondern man hat einfach mehrere Projekte unter dieser einen Haube, was es einfach einfacher macht, natürlich Code zu teilen oder auch Versionsstände miteinander zu synchronisieren. Und was macht MELOS eigentlich genauer? Ja, ich glaube, man muss ein bisschen unterscheiden zwischen einem Paket, was gedacht wird oder entwickelt wird zum Veröffentlichen und Paket, in der eine App entwickelt wird. Und MELOS ist eigentlich geboren aus dem Grund, dass man für das Flutter Fire Repository, wo die ganzen Feuerbase Pakete für Flutter entwickelt wurden, ein Tool brauchte, die Veröffentlichung zu automatisieren und die Change Logs zu managen und die Versionierung zu machen und auch das lokale Entwickeln zu unterstützen, dass man die lokalen Dependencys so umschreibt, dass man mit den lokalen Paketen, die aufeinander auch Dependencys haben, arbeiten kann und nicht so sehr aus dem Use Case geboren, jetzt Apps zu entwickeln. Was auch der Grund ist, warum wir letztlich wieder weggegangen sind von Mellos, zumindest in einem Monol Repository und in dem anderen noch vielleicht auch in nächster Zukunft wechseln werden oder weggehen werden zu unserer eigenen CLI. Aber die Hauptaufgabe von Mellos ist es zu erleichtern, solche Pakete, die ständig veröffentlicht werden, zu managen und diesen Prozess zu vereinfachen, diese Pakete zu Maintenaten. Also gerade was du jetzt eben erwähnt hast, dass man diese Abhängigkeiten irgendwie definieren kann, lokal überschreiben kann und zu sagen, da ist alles ein Stand. Aber nach außen hin will ich halt irgendwie sicherstellen, wenn ich jetzt ein Paket aktualisiere, muss ich ja eigentlich alle anderen Pakete, die auch diese neue Version dann von diesem gesharte Paket einbinden, aktualisieren. Und so was automatisiert dann eigentlich so was wie MELOS. Ich glaube, das ist dieser eine Aspekt, den natürlich MELOS bietet und das zweite ist natürlich auch, dass man über das gesamte Mono-Repository dann Befehle legen kann. Ja, man kann Skripte definieren, die man dann automatisiert in allen Paketen nacheinander oder parallel ausführen kann. Man kann auch filtern, sodass man nicht auf allen Paketen das ausführt. Oder man kann Filter definieren, die halt schauen, ob es über Testfolder gibt und dann nur in diesen Paketen Tests ausführt. Es ist halt nicht ganz so Power Full wie eine komplett, wenn du alles in Dart Code irgendwie regeln könntest. Und das ist auch so ein bisschen was uns, was bei uns die Limitierung ist, warum wir weggegangen sind von Mellos, ist etwas, was ich auch interessant finde, Mellos noch zu erweitern, sodass man mehr, dass man vielleicht Mellos erweitern kann, eigene Commands, sodass man praktisch eine CLI schreiben kann, die aber von Mellos gehostet wird. Aber das sind Sachen, die eher noch in der Zukunft sind. Ja, da gibt es ja Projekte, die das irgendwie aufgreifen. Weißt du gerade den Namen noch von Pascal Welsch, der das ja …? Ich bin letztens erst über …. Vielleicht. Kommen wir noch drauf. Ich weiß. Auch nicht mehr. Genau. Packen wir auf jeden Fall in die Show, noch zu Ende, dass das wieder einfällt, wie das Projekt heißt, aber die genau letztendlich so einen Ansatz verfolgen, wie wir das jetzt gemacht haben, dass wir gesagt haben, wir sind dann eben an die Grenzen von Mellos gestoßen. Mellos, das noch mal zu verbildlichen, ist da, dass man sagen kann: Ich führe in meinem Root letztendlich des Repositor einfach einen Testaus, dass ich sage Mellows Test aus, dass ich sage Mellos Test. Und es führt mich einfach in jedem Unterprojekt dann die Test-Suite aus, die ich dort definiert habe und dass ich auch andere Sachen machen kann, wie dass ich sage, ich will alle Sachen, die dynamisch gebaut werden, also durch so einen Buildrunner gebaut werden, anstoßen oder ähnliches. Also dass man einfach da eine zentrale Anlaufstelle hat, solche Sachen auszuführen. Und was der Gabriert eben schon ausgeführt hat, wir hatten vor allem die Situation, wir haben gewisse Abhängigkeiten. Wir haben dieses Share-Paket und dieses Share-Paket muss gebaut sein, bevor irgendwelche Plattform-Metriken entstehen, die halt wieder User-Faces sind, dann gebaut werden. Und das war halt mit Melov so, dass man das halt sehr explizit definieren musste und wir eigentlich gesagt haben, eigentlich würden wir gerne mehr Flexibilität haben, solche Abhängigkeiten einfach an einer Stelle zu definieren und alle Prozesse, alle Flows, die darauf aufbauen, die können sich auf diese Informationen dann greifen. Also was wir dann geschaffen haben, ist einfach so eine Art, ja, ein weiteres Package, was wir irgendwie CLI oder Tool nennen, wo wir einfach da eine Reihe von Befehlen irgendwie anbieten. Und das sind dann so Befehle wie zum Beispiel auch einfach, füge jetzt in jedem Unterprojekt Flutterpapier aus? Das kann natürlich Mailos auch sehr gut. Aber zum Beispiel auch, baue mir jetzt die App jetzt für eine bestimmte Plattform zusammen, link da bestimmte Informationen mit rein. Und da habe ich natürlich dann wieder durch die Flexibilität einfach von Daten halt die Möglichkeiten, sehr viel mehr zu machen. Und wenn ich mir so was in einem Shell Script zusammenbauen müsste, das wäre vielleicht eine weitere Option, dass ich mir einfach eine Reihe von Shell Scripten letztendlich irgendwo in einen Ordner lege und die dann ausführe, bin ich gefühlt immer so ein bisschen mehr gebunden an das, was mir letztendlich diese Shell Sprache bietet. Gabri, Jojo meinte eben, du hast doch früher schon viel Erfahrung mit CLI Tools gehabt. Ich weiß gar nicht, wie man anfängt sowas zu entwickeln. Jetzt in der Frage, also keine Ahnung, jetzt ist erst mal nur eine Programmiersprache da, jetzt ist DATE und im Flutter-Kontext kann ich mir das noch vorstellen. Da gibt es ein Framework außen rum. Das ist alles zusammen. Ich kompilier das und es kommt irgendwas raus. Was gibt es denn dann für eine Grundlage in DATE, ein CLI Tool zu erstellen? Ist es dann von Scratch oder gibt es da auch dann praktisch eine fertige Umgebung, CLI Tools zu bauen? Es gibt ein Paket, was auch vom DATE-Team kommt für genau den Zweck, CLI Tools zu bauen. Das heißt, glaube ich, ARX, was eben das ganze Passing für dich übernimmt, die CLI Argumente in Optionen zu passen, die du dann verwenden kannst, Commands zu bauen. Und damit ist es wirklich einfach, Commands mit Unter-Commands und allen möglichen Variationen zu bauen. Das ist auch was wir nutzen. Das heißt, du hast dann einfach ein Datenprojekt und da hast du diese Abhängigkeit zu dem AX Ding und das reicht, letztendlich ein CLI Tool zu bauen. Genau. Was dieses ARCH Tool anbietet, ist einfach so eine Art Command Basisklasse, was einfach bestimmte Funktionen anbietet. Die leitet man dann einfach ab und man kann das dann einfach zusammenstöpseln. Letztendlich wird alles dann nachher in eine Data Datei gebündelt, die man dann entsprechend aufrufen kann. Und dann ist es auch so, wenn man zum Beispiel automatisch, dann kommt die Funktionalität mit, dass man so eine Minus Minus Help Option hat, wo er einfach auflistet, das sind jetzt alles Sub-Commands, die du in einem Haupt-Command definiert hast. Was sind die Parameter für das Sub-Command? Also alles das, was du halt brauchst, so eine CLI zu definieren, die man auch so ein bisschen inspizieren kann. Was ist überhaupt die Funktionalität, die ich jetzt habe? Und ist da so fancy Staff drin? Keine Ahnung, man schickt die CLI ein, dann gibst du was ein, dann kommt da so ein Ladebalken und irgendwelche lustigen Animationen oder ist das was, was man selbst machen muss? Da gibt es andere Pakete, die einem dabei helfen. Auch so Farben zu verwenden und Animationen oder so Ladebalken. Da gibt es aber auch Pakete dafür. Gefühlt ist das im JavaScript, gibt es da schon Pakete, die irgendwie besser sind und das irgendwie auch fancyer und irgendwie integrierter abbilden. Also es gefühlt so, dass man sich das in Daten noch so ein bisschen zusammenstöpseln will. Also die meisten unserer Tools sind wirklich hier, Black and White und geben die Sachen so aus. Ich habe das nur in einem Tool, dass ich so gewisse Farbausgaben irgendwie reingemacht habe und das war komplizierter als gedacht, deswegen reduziere ich mich da lieber auf die Basis funktioniert. Aber das funktioniert sehr gut. Und ja, das andere Thema hatte ich, glaube ich, vorhin schon ein bisschen angesprochen, auch ein großer Bereich, wo wir einfach diese Scripting Möglichkeiten von DATE bieten oder nutzen, ist halt eben diese Custom Build Scripter. Also es ist eigentlich ein großer Bereich unterhalb unserer Flutter Projekte, wo halt sehr viel angestoßen wird. Also da ist es auch ganz interessant, was vielleicht nicht jeder weiß. Also man hat ja die Möglichkeit über Flutter Flavors, ich glaube das nennt sich auch Flavors, irgendwie eigentlich in einem Flutter Kontext sein Projekt Flavor spezifisch anzupassen, dass du sagst, ich habe jetzt eine Version für den englischen Markt, für die deutsche Markt, ich habe da andere App Icons, ich habe irgendwelche Inhalts Dateien oder Content Dateien, die sich verändern. Aber das war für unseren Anwendungsfall einfach zu eingeschränkt. Was man aber hat, die Möglichkeit, ist über die sogenannten DATEFINE. Datefine ist etwas, was man einfach zum Beispiel beim Bauen eines Flutters-Projektes dann dem Flutter-Befäh mitgeben mitgeben kann. Und diese Information ist auch etwas, was zum Beispiel dann auf der Android-Seite dann in der Gradle-Datei zur Verfügung steht, wo man diese Informationen auslesen kann. Ich kann zum Beispiel sagen, in unserem Fall, ich baue jetzt die deutsche Version, dann habe ich ein Daten-defined app_langreach = de und auf diesen app_langreach-Parameter kann ich dann in mein Gradle Script eben reagieren und kann sagen, nutzt die Informationen, das eine oder andere zu machen. Und wie übergeben diese Informationen dieser DATEV-Finds eigentlich einfach dann an die Daten-Skripte, die wir aufrufen? Und dort können wir einfach dann sehr flexibel natürlich darauf reagieren und sagen Okay, wenn ich jetzt die deutsche Version baue, dann brauche ich noch andere Inhaltsdateien, muss andere Inhalte anders zusammenstellen, anders aggregieren, dann für jede Sprachversion dann eine eigene Operation zu machen. Und das sind da einfach auf beiden Seiten auch genauso letztendlich im Exportprojekt. Da liegt es glaube ich eher in den Schemes, hat man da genauso die Möglichkeit, auf diese DATEFINES zuzugreifen. Und so kann man noch sehr viel flexibler letztendlich seinen Buildprozess gestalten. Ich glaube, diese DATEV ist etwas, was es nicht nur dort gibt, sondern was eigentlich bei jeder Ausführung von einem DATE Programm mitgegeben werden kann und Dinge beeinflussen könnte. Ja, das sind eigentlich so Compile Time Konstanten, die übergeben werden können. Aber dieses ganze Thema Flake, was ist auch was, da gibt es einige Issues im Flutter Repository, wo Leute sich eben genau solche Sachen wünschen, die wir auch verwenden oder brauchen. Und das ist was, wo auf jeden Fall noch Potenzial existiert, im Flutter Tool da sich zu verbessern. Ja, sonst muss man es eben komplett selber machen. Aber an der Stelle am besten mit Daten. Das ist aber was anderes als Fast Track, was du eben angesprochen hast. Ich hatte irgendwie im Kopf, Fast Track ist ja auch, dass wir diese unterschiedlichen Sprachversionen haben und irgendwie managen, dass das irgendwie hinkommt und so, aber das ist ein. Anderer Schritt. Ja, duWas wir halt mit diesen Build Scripten machen, ist erst mal, dass wir natürlich dann die fertige Binnary eigentlich lokal bauen und dann geht Fast Track hin und hat diese Binnary, die wir mit den Build Scripten gebaut haben und lädt sie dann einfach hoch, weil es der Push dann letztendlich diese IPA oder APK dann einfach gegen den AppStore und stößt halt da den Release Prozess an, stellt halt bestimmte Sachen ein. Und habt ihr das noch mal gerappt in irgendeinem anderen Script? Oder sind es wirklich? Also wenn ihr jetzt eine App releast, ist das ein Befehl, der dann eure Custom Build Scripte anstößt und dann über Fast Track das zu Google Play hochlädt? Oder sind das schon noch zwei Mal ein Befehl. Den ihr eingibt? Ja, es läuft ein bisschen anders. Das ist natürlich alles so eine CICD Pipeline aufgehängt, dass wir sagen: Okay, wir lassen eigentlich von Code Magic letztendlich unsere IPA Sachen dann bauen und dann wären die automatisch. Also das bietet einfach einfach Code Magic als Test-Leitbild zum Beispiel im AppStore Connect hochgeladen und wir gucken dann eigentlich nur, wir sprechen die API letztendlich von AppStore Connect an, ist diese IPA da, kann ich daraus letztendlich einen Release bauen, dann fügt mir die ganzen Release Informationen hinzu und Ähnliches, also den Chain Stock hinzu. Und das macht letztendlich dann Fast Track. Aber das andere ist. So ein bisschen weit ausgelagert. Die eigenen Build Scripte, die liegen dann praktisch in Code Magic ausgeführt? Genau, die werden in Code Magic dann ausgeführt. Also eigentlich ist es so, dass ich einfach nur ein Flutter Run Bild mache. Und diese Flutter Run Bild stößt dann sozusagen intern einfach diese Custom Build Scripte an. Also wir nutzen schon die Shell, die uns Flutter bietet, zu sagen ich füge jetzt mein Build aus, aber während dem Build greifen wir sozusagen diesen Prozess ein und sagen, bevor du jetzt wirklich die APIKabel ausführt, bitte vorher das und das und das noch aus. Und das führt auch dazu, dass ihr mit einem Flutter Run Build baut ihr dann standardmäßig alle Flavors, alle Apps? Nee, das ist schon so, dass du eigentlich sagst, der Default App Language Parameter ist irgendwie DE und wenn wir den die englische Version, müssen wir das explizit übergeben. Und das heißt, das wiederum sind dann einzelne Schritte, die in Code Magic beispielsweise hinterlegt sind, dass es für jede App. Einmal diesen. Schritt gibt mit dem. Jeweiligen … Mit dieser Spezifikation für welche Plattform und Sprache. Genau. Also eigentlich bauen wir jedes Mal, wenn wir eine App releasen wollen, weil wir acht Sprachversionen haben, A2 Plattformen, halt 16 unterschiedliche Apps, die wir. Dann verteilen. Das dauert dann auch immer. Eine Stunde. Genau, es läuft dann ein bisschen, bis es dann fertig ist. So, also CLI's, Fast Track, Skripte, was noch? Es gibt den anderen großen interessanten Bereich, nämlich dann natürlich zu sagen: „Hey, natürlich hat fast jede App, die heutzutage entwickelt wird, in irgendeiner Form ein Backend. Und früher waren unsere Backends da viel in Java und das ist eigentlich so ein bisschen der Prozess gewesen. Wir sind eigentlich gestartet, dass wir erst mal gesagt haben, wir migrieren erst mal nur die Flutter-App und haben aber immer noch unser Java Backend, wo wir dann immer gemerkt haben: „Okay, manche waren auch bestimmte Bestandteile des Codes gar nicht mehr vorhanden, irgendwo in alten Repositories verschollen, weil man diese Teile auch oftmals nicht anpassen musste. Und wir haben es einfach natürlich mit diesen Rewite of Flutter geschafft, dass wir einfach so von der Feature-Entwicklung in ganz neue Bereiche reingehen, auch neue Backend-Funktionalitäten brauchen. Und da war irgendwann die Überlegung – und das war auch gefühlt immer sehr mühselig – ein bisschen alten Code, Java Code auch anzupacken: „Hey, wie wollen wir das irgendwie erneuern? Wo meine Idee von Anfang an war zu sagen, eigentlich würde ich am liebsten natürlich ein DATE Code haben. Wir haben in vielen anderen Projekten natürlich genau die gleiche Korrespondenz. Wir nutzen JavaScript im Frontend, nutzen dann Node. Js im Backend mit JavaScript. Und dann habe ich mich einfach intensiver mit dem Thema beschäftigt und bin erst mal ein bisschen stutzig geworden, dass es da gefühlt relativ wenig gibt, auf dem man aufbauen kann. Also es war einfach eine ganze Phase, dass ich erst mal so Recherche betrieben habe. Was gibt es denn für Frameworks? Und ich glaube, da kann man erst mal so ein paar letztendlich herausnehmen. Also was man halt feststellt, diese ganze Serverentwicklung ist halt damals mit eigentlich DATE entstanden. Da gab es so einige, ich glaube zwei, drei Frameworks, die ja vielleicht auch weit genutzt wurden, die auch schon sehr viel Funktionalität irgendwie geboten haben, aber wo man heute merkt, da ist eigentlich gar kein aktiver Container mehr hinterher. Also der letzte Commit, der auf dem Repository ist sieben Jahre alt. Da kann man nicht erwarten, dass da irgendwie in Zukunft noch irgendwas passiert und deswegen natürlich keine Option ist, da ein aktuelles Projekt drauf aufzusetzen. Bevor wir da gleich noch ein bisschen mehr im Detail drauf eingehen, könnt ihr ganz kurz skizzieren, was so Funktionalitäten von dem Backend sind? Also ist es ist irgendwie, keine Ahnung, ist eine Datenbank und man hat ein API Call und kriegt einen Nutzer zurück oder was ist jetzt hier. Die. Wichtigsten Funktionalitäten für das Backend in dem spezifischen Projekt von FIBIL dein Wort? Ja, also es ist eigentlich ein API Server, der halt eine HTTP REST API zur Verfügung stellt für die Apps und teilweise für unsere Verwaltung, für die App, mit der wir den Content verwalten. Und der muss halt auf Redis und auf Postgrease zugreifen können. Das sind so unsere Datenbanken, die wir verwenden im Hintergrund. Und alles, was dazwischen ist, fängt halt an bei Shell. Also das ist das Paket, was wir nutzen, den Server aufzubauen. Und dann haben wir verschiedene Services und erst mal Controller, dann Services, die dann letztendlich auf Repositories zurückgreifen, die dann die Datenbanken ansprechen. Und was wir halt brauchen dafür, sind die Treiber, die irgendwie mit den Datenbanken kommunizieren können. Und da gibt es auch für PostgreS ein und für Redis auch, die auch Mintain sind. Aber für alle anderen Datenbanken ist es ein bisschen schwieriger. Also für MongoDB gibt es zum Beispiel glaube ich keine. Ja, ich glaube, da können wir auch gleich noch ein bisschen tiefer darauf einsteigen, was es so an Möglichkeiten gibt, mit der Außenwelt zu kommunizieren, wie von meinem einzelnen Daten-Server. Also du hast es schon ganz richtig genannt. Also ein großer Bereich ist natürlich so, dieser API Server funktioniert nicht. Ich habe eine API, die ich von den Clients aus ansprechen will. Was wir natürlich auch noch dabei haben, ist so eine Art, eigentlich ist es eine Art Cron Service. Also Cron sind ja irgendwie Operationen, die einfach zyklisch im Hintergrund laufen oder durch irgendwelche Operationen, andere Schritte, Prozesse angestoßen werden, wo wir dann auch gesagt haben, auch das ist irgendwie ein Service, der nennt sich dann irgendwie Task Service. Der wird bei uns letztendlich von einer Google-Infrastruktur angestoßen. Da gibt es Google Cloud Queues oder Task Queues, wo man einfach sagt, man packt eigentlich einen HTTP Call auf eine Queue und der kann letztendlich ein gewisses ETA haben, also ein Datum wann er ausgeführt werden soll. Und in dem Moment ruft er einfach halt irgendwie auch wieder eigentlich einen API Service auf. Also eigentlich ist es nichts anderes, aber von der Definition her kriegt er natürlich dann so ein Datenpaket, wo halt drinsteht, du musst das und das machen, bitte führ jetzt das aus. Also so eine gewisse Vorschrift hat, was eigentlich gerade passieren soll zu dem Zeitpunkt. Und was man an der Stelle noch hat, sind vielleicht gleich kleine andere Services, die dann nur Kommunikation mit einer externen Schnittstelle, zum Beispiel mit irgendwelchen Facebook Diensten oder ähnliches machen. Das ist eigentlich das, wo wir zum großen Teil natürlich das nutzen und eben hast du es ja schon ausgeführt. Also unten drunter haben wir dann eigentlich nur noch eine Caching Schicht, halt bestimmte Daten, die wir halt ständig brauchen, nicht ständig, also immer auf der Datenbank zu laden und eben dann noch eine Datenbank Schicht, halt wirklich die Daten strukturiert vorzuhalten. Und jetzt so einen simplen Webserver in Anführungsstrichen hinzustellen oder einen API Server hinzustellen, da braucht man dann auch einfach oder nutzt man irgendein Package, was es dann gibt. Das ist dann vergleichbar mit wie, weiß ich nicht, Express oder sowas in der JavaScript Welt. Sowas gibt es dann einfach als Äquivalent für Daten. Also genau da gibt es verschiedene Ebenen. Und ich glaube, wir können mal anfangen, so ein bisschen zu skizzieren, was es da gibt oder was vielleicht sinnvoll ist. Also wenn ihr irgendwie Interesse habt, irgendwie Daten im Backend zu verwenden, was sind die Pakete, die wir so identifiziert haben, dass sie auch aktiv Maintenent werden, dass da Entwicklung passiert, die vielleicht auch neu jetzt mit Flutter entstanden sind. Ich glaube, eins, was man auf jeden Fall nennen sollte, ist Konduit. Konduit ist eigentlich ein Fork von Aqaduct und Aqaduct war eigentlich damals so dieses renommierteste und auch gefühlt so von der Funktionalität einfach am weitentwickeltste DATE Server Framework, was man hatte. Also es wird sehr viel Funktionalität, wie gehe ich mit Sessions um? Wie mache ich vielleicht auch mit Zugang zu meinen Caching Ebenen? Wird dort irgendwie angeboten, also dass man da einfach gefühlt nicht nur so auf diesen Bär-Bonds, ich kriege irgendwie einen Request, hatte einen typischen Request rein und gibt eine Response zurück und alles dazwischen muss ich irgendwie selber bauen, mehr Komfort bietet. Aber genau dieses Equity Produkt wurde nicht weiterentwickelt. Jetzt ist es ein Community Produkt, wo man sagen muss, die Dokumentation ist okay. Gefühlt ist es trotzdem aber nicht so das, wo jetzt die meiste Entwicklung gerade rein fließt, also wo jetzt viel passiert. Es ist auf jeden Fall so in Verwendung. Ich glaube nicht bei wirklich großen Projekten. Aber was zum Beispiel interessanter ist und wo es auch sehr spannende Talks auf den letzten Stadtteilkonferenz gibt, ist Server Pod und auch ein Projekt, was wir erst mal initial genutzt haben, weil das verspricht eigentlich einem sehr viel dieser Funktionalität, wie ich eigentlich mein Server schreibe und mein Client dazu schreibe, zu übernehmen. Also was es halt sagt, ist erst mal, dass es eine automatische API-Generierung macht. Das heißt, das einzige, was ich eigentlich machen muss, ist, dass ich meine Endpunkte definiere und sage: „Okay, das sind letztendlich die Parameter, die an diesen Endpunkt übergeben werden, das ist der Rückgabewert und alles andere ist letztendlich etwas, was dann generiert wird. Also das nutzt dann auch wieder dieses Buildrunner Package. Aber ich habe dann die Möglichkeit, einfach durch diesen Generate-Befehl zu sagen: „Okay, generiere mir meinen Client Code, und was halt da eine gewisse Beschränkung war, die halt nachher für uns auf jeden Fall diese Limitierung war, wodurch wir sie dann nicht mehr nutzen konnten, dass man da sehr stark beschränkt ist eigentlich von den Datentypen, die man nutzen kann. Also es hat einfach eine Unterstützung fürBücherwerte, Integerwerte, Double, Strings, Datum und Byte Data. Und man kann natürlich Listen und Maps von diesen Typen definieren, aber andere Typen werden erst mal nicht unterstützt. Und vor allem man kann aus diesen Datentypen wieder dann auch eigene Modelle definieren. Und diese Modelle werden erst mal in YAML-Dateien definiert, wo man einfach sagt, man hat so einen Ordner, man liegt letztendlich für jede Klasse, für jede Entität, die man definieren möchte, irgendwie da eine eigene Datei an, da kann man den Klassennamen definieren und einfach die Liste von Feldern, die halt dann einfach eine Ausprägung von diesem Typen sein muss oder auch eine Liste oder eine Map. Man hat auch die Möglichkeit, letztendlich dann ein bisschen die Serialisierung zu beeinflussen. Und aus diesen Definitionen wird einfach zum einen das Modell definiert, also wirklich die Entität. Es wird dann auf Client und Server Seite die entsprechenden Modelle natürlich abgelegt oder in einem beschertem Verzeichnis dann eben abgelegt. Und an der Stelle wird auch für die Datenbank Ebene, weil das ist etwas, was auch bei Server Pod eben vorgegeben ist, wird das entsprechende Datenbankschema definiert. Das heißt, ich kann eigentlich an der Stelle nur gegen eine Postgreif-Datenbank kommunizieren. Der definiert mir auch oder generiert mir auch die entsprechenden Table-Schemas, kann die vielleicht auch direkt auf der Datenbank ausführen. Was er auch anbietet, ist, dass er eine Caching-Schicht bietet und sagt: „Ich kann diese Daten auch in dem Cache vorhalten oder irgendwie dann reinsetzen. Das liegt oftmals direkt am Session Objekt. Aber ich bin so ein bisschen beschränkt, weil er generiert mir ein ORM, was mir dann zum Beispiel solche Methoden wie Insta Update und find by ID oder auch Finden nach anderen Kriterien irgendwie anbietet. Das ist das, was automatisch generiert. Ich kann das natürlich auch erweitern, aber ich bin letztendlich schon darauf festgelegt, wie diese Sachen zusammenlaufen und habe da gefühlt dann irgendwann zu wenig Einflussmöglichkeiten, diese Generierung und auch genau das Aussehen der Dateien noch zu beeinflussen. Und was vor allem bei uns dann zum Tragen gekommen ist, Beziehungen zwischen Objekten abzubilden, bietet es erst mal nur one to one oder one to many Relationships, also so eine Child Parently Relationship, aber keine money to money Relationships, die halt doch in einigen unserer Modelle eben notwendig waren. Und auch einfach so von den Datentypen war es eben so, dass das irgendwann nicht mehr ausgereift hat. Wir hatten sehr ausgereifte Prototypen, wo wir erst mal auch gedacht haben, es funktioniert. Aber als wir dann mal in den konkreteren Anwendungsfalle mit Server Pod gegangen sind, haben wir einfach gemerkt, für unsere Komplexität der Daten war es eben nicht ausreichend, die Möglichkeiten, die man dort hatte. An sich bietet es aber super viele Features, also hat so diesen eingebauten Caching-Mechanismus, den ich eben gerade angesprochen habe. Du hast auch direkt die Möglichkeit, solche Storage-Provider anzubieten, Dateien zum Beispiel auf Office 3 oder Google Cloud abzulegen. Ich kann direkt Authentication-Provider irgendwie einbinden. Ich habe auch die Möglichkeit für Unterstützung von WebSocklets, so dass ich so eine Art Data Streaming, wenn ich irgendwelche Live-Updates auf meinem Client brauche, dann einbauen kann, was auch sehr schön eigentlich gerappt ist. Also von der API und der Dokumentation ist das Projekt wirklich super. Ich habe die Möglichkeit auch Task-Creat-Tooling auszuführen, das heißt, dass ich auch dort letztendlich keine Cron Jobs brauche, sondern das alles letztendlich in dieser Server Pod Struktur definiere und der sich unter der Haube drum kümmert, wie er diese Sachen ausführt und eben anstößt. Hilft einem Server Pod dann eigentlich auch dabei, diese Modelle, die man dann definiert, im Client zu verwenden, also einen Client zu generieren oder. Irgendwie sowas? Genau. Also das macht er eigentlich komplett, dass er wirklich so einen Client mit Interface bietet, zu sagen, ich habe jetzt irgendwie einen Service, der jetzt mit dem Backend kommuniziert, wo ich irgendwelche Request-Objekte übergebe, die ich definiert habe und ich kriege das Response Objekt zurück. Er generiert die natürlich eigentlich so, dass es einfach wirklich gesharte Modelle sind und erst mal aus einer Form von einem Beispielprojekt, dass irgendwie Client und Backend Projekt in Richtung I-Monoripen liegen. Unddass halt einfach das Modell zwischen Client und Server dann geteilt werden kann. Das ist alles das, was er generiert. Es ist schon sehr automatisch. Er generiert natürlich genau diese Entsprechung, die er auf dem Server vorfindet, in diesen Endpunktdefinitionen, dann eben für den Client. Aber schafft natürlich da eine Einfachheit, die wir uns natürlich einfach wünschen oder wo wir auch so was wie OpenAPI früher sehr viel genutzt haben, wo wir gesagt haben, wir haben irgendwie einfach einen Endpunkt in irgendeiner Form generiert er dann diese OpenAPI. Json-dateien. Auf der anderen Seite habe ich dann wieder ein Tool, was mir einfach mein Client Projekt aus generiert. Und ich habe einfach nicht diese Notwendigkeit manuell Client und Server die Definition, die APIs irgendwie konsistent zu halten und muss mich irgendwie darum weniger kümmern. Ich habe eigentlich immer nur die Veränderung, erst ein Backend Projekt, dann erzeuge ich mir einfach das Client Projekt neu. Wenn dann irgendwas von den APIs nicht stimmt, muss ich das im Client natürlich fixen. Aber eigentlich habe ich nur eine Quelle der Wahrheit, die einfach im Backend dann bei den Endpunkt Definition sitzt. Server Pod ist es aber nicht geworden. Server Pod auch nicht. Und ja, ein anderes Projekt, glaube ich, bevor wir darauf eingehen, was das letztendlich geworden ist, sollte man noch erwähnen, weil es ein recht neues Projekt ist und gefühlt auch in letzter Zeit so sehr viel Anklagen in der Flutter-Dart-Community findet. Das nennt sich DarkFrock und wird von very good Ventures implementiert. Und very good Ventures, ich weiß gar nicht, sie sind auch so ein großer Begriff. Auf jeden Fall. Nehmen wir sehr viele Vorträge auf den Flutter Konferenzen. Ich glaube, die machen so Flutterentwicklungen für externe Kunden, beteiligen aber sehr viel auch an Ökosystemen. Ich weiß auch nicht so viel dazu, wie genau diese funktionieren, aber sie machen super viel in der Open Source Community und in Open Source Projekten. Und haben. Da auch sehr viele interessante Bibliotheken. Und Dartfrock ist eigentlich ein Zusammenschluss zwischen Shelf und Macean. Und Maceon ist ja so ein Tool, mit dem man einfach so bestimmte Skripte irgendwie automatisieren und zusammenfassen kann. Und Shelf ist letztendlich etwas, was wir gleich auch noch im Detail uns anschauen, was wirklich so diese Grundlage ist. Und vielleicht, das Beispiel oder die Referenz zu bieten zu dem, was vielleicht so ein Express. Js irgendwie in der JavaScript Welt ist und hat Ähnlichkeiten, wenn man aus dem JavaScript Umfeld kommt, eigentlich mit Remix oder Next. Js, also dass man dort eigentlich ein Opinionated Framework hat, was bestimmte Definitionen einfach vornimmt, aber dafür dem Nutzer halt eine sehr einfache Struktur oder dann bestimmte Dinge einfach übernimmt. Also es ist zum Beispiel so, dass man einfach sagt, jede Route liegt in der eigenen Datei und eigentlich wird über die Paketstruktur, die Verzeichnisstruktur festgelegt, wie diese Routen verschachtelt sind und wie aufgerufen werden kann. Also ich kann zum Beispiel einfach da eine Datei irgendwie ablegen, die heißt Hello. Date. Das heißt, damit habe ich automatisch an meine API einfach einen Endpunkt / Hello, den ich aufrufen kann. Und was diese Datei enthalten muss, ist einfach eine On-Request-Methode. Und eben, ja, ich bekomme ein Shell Request als Eingabeparameter, gibt eine Shell Response zurück. Also da bin ich wieder auf der Shell-Ebene, auf die wir gleich gehen, aber übernimmt sozusagen das ganze Handling. Wie sind eigentlich meine Routen definiert und zusammengestöpselt? Ich habe auch die Möglichkeit, da dynamische Parameter mit anzugeben. Das ist auch sehr ähnlich, wie es halt zum Beispiel im Remix jetzt gelöst ist, dass ich einfach da mit eckigen Klammern sagen kann, ich habe eine Datei, die heißt zum Beispiel Hello Slash und dann eckige Klammer auf „name, eckige Klammer zu „dart, und dann weiß ich einfach, ich habe einen Parameter, der „name heißt, den ich dann von außen übergeben kann und den habe ich dann in meinem Request Objekt als Parameter, als Query Parameter dann zur Verfügung und kann den an der Stelle eben auslesen und zurückgeben. Das heißt ja, dafür ist es einfach diese Konvention, was ja viele andere Tools wie Next. Js oder auch Next. Js auch machen, dass sie sagen, eigentlich ist letztendlich die Verzeichnisstruktur dafür zuständig oder definiert, wie meine Routen organisiert sind? Ja. Ich hänge gerade noch ein bisschen im Kopf, aber das ist eher mein Unwissen zu den grundsätzlichen Projekten, dass man da von dem Routing auch dann im Backend spricht. Das ist einfach, dann meine API zu strukturieren. Genau. Weißt du, du hast zum Beispiel einen Endpunkt, der heißt irgendwie oder einen Oberpunkt, wie du es bei REST oftmals hast. Weißt du, du hast eine Ressource, die zum Beispiel irgendwie Puzzle heißt. Ich möchte... Ich möchte die Puzzles irgendwie lesen, schreiben, updaten. Und natürlich unterstütze ich erst mal diese ganzen HTTP Methoden. Das wird auch von DarkFrock eigentlich unterstützt. Aber ich habe dann zum Beispiel einen Unterpunkt, der heißt dann „Puzzle. Images. Und damit kann ich direkt irgendwie auf die Bilder zugreifen. Und das ist einfach nur, wie man natürlich auch in REST einfach sagt: Ressourcen bilden eigentlich eine hierarchische Struktur ab, da ein bisschen mehr Klarheit zu schaffen. Und das ist einfach das, was du letztendlich bei DarkFrock einfach dann sagen würdest. Du hast einen Ordner, der heißt wie Puzzle. Da liegt dann irgendwie eine Index. Da Datei drin. Aber es gibt auch eine Unterdatei, die heißt irgendwie Images oder ähnliches. Das hat ja eigentlich nichts mit dem Frontend zu tun. Also wenn du in anderen Projekten hast oder in einem Web-Projekt hast du zwar auch das, also ein ähnliches System, aber hat damit nichts zu tun, dass du ein Routing hast, irgendwie auf die unterschiedlichen Seiten zu kommen. Aber okay, das ist dann einfach nur die Struktur, die Daten oder die passenden Routen im. Backend festzulegen. Genau, zu machen. Du hast da genau die Möglichkeit, irgendwie Middleware zu definieren. Middleware ist ja immer irgendwas, was letztendlich deinen Request beeinflusst, wo du sagen kannst, okay, der Request kommt rein, du kannst dir erst mal Daten anschauen, zum Beispiel eine Authentifizierung machen. Die Regierung, das Middleware. Guckt sich den Request einmal an. Genau, guckt sich einen Request an, verändert ihn vielleicht und gibt ihn einfach in die nächste Ebene weiter. Und was ich auch die Möglichkeit habe, so ein einfaches Dipendent Injection Modell, dass ich sagen kann, ich kann an jeder Stelle halt eben diesen Request-Kontext irgendwie erweitern und Informationen, dann kann aber die nächste Ebene sich die reingucken, dass ich zum Beispiel sage, ich habe an irgendeiner Stelle die Automatisierung gemacht, da kriege ich dann aus einem Query die User ID raus oder das User Objekt und dieses Objekt kann ich dann an den nächsten Ebenen verwenden, zu sagen, zum Beispiel der Benutzer hat eine gewisse Rolle und deswegen darf er auf gewisse Ressourcen zugreifen. Und auch natürlich Auslieferung von statischen Dateien. Da gibt es einfach ein Public Verzeichnis, wo ich das irgendwie veröffentlichen kann. Also es ist sehr, sehr reduziert, bietet einem nicht sozusagen oberhalb von Shell, was wir uns jetzt angucken, nur die Möglichkeit, dass man halt einfach diese Verzeichnisstruktur nutzt, sein Projekt zu organisieren. Gabi, du hast Shelf in das Projekt gebracht? Das war schon da, als ich gekommen bin. Aber ja, ich kannte Shell schon davor auch ein bisschen. Und es ist halt ziemlich nah an Express dran, wenn einem das was sagt. Also man hat keine feste Struktur vorgegeben. Man muss die Routen oder den Router selber definieren und dann kann man da die verschiedenen Handler reinhängen, die dann zuständig sind für verschiedene Unterrouten. Es gibt auch Middleware, das ist glaube ich, auch ein Konzept, was deswegen in all den anderen Paketen wieder zu finden ist, weil die letztendlich auf Shelf aufbauen. Und das ist das, was wir nutzen bei uns. Wir nutzen eigentlich relativ wenig oben drüber. Wir nutzen Shelf und alles was da drüber ist, haben wir selber gebaut. Weil das war einfach so die Erkenntnis, dass wir gesehen haben, also Shelf ist etwas, was vom DATEAM auch irgendwie gemintained wird, ist schon sieben Jahre alt. Es ist es auchirgendwie glaube ich lange nicht mehr viel, was dran passiert, aber gefühlt, weil einfach alles da ist und es einfach diese Grundfunktionität, was andere Packages wie Express. Js natürlich bieten, dann entsprechend mitbringt. Und es gibt bestehende Funktionalität, also alles, was es dort gibt, wird über Middleware Library eigentlich reingehängt. Erst mal habe ich bei Express oder auch bei diesem Shell einfach nur die Möglichkeit zu sagen, ein Request kommt rein und wird irgendwie verarbeitet. Und dann gibt es halt einfach ein weiteres Paket, das ist jetzt die Shell Router, was genau diese Möglichkeiten bietet, die die anderen Sachen jetzt in der Verzeichnisstruktur abbilden, dass ich dort ein Routing festlege, einfach sage, es gibt eine Route, die irgendwie Puzzle heißt und es gibt eine Route Puzzle Images. Und welche Methode oder welche Händler, wie du es eben gerade genannt hast, wird an der Stelle eigentlich aufgerufen. Dann gibt es auch so was wie Shared Web Soccett, Shared Json haben wir uns selber geschrieben. Also das hattest du eben auch gesagt. Wir haben uns einfach sehr viel von der Middleware, die wir brauchen, Authentifizierung zu machen, jetzt Daten, die wir direkt zurückgeben, dann doch wieder in eine Response zu verwandeln, die wir dann einfach nutzen. Und da hat man aber eine sehr große Flexibilität und kann sich so einfach seine Funktionalität irgendwie maßgeschneidert irgendwie bauen, die man benötigt. Was ihr ja dann wahrscheinlich auch braucht, ist irgendeine Art, wieder mit Datenbanken zu sprechen. Aber das heißt, diese Schicht ist dann aber auch komplett selbst geschrieben. Du hattest eben was gesagt von Treibern, die man braucht für Datenbanken. Da gibt es dann aber …. Es gibt Pakete, die es ermöglichen. Das heißt, für DATE grundsätzlich gibt es die vielen Pakete. Das war nur eine Limitierung von …. Wo waren wir eben? Es gibt nicht für jede beliebige Datenbank. Für MongoDB hat es. … Für MongoDB zum Beispiel hättest du hier das gleiche Problem, weil das keine fertige … Hier ist deine DATE-Anbindung für MongoDB. Das heißt. … Aber auch da, wenn du gerade diese Pakete ansprichst, ist es auch gefühlt so, zum Beispiel das Paket für Postgreps ist auch vor sieben Jahren entstanden. In letzter Zeit passieren so ein paar Veränderungen, ein paar Commits drauf, aber es war auch eine Zeit lang so, dass eine gewisse Funktionalität eben nicht bereitstand, die wir gebraucht haben. Also gefühlt ist es einfach so dadurch, dass vielleicht dieser Bereich nie so aktiv genutzt wurde, dass es halt noch deutlich dünner ist, ausbaufähig ist und man auch irgendwie dann Pakete findet, wo man sich genau angucken muss: Passen es von den Issues oder ist dann doch irgendwas dabroken? Und was zum Beispiel so ein Paket wie Postgreift macht, ist einfach, dass es halt dieses binäre Postgreif-Protokoll dann unterstützt und einfach wie als Treiber Schicht hast du ja richtig genannt schon, eben den Zugriff zur Datenbank dann ermöglicht. Habt ihr Shelf Json veröffentlicht? Nee. Ja, weil es auch im Kern irgendwie so angepasst ist an unsere Bedürfnisse. Und ich glaube einfach so eine kleine Schicht, ich weiß nicht, sind es 50 Zeilen Code? Ein bisschen mehr inzwischen schon, ja, aber es ist eigentlich nicht viel Funktionalität, die da drin steckt. Rein vom Namen hört es sich so an, als ob es was ist, was tendenziell viele brauchen, also dass man irgendwie eine Json Möglichkeit hat, das zu interpretieren oder wieder da rein zu packen. Das macht das, oder? Ja, und was halt auch nützlich ist, was wir da drin haben, ist das Fehler-Handling oder Error Handling. Also wenn wir Exceptions werfen, die umgewandelt werden in Status Code und das Ganze einfacher geht, das durchzureichen, bis auf die Shared Ebene. Also dass es einfach einen entsprechenden Json Body dann rausgibt, wenn ich eine Fehlermeldung habe und dann auch entscheidet, weil jetzt bin ich in einem Produktion Environment, dann darf ich natürlich weniger Informationen rausgeben. Das haben wir alles eigentlich in diese Ebene reingezogen. Also für uns eigentlich... Das ist wirklich so unser Json, Stereolyser, Marsharing-Ebene, die sich alles das, was untendrunter an typisierten Daten irgendwie zur Hochgegeben wird, dann irgendwie umwandelt in die Schicht, die der Client wieder verwenden und verstehen kann. Ich denke, wir haben ja diese Datenbankabstraktion irgendwie anguckt. Das war gefühlt so das, wo man am meisten einfach schauen musste, wie ist die Qualität der Pakete, die man findet? Und da ein bisschen gesucht haben. Also da können wir, glaube ich, nur so ein bisschen Empfehlungen aussprechen von dem, was wir gefunden haben, was irgendwie gut funktioniert, vielleicht auch unsere Anwendungsfälle irgendwie so abbildet und das ist im MySQL-Bereich eigentlich MySQL 1 und MySQL Client. Da ist MySQL 1 irgendwie so das populärste Paket, was auch wirklich so den Funktionsumfang, den wir damals so getestet haben, sehr gut abgedeckt hat. Für Postgres ist es einfach dieses Postgres und Postgres Pool. Das Postgres Bibliothek bietet halt oder bindet halt dieses binäre Format an und das Postgres Pool ist einfach so dieses Pooling oberhalb, dass ich sage, ich habe einfach so einen Connection Pool, den ich wiederverwenden kann, sodass halt die Connections einfach geteilt werden und ich nicht für jeden Aufruf eine eigene Verbindung aufmache und dann zum Backend Server, zum Datenbankserver irgendwie halte. Das Redis-Paket nutzen wir letztendlich als Caching Schicht. Ich weiß gar nicht, ob es irgendwas für Memcash gibt, aber gefühlt solltet ihr natürlich heutzutage auch eher Redis nutzen als Memcash. Was wir immer gemacht haben, dass wir uns immer so eine eigene Datenbankabstraktion geschrieben haben. Also wir möchten eigentlich auf unserer Ebene eher die Sicht einer Collection auf die Daten haben, wo wir auch sagen, wir brauchen vielleicht nicht die gesamte Query Funktionalität, weil wir immer sehr ähnliche Operationen haben, wie wir Daten irgendwie abschreiben. Wir möchten die Daten per Primary Key irgendwie dann laden und dass eigentlich diese Abstraktion uns natürlich ermöglicht, dass wir untendrunter jederzeit die entsprechende Schicht austauschen und dann Applikationscode eigentlich gar nicht verändern müssen, sondern nur wirklich diese unterste Ebene dann noch mal irgendwie austauschen und verändern können, sodass wir da gefühlt uns einfach diese Flexibilität erhalten, jederzeit zu sagen, wenn wir doch feststellen, irgendeine Funktionalität ist nicht irgendwie abgedeckt von einem Paket, wir tauschen das ein und müssen eigentlich dann nur wirklich die Implementierung, wie dann mit der Datenbank gesprochen wird, irgendwie ändern und die API letztendlich dieses veränderten Paketes dann anpassen. Was man an der Stelle auch sieht, wir sind natürlich in einem Cloud ProviderUmfeld. Und da ist es dann schon auch schwieriger, etwas zu finden. Also gerade wir nutzen die Google Cloud, hatten wir da erst mal keine, nicht direkt irgendwie eine API und das ist eigentlich das, was hoffentlich noch entsteht, weil man denkt, natürlich hat Google ein Interesse daran, dass sie für Flutter, wo man ja auch denkt, vielleicht machen sie die ganze Flutter Entwicklung nur und machen natürlich die Integration mit Firefox so gut, damit man die Google Produkte nutzt, aber auch natürlich diesen Anwendungsfall, wir möchten eigentlich auch da für Flutter-Projekte im Backend verwenden, in Zukunft besser unterstützen und da eine Art API anbietet, die das besser macht. Und was man da hat, was einfach eine Unterstützung ist, dass es da ein Google APIs Package gibt, das wird automatisch generiert. Also es gibt da, glaube ich, eine Definition. Das sind, glaube ich, erst mal Json Dateien und daraus können für verschiedenste Programmiersprachen dann einfach eine automatische Modellebene für die API generiert werden. Und so gibt es das eben auch für Data, das ist ja eigentlich für... Der Google API, die es da draußen gibt, eigentlich ein Client, so eine Art Client Bibliothek, die ich dann nur anbieten muss. Aber könnt ihr mal ein Beispiel geben, was ihr euch da vorstellt, was schön wäreAlso was würde gekapselt werden jetzt von Google Cloud Funktionalität, auf die man dann direkt zugreifen kann? Also die Clients, die es so für andere Sprachen gibt, die greifen in der Regel auch auf diese generierten Clients zu, aber rappen die noch mal, schönere APIs bereitzustellen. Und was auch so ein Nachteil ist, dass die nicht über die Daten generierten Clients nicht über die schnellere Schnittstelle kommunizieren, sondern alles über die REST APIs machen und da noch ein bisschen Effizienz verloren geht. Also weißt du, die generierte API bietet mir die Möglichkeit, zum Beispiel mit FireStore als Datenbank-Backend zu kommunizieren, aber nutzt eben REST und REST hat da einfach und sterilisiert die Daten in Json, das ist halt einfachdiesen höheren Serialisierungsaufwand bedeutet als das GAPC zu nutzen. Und gerade natürlich auf der Ebene habe ich eine sehr schnelle Kommunikation zwischen Server und dem Backend System und würde mir eigentlich wünschen, dieses moderne Format. Okay, aber ja, FireStore war jetzt sowas, wo ich als Beispiel, wo es ein Service ist, auf den man dann einfach zugreifen möchte. Aber genauso weißt du natürlich wie Services wie Google Cloud Storage, zu sagen: „Hey, ich möchte jetzt eine Datei ablegen und die irgendwie abladen. Oder auch natürlich, was wir jetzt nutzen, Google Cloud Task Views, wo ich jetzt sage, ich möchte einfach einen neuen Task irgendwie Quen. Also alle Services, die es da draußen gibt – ich kann auch mit Kubernetes interagieren – haben eigentlich so eine Entsprechung dieser API, aber für viele andere Bibliotheken oder die Bibliotheken aus anderen Sprachen gibt es halt dann einfach für manche Services, die es einfach anbieten, einfach diese schnelleren Kommunikationsmöglichkeiten. Und da wäre es auch schöner, weil auch so das ganze Zusammenstöpseln so ein bisschen kompliziert ist, ist es halt schon sehr hierarchisch aufgebaut. Ich brauche erst mal so einen Authentic Klient. Dieser Authentic Client muss dann eigentlich an so einen Service übergeben werden. Das muss ich mir alles irgendwie zusammenbauen, irgendwie raussuchen. Eigentlich wäre es schon natürlich, so eine Bibliothek zu haben, wo ich sage, ich habe einfach ein Task View Objekt und kann da einfach ein Task reinlegen und muss mir nicht gucken, wie sieht das Format unten drunter aus? Was ist genau letztendlich das Json Objekt? Das muss ich ja nicht. Das wird mir schon vorgeben. Aber ich muss mich so ein bisschen durch die API wühlen, zu sehen, wie interagiere ich jetzt mit einem Service auf der Seite. Das ist das, was man für die Google Seite braucht. Und das gleiche natürlich, wenn man Amazon umfällt, irgendwie unterwegs ist, gibt es auch momentan nicht. Ich glaube, eigentlich habe ich das Gefühl, dass Amazon Team da mehr hinterher ist, zumindest aus den Gesprächen, die ich auf den letzten Flutterkonferenzen habe, haben die sehr großes Interesse dran, das irgendwie breitzustellen und haben gefühlt auch schon mehr Sachen. Es gibt ja diese iPase Amplify-STK. Was ja komplett in Daten neu geschrieben wurde, nicht wie bei Firefox, wo einfach die bestehenden SDGs gerappt wurden, sondern die haben es komplett neu für Daten geschrieben, was halt auch den Vorteil hat, dass es auf allen Desktopplattformen funktioniert. Also die investieren da ziemlich viel Zeit und. Ressourcen rein. Also eigentlich eher das, was man nicht so erwarten würde, dass vielleicht Google da weniger macht oder vielleicht jetzt nicht so im Fokus ist. Aber es ist natürlich das, was eigentlich auf der nativen Flutterseite von Firefox ja schon geboten wird. Man hat ja diese Firefox-STK, aber wie du es ja eben gesagt hast, das rappt oftmals eigentlich nur die bereits vorhandenen SDKs und bietet darüber eine andere API. Und was es da gibt in dem Bereich, also da gibt es auch kein Server-STK für die AWS Services, aber man kann eben aus dieser AWS Amplify-STK zwei Packages nutzen, die eigentlich ausreichend sind. Das ist einmal AWS kommen, was einfach so gewisse Grundeigenelemente wie Kommunikations-Clients, HTTP-Clients, die halt eine gewisse Authentifizierung schon machen und auch dieses AWS Signature. Man braucht ja eigentlich V4. Man braucht ja immer so eine Signatur, wenn man mit irgendwelchen AWS-Endpunkten redet und das übernimmt halt das gesamte Format eigentlich, wie die Signatur berechnet wird. Also es wird ja immer an jedem Aufruf irgendwie dran gehängt. Früher haben wir das immer selbst implementiert und immer ein bisschen gebraucht, bis es so gestimmt hat irgendwie. Und deswegen ist es ganz gut, dass es dieses Paket bietet, was ein paar Funktionen bietet, die man dann irgendwie ansprechen kann, das zu bekommen. Wir machen es halt so: Wir bauen eigentlich immer Docker Container, das einfach auszuführen im Backend. Das ist, glaube ich, die schönste Möglichkeit, das zum Beispiel auszuführen. Da gibt es natürlich verschiedenste Lösungen auf den Plattformen. Man kann es natürlich entweder direkt in Kubernetes irgendwie laufen lassen, wenn man so einen Docker Container eigentlich hat. Wir nutzen Google Cloud Run, was einfach so ein Platform as a Service Konzept ist, die Sachen auszuführen. Eigentlich ist es so, dass wir sagen, wir haben eigentlich eine Server-Daten Datei, die irgendwie IoT gebaut wird. Das ist einfach so in unserem Build Prozess hinterlegt, dass wir sagen, wir bauen erst mal aus unserer Server-Daten Datei, die natürlich alle anderen Data-Teilen irgendwie einbindet, machen wir mit einem IoT Build eben eine ausführbare Server Datei und packen die letztendlich dann in einen Docker Container und laden halt dieses Docker Container dann einfach in die Registry und sagen dann letztendlich Cloud Run führt mir einfach eine neue Instanz von meinem Service mit diesem Docker Image aus. Und das ist auf jeden Fall eine sehr schöne Möglichkeit, das aufzubauen. Und man hat einfach da diesen Effekt – und das ist natürlich gerade besonders interessant für solche K-Native Umgebungen wie Cloud Run –, also auch in K-Native wäre das natürlich genauso möglich, dass man ja auch einen Scale to Zero Szenario sich aufbauen kann, wo eigentlich keine aktive Instanz von meinem Service läuft, sondern eigentlich nur der Laut Balancer, wo ich dann einfach sehr schnelle Startzeiten natürlich haben möchte, wenn dann der erste Request reinkommt, dass ich darauf reagiere. Das ist immer so ein bisschen der Nachteil. Ich könnte auch alles einfach als VM sozusagen in der Daten VM dann auf diesen Server ausführen lassen, wo ich natürlich während der Laufzeit durch diese Hotspot VM natürlich bessere Ausführungszeiten für die oft aufgerufenen Pfade bekomme, aber einfach durch diesen A2Bild einfach eine deutlich schnellere Startzeit habe, die im Bereich so von 200, 300 Millisekunden auf jeden Fall eigentlich immer bei unseren Services, weil auch immer so ein bisschen Vorinitialisierung passiert, von unter 500 Millisekunden habe, was auf jeden Fall schnell genug ist, dann so ein System zum Laufen zu bringen. Und vielleicht eine Option, die man noch erwähnen muss, weil auch in letzter Zeit habe ich so ein paar Beiträge gesehen, wo es noch mal irgendwie diskutiert wurde, ist das Google Functions Framework. Aber du hast vorhin gerade gesagt, da ist seit zwei Jahren kein Commit mehr drauf passiert und deswegen so ein bisschen fraglich, ob es das ist, wo Google wirklich drauf baut und ob das irgendwie eine gewisse Zukunft hat. Aber hattest du dir das ein bisschen näher angeschaut, was eigentlich dieses Google Functions Framework bietet? Nicht wirklich. Ich dachte, ich hätte irgendwas... Ich habe das Gefühl, dass bei Google auch vorgestellt wurde, dass man da jetzt in mehr Kontexten noch verwenden kann oder ob das irgendwie geplant ist für die Firefox Functions. Aber ich. Kann mich jetzt auch nicht mehr so ganz. Genau erinnern. Aber eigentlich ist es, was heißt genau das? Also eigentlich so der Ansatz zu sagen. Das wäre schön, wenn es möglich wäre. Ich möchte eigentlich eine einfache Möglichkeit haben, da die verschiedensten Umgebungen auszuführen, was eigentlich dieses DATE Functions Framework macht. Es nutzt unter der Haube auch Shell. Du hast einfach nur die Möglichkeit, in einer Datei eine Funktion zu definieren, die muss auch Function heißen. Du kannst das noch irgendwie verändern über eine Umgebungsvariable für den Build Prozess. Aber dann musst du noch eine Annotation dran schreiben und letztendlich macht er dann eben wieder einen Shelf Server drauf, der diese eine Funktion aufruft. Wo eigentlich so die Idee ist natürlich, wie es halt auch bei entsprechenden Cloud Functions ist. Ich habe eine Funktion, die dann mehr Funktionalität irgendwie abbildet oder vielleicht einen dedizierten Service, eine dedizierte Operation macht. Und eigentlich ist jede Funktion sozusagen ein eigener Service, der irgendwie läuft. Also nicht so wie wir es vielleicht haben, dass wir halt wirklich eine API unter einem Endpunkt gebündelt haben und gesagt haben, das ist unser API Service, der ist für die gesamte Kommunikation, zum Beispiel für den native Client zuständig und hat natürlich dann etliche Routen, die er dann auflösen kann, sondern dass ich sage, ich habe irgendwie einen Endpunkt, der heißt, gib mir jetzt irgendwie die Liste aller Puzzles und dann gibt es einen anderen Endpunkt, der heißt, gib mir die Liste aller Bilder oder ähnliches. Und dass ich alles irgendwie separat voneinander deploye und zum Beispiel Adam Bien ist ja auch ein großer Freund davon, sagt hier eigentlich, macht alles Serverless und Serverless Functions und alles so klein und atomar wie möglich. Und das soll halt genau dieses Functions Framework anbieten. Aber unter der Haube baut es auch einen ganz einfachen Shell Server, wo wir damals gesagt haben, also dann haben wir doch lieber diese höhere Flexibilität, so ein bisschen mehr auch auf das Routing Einfluss zu nehmen und dann Client oder mehr die Möglichkeit zu geben, mit einem Endpunkt zu sprechen, aber verschiedenste Datenüber diesen einen Punkt oder über diesen einen Endpunkt oder über einen Service dann abzurufen. Und das, muss man sagen, ist es eigentlich schon. Und gefühlt ist es so, dass es sich wirklich gut anfühlt, diesen Weg zu gehen, zu sagen, man hat eben nur noch diese eine Programmiersprache. Das ist einfach ein Riesenvorteil, den man in der täglichen Arbeit merkt, dass man gefühlt überhaupt nicht mehr direkt in der Sprache drin ist, sich vielleicht auch wirklich nur noch mit einer Sprache auseinandersetzen muss. Natürlich guckt man immer ein bisschen über den Tellerrand, aber es ist einfach so, egal mit wie viel Sprache man sich auseinandersetzt und wie viele Sprachen man auch beherrscht, dass man so... Dass es doch schwierig für den Entwickler ist, ständig sich jedes Konstrukt, jeden Begriff, also jedes Keyword von jeder Sprache zu beherrschen. Und gerade wenn die Konzepte sehr ähnlich sind, man manchmal auch wirklich durcheinander kommt. Wie hat das genau in dieser Sprache funktioniert? Das merke ich jetzt auch immer noch, wenn ich zwischen Daten und Kottland so hin und her springe, dass man doch immer sich wieder klar werden muss: Okay, wie war das denn jetzt genau in dieser Programmiersprache, wenn man das jetzt nicht tagtäglich macht? Ja, irrelevant. 2023. Du schreibst ja nur noch das Konzept, was du brauchst und es wird ja runter programmiert, die Programmiersprache. Kann dir egal sein? Ja, das stimmt. Klar, das ist natürlich jetzt eine ganz andere Entwicklung. Fällt euch irgendwie ein, wo ihr sagen würdet, da kommt jetzt jemand mit einem Use Case auf euch zu und er sagt: „Boah, lass die Finger von da dem Backend. Also gibt es irgendwie Sachen, wo ihr ganz klar sagen würdet, dafür ist es im Moment noch nicht geeignet und da sollte man vorsichtig sein? Oder sagt ihr, egal, machen wir mit DATE? Also ein Use Case, der mir jetzt irgendwie einfällt. Es gab mal so ein altes Framework, das nannte sich Angel, was auch so ein Modul hatte, mit dem man dann eine GraphQL API aufbauen könnte. Also dafür gibt es noch kein Package oder so für Shell, wo ich mir eigentlich denken würde, wäre eigentlich schön. Ich meine, es gibt ja auch schon manche Stimmen, die sagen, auch GraphQL hat seine Nachteile und ist vielleicht gar nicht so der präferierte Weg, in Zukunft noch Sachen zu bauen. Das ist ja viel mehr auch zu GRPC. Ganz groß im Kommen ist auch wirklich direkt als Kommunikationsschnittstelle zum Client. Das wäre so ein Punkt, wo ich sagen würde, wenn ihr überlegt, irgendwie GraphQL zu nutzen oder vielleicht auch die Anforderungen habt, das müsst ihr auf jeden Fall komplett selber bauen, weil ihr wollt nicht Angel verwenden, was gefühlt einfach keine Wartung mehr hat. Ja, auch natürlich wirklich. Du hast angesprochen, MongoDB, also Postgres MySQL ist irgendwie ganz gut unterstützt, aber auch die Integration, die Cloud Services. Man muss so ein bisschen was selber schreiben. Das ist natürlich ein gewisser Invest, den man initial hat. Gefühlt war es sehr schnell möglich, dass man dort eine operierende Schicht hatte. Aber das ist natürlich so eine Grundvoraussetzung, dass man sich erst mal damit abfinden muss. Man muss sich vielleicht überlegen, was fehlt mir von dem, was ich brauche? Lohnt sich das jetzt wirklich, da nutzen zu können, selber zu schreiben? Wie groß ist der Aufwand? Einfach, das ist vielleicht von Fall zu Fall dann einfach eine Entscheidung. Aber es ist nicht so einfach zu sagen, wir nutzen einfach Node. Js oder in dem Fall DATE, weil das Ökosystem einfach nicht so groß ist wie bei anderen Sprachen, die schon länger existieren oder länger vor allem im Backend Bereich genutzt werden. Man muss da einfach noch mal checken, ob alles da ist, was man braucht. Also es ist so eine gewisse Grundrecherche oder vorab Recherche, die einfach so sinnvoll ist, dass man sich so ein bisschen einfach absichert, kann ich meinen gesamten Use Case, den ich so vorhabe, eigentlich mit DATE abbilden. Und für uns hat es einfach die extremen Vorteile, die ich eben genannt habe und natürlich auch die Performance, also dass wir sehr, sehr wenig Ressourcen brauchen, die Last unserer Systeme eigentlich abzubilden. Und da in anderen Sprachen auch, Java ist vielleicht natürlich auch sehr hungrig. Natürlich gibt es Systeme wie Kral VM, die das wieder ein bisschen kompensieren können. Was mir auch immer sehr gut letztendlich an DATE gefällt, ist einfach das geringe Tooling, was man braucht. Wenn ich überlegen würde, das gleiche irgendwie mit JavaScript im Backend zu machen, brauche ich doch vielleicht einen TypeScript Compiler, der mir das übersetzt, Node. Ts oder irgendwas, wo man bei Daten einfach direkt sagt, wer bei uns eigentlich mit der Sprache, mit der Daten vor allem interagiert und das einfach so auch diesen Start in einem Projekt immer sehr, sehr viel einfacher macht. Okay. Cool. Dann könnt ihr jetzt alle Daten im Backend einsetzen. Ja, ich hoffe, es wird auch noch mehr. Aber eigentlich ist ja euer Hauptvorteil, in der gleichen Programmiersprache zu bleiben. Also wenn ihr ein Flutter Projekt habt oder zufälligerweise irgendwo anders DATEins setzt im Frontend, dann ist das doch eine Option, das auch in den anderen Bereichen zu machen. Also auf jeden Fall heute möglich. Und gibt es viele Optionen, das Ganze produktiv einzusetzen. Habt ihr sonst noch was, was euch einfällt zum Thema Full-Stake-DATE, wo ihr sagt, das müssen wir jetzt noch mitgeben? Oder seid ihr happy mit den Informationen? Also ich bin happy. Ich glaube auch, wir haben vieles vermittelt. Ich bin sehr gespannt, was kommt. Also auch gerade jetzt auf der Flutterkonf. Wann ist es für Juli? Juli. Wir hatten da auch einen Talk. Gibt es auf jeden Fall ein paar Themen, die genau auch in diesen Aspekt reinschauen und sich anschauen, wie man das realisieren kann. Es wird auf jeden Fall spannend, was andere in dem Bereich machen, sich da vielleicht auszutauschen, was so die Erfahrungen sind. Also man merkt auf jeden Fall, dass da ein Bedürfnis da ist, ganz klar. Also nicht nur wir haben dieses Bedürfnis, vielleicht auf beiden, auf allen Ebenen zu verwenden, sondern auch andere. Und dass das Gefühl einfach so im Kommen ist und da wahrscheinlich auch entsprechend interessante Frameworks entstehen, wie jetzt StartFork zum Beispiel ein Beispiel ist. Cool. Dann vielen Dank euch beiden. Danke dir, Dennis. Und wie immer die Bitte am Ende der Folge, dass ihr uns gerne schreiben könnt, wenn ihr Feedback habt zu dieser Folge über unsere Website: „Programmier. Bar. Auf Spotify gibt es ja auch so eine Funktionalität, dass man Nachfragen stellen kann. Ich sage immer, ich habe das im Blick, aber ich merke immer, wenn ich sage: „Hey, da gibt es eine Möglichkeit, dass ich mal wieder reingucken müsste, weil wir nicht aktiv darüber eine Notification bekommen. Trotzdem schreibt auch gerne da rein, denn das hat den Vorteil, dass mit ein bisschen Verzögerung diese Fragen auch unter der Folge erscheinen und das praktisch, also das Feedback dort auch für andere einsehbar ist. Also wenn ihr Ergänzungen oder so was habt, könnt ihr die auch gerne da reinpacken. Ja, und sonst wünschen wir euch eine schöne Zeit. Hoffen wir, hören uns bald wieder. Und genau, also falls ihr irgendwie Flutterentwickler seid, dann schaut euch auf jeden Fall das Programm von der Flutterkonf an. Das ist auf jeden Fall sehr, sehr spannend, was da vorgestellt wird in vier Tracks. Wir sind vor Ort mit der Programmierbar. Wir sind mit Lultum vor Ort, wir sind mit der Programmierbarheit vor Ort. Wir haben drei Speaker, die dort einen Talk halten. Also große Präsenz von uns, aber natürlich auch von ganz, ganz vielen anderen tollen. Und das ist parallel zur Droitcon. Also falls ihr vielleicht nicht unbedingt Flutter, aber trotzdem im Mobile Space und bei Android unterwegs seid, könnte das relevant für euch sein? So wie ich das verstehe, ist es alles ein Eventgelände und auch praktisch Ausstellung und Party und keine Ahnung was noch außen rum ist, ist gemeinsam. Von daher ja, spannende Konferenz Ende Juli in Berlin. Yes! Ist Ende Juli die richtige Antwort? Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Anfang Juli. Okay, ich glaube bis 6. Ja, ja, doch noch wenig. Nee, fünf, sechs, sieben kann das sein. Ja, genau. Fünfter, sechster, siebter Juli. Ende Juli war auch irgendwas in Berlin? Die VR Developer ist. Glaube ich. Ah ja, VR Developer, die Konferenz, wo eine Kollegin meinte, dann bleiben wir doch einfach, bleiben wir doch direkt in Berlin die drei Wochen. Vielen Dank. Bis bald. Mach es gut. Ciao. Tschüss. Tschüss.