Softwarearchitektur: Microservices, Frontend, Backend, Datenhaltung & Kommunikation #46

Was? Moin zufolge 46 von einfach komplex. Hier ist Gerrit und der Burkhardt ist auch wieder dabei. Moin Moin, heute soll es gehen um das Thema Software Architektur Wir hatten einen Hörerwunsch glaube ich sogar zum Thema wenn ich mich richtig erinnere irgendwie auf Discord oder so. Ja, ich glaube auch ja. Und da sagte Burkhard Total geil, das müssen wir uns angucken. Wir haben jetzt extrem viele Komponenten schon mal von so einer Architektur oder von so einer Software angeschaut,

Datenbanken, die API. Front End Back End haben wir uns alle schon mal angeschaut. Und wie kommt das alles zusammen und wie baue ich eigentlich eine vernünftige Software Architektur? Das machen wir heute am Beispiel einer To do App Burgert warum die To do App war auch deine Idee. Jedes System hat ja so seine Testkaninchen oder Labormäuse oder irgend sowas.

Der Molekularbiologe, der hat da die Labormaus oder Drosophila bei sich auskennt und so hat jeder so sein Testsystem und bei der Software hat man sich überlegt was ist gleich die minimale komplexeste. Also wenn ich mal eine ganze Anwendung angucken will um genau solche Fragen zu beantworten wie Architektur und so weiter. Ist wohl das minimale davon.

Und was kennt jeder? Ja halt so ne to do App ne also Gerrit du weißt was ich meine, vielleicht erklärst du kurz was wir dass alle Zuhörer auf der Welt to do App also oder ne aufgabenwelt verwaltungsapp oder irgendwie ja wie man das.

Nennt ja, man kennt ja ne to do Liste, sag ich mal vom Bleistift und Papier. Ja schreibe ich einfach auf, ich hab dies und das zu tun, dahinter mache ich vielleicht ein kleines Kästchen, das ich dann abhaken kann, wenn ich diese Aufgabe erledigt habe, zum Beispiel einkaufen gehen, die Wohnung aufräumen und Tisch reservieren für den Restaurantbesucher, abends 3 aufgaben, die schreibe ich auf und mach dahinter nen Haken wenn ich es. Erledigt habe ganz genau, das ist trivial, aber auch total

viel mehr wert. Also wie also Annika und ich, also meine Frau und ich, wir nutzen das zum Beispiel als wir haben digitale Einkaufsliste und dann. Genauso eine to do App und da steht halt drauf was als welcher Artikel eigentlich Butter, Milch, was weiß ich dann hakst du das halt ab und dann kommt es quasi in den abgehackten Bereich und wenn es wieder leer ist, dann wird das halt irgendwie wieder wieder noch mal quasi reaktiviert und ist wieder oben, ja. Das zeigt auch schon, was wir

glaube ich minimal. Und das ist jetzt das Wichtigste, schon bei der Software Architektur. Das, was wir jetzt machen. Wir besprechen quasi das Lastenheft, ja, also wir wollen erstmal ganz genau verstehen, was soll wirklich genau diese App können, ja wo soll sie laufen und was wir jetzt schon gesagt haben, wir wollen auf jeden Fall. Also Tasks anlegen können.

Sie abhaken können. Also ist dann, vielleicht wollen wir sie auch wieder auf noch nicht fertig umsetzen können, also das in beide Richtungen ist so n toggle quasi und wir wollen vielleicht auch Gerrit die Löschen komplett löschen können klar und wir wollen vielleicht auch den Namen ändern können vom Task falls du dich doch mal verschrieben hattest oder irgendsowas also Nummer ich mit nur mit h geschrieben hast oder irgendsowas du sprichst. Jetzt in der Einkaufsliste kann

aber beliebige to do Liste sein. Kann auch das sein, was du gesagt hast? Ich muss noch staubsaugen. Ich muss noch das und das Zahnarzt und so weiter und

sofort genau, völlig egal. Genau, und ich hab, das habe ich rausgenommen, das ist gar nicht jetzt, also von mir überhaupt so ausgedacht, das ist ganz oft so, wenn man jetzt zum Beispiel, wenn sich so Frontend erklären, wie das zu machen ist, zum Beispiel für React, da gibt es so eine to do App einfach mal so, wie man das also ein best practice ist, sage ich mal zum Beispiel so eine to do App als Front End, nur realisieren kann, hier fangen wir schon an, jetzt müssen wir uns mal kurz

überlegen, was soll unsere To do App eigentlich genau wirklich können. Und was für Komponenten hat es? Und da fängt dann schon an, Software Architektur zu entstehen. Auch kleiner Disclaimer heute wir sprechen zwar über Softwarearchitektur und es gibt glaube ich auch ziemlich viele Bücher und so weiter. Ich glaube, es gibt ziemlich viele Ansätze, wie man das machen kann, und es ist vielleicht auch so unterschiedlich wie die Leute, die sich Software Architekten

schimpfen, das angehen. Heute hört ihr quasi, wie ich es machen würde, ja, also ich hab ja n bisschen in meiner Vergangenheit jedenfalls den Titel getragen, ob ich es wirklich habe ich wirklich ein guter Software Effekt war weiß man immer nicht so genau, man kann es vielleicht daran sehen ob der Kavs noch läuft oder nicht so dann würde ich sagen, ja ich hab's einigermaßen hingekriegt, so aber ist so meine Sicht der Dinge ist bestimmt nicht ganz

allgemeingültig und vielleicht würden es andere Leute ganz anders machen, also kleiner Disclaimer ist natürlich immer so weil einfach komplex, hier kommt immer irgendwie was Subjektives mit rein, aber das hat heute ganz gar keinen Anspruch auf objektive Best Practice, so müsst ihr es machen, sondern ihr hört jetzt wie ich das machen würde.

Wir sind keine Wikipedia. Ja und Wikipedia vorlesen lassen, das brauchen wir keinen Podcast für anmachen, das geht auch so auf dem Telefon. Ganz genau. Nein, völlig in Ordnung, Burkhardt, dass wir da deine Sichtweise drauf hören. Wie fängst du an, jetzt hast du deine to do App, Wir haben die Grundanforderungen an die to do App schon mal definiert, also das Mini Lastenheft geschrieben, die haben. Wir noch nicht.

Ich hatte die jetzt. Also wenn du jetzt der to do, wenn du jetzt über aufträger wirst, hätte ich jetzt noch ein paar Fragen. Sicher, Gerrit, Wie sieht es denn aus mit deiner To do App? Willst du die eigentlich im Browser laufen lassen? Ganz modern, schön irgendwie oder soll das n Desktop Anwendung werden oder das ist ja total wichtig für mich zu wissen ne.

Soll im Browser laufen und möglicherweise auch auf dem Telefon. Ja, ach cool und willst du eigentlich die To do App, dass die nur während die an ist irgendwie sich ihre to do s speichert? Oder willst du quasi den Tab schließen können? Und danach soll die wenn du wieder aufmachst trotzdem alles so sein wie es vorher war? Die soll natürlich genauso sein,

wie es vorher war. Die soll ihren Status beibehalten, so wie es. Kleine kleine jetzt jetzt habe ich so ein paar Sachen verstanden jetzt, ich spreche das mal für euch, also wenn die so sein soll wie sie vorher war und Gerrit zwischendurch den Tab zugemacht hat, also wenn er den Tab zu macht, dann schließt er quasi die ganze Session das ganze Programm was die 2 erbrennen hat.

Wir haben noch gar nicht darüber gesprochen, ob das jetzt eine Single Page Application oder Multiplayer, aber egal, er schließt das halt alles und wenn wir jetzt kein Backend haben was vorher das gespeichert hat, dann ist alles verloren, das heißt mit der Aussage das wäre das Wiedersehen will geht in meinem Kopf schon ab ok wir brauchen mindestens ein Front End ganz klar er will ja die TO dos sehen und so weiter also im Browser.

Also brauchen wir ein Frontend und wir brauchen ein Backend, weil Garrett das noch sehen will. Ja, das nächste Mal, wenn er seine App wieder aufmacht, ja, klingt ziemlich trivial. Ne, klingt ziemlich trivial, aber so, also so bauen wir mal die kurz die Blöcke zusammen, so ja, es gibt durchaus Anwendungen die einfach nur im kein State haben so keinen Persistierten State sagt man auf Fachchinesisch, also wo einfach nur die UI ist.

Zum Beispiel ich sag mal was ein Bluetooth Verbindung, du hast eine UI, verbindest dich irgendwie mit so einem Bluetooth Ding, machst da irgendwas und dann machst du das Ding zu, dafür brauchst du kein Backend, das kannst du einfach alles in Frontend regeln, aber unsere to do App braucht jetzt wohl ein Backend. Jetzt hab ich noch eine Frage. Gerrit, wollen wir eigentlich, willst du mehrere Listen haben, also mehrere verschiedene To do Listen wo die wo die Dinger drin

sind. Ja, ich stelle mehr sowas. Wieso buckets so so glaube ich würde man wahrscheinlich sagen ja einmal oder oder Kategorien vor wie zum Beispiel meine to do S dem privaten oder dem beruflichen zuordnen könnte als Beispiel. Und wir haben dann quasi eine Überschrift, zum Beispiel Einkaufsliste, Einkaufsliste, so wie von mir und oder oder, was private Aufgaben oder irgendwas

zum Titel machen. Dran ne, OK, jetzt wieder nachgedacht Software Architektur, das heißt wir haben hier 2 wichtige Datenstrukturen, wir haben quasi ne Liste. Und wir haben die Aufgaben. Ja, die Liste hat irgendwie n Namen, Einkaufsliste, private Tasks und so weiter und dann haben wir die die einzelnen Aufgaben mit ihren Namen und mit ihrem Zustand, nämlich ist abgehakt oder ist noch nicht abgehakt und so weiter. OK, soweit so gut.

Jetzt noch die Frage und wichtige Frage mandantenfähigkeit so frag ich dich das natürlich nicht, soll deine App mandantenfähig sein oder sind das daher was willst du Burkhardt? Ich was anderes willst du zum Beispiel, dass Lara, deine Frau, auch deine to dos sehen kann und die vielleicht sogar auch gleichzeitig mit editieren kann?

Ja, das wenn ihr nämlich zum Beispiel so ne Einkaufsliste habt, dass die nicht nur für dich ist, sondern dass Lara, wenn sie zum Beispiel den gleichen Link hat oder Irgendsowas sieht, das ganz einfach mit nutzen kann. Das wäre toll, ja. Aber natürlich möchte ich das dafür gesorgt haben, dass nur wir 2 unsere Tasks oder Einkaufsliste sehen können. Okay krass und nicht noch andere Leute, ja. Okay gut also jetzt nochmal für unsere Zuhörer, was Gerrit uns jetzt gesagt hat.

Er will quasi Multiplayer haben, also sollen also quasi mehrere Klienten gleichzeitig seine Liste editieren können. Das bedeutet, ganz wichtig jetzt für die Architektur. Dass. Sich das Backend ändern kann. Unter garrets Arsch, obwohl er das gar nicht getriggert hat. Also stellen wir uns vor, Gerrit hat seine To do App gerade auf und Lara zufällig auch und hakt einen Task ab. Dann hat Gerrit nichts gemacht. Aber Gerrit will eigentlich in ziemlicher Echtzeit sehen, dass das passiert ist.

Das heißt, wir brauchen jetzt hier was Neues vorher, wenn Garrett das nur alleine hätte. Die to do App und auch sogar mit dem Backend drin, bräuchten wir aber nur synchronisieren von Garrett Client. Richtung Backend immer nur in die Richtung und wir müssten jetzt nicht aufpassen, dass sich das Backend auf einmal ändert. Und wir Gerrit live ne Änderung einspielen müssen. Ja das ist n riesen Unterschied architektonisch hier ja weil wir jetzt haben wir auf einmal.

Jetzt ist die Frage wo kommen welche Events her. Das kann das quasi auch aus dem Backend kommen. So. N ja, jetzt kann mich quasi n Event aus dem Backend kommen und muss deinen deine UI, dein Display entsprechend updaten. Ne? OK, haben wir aufgenommen in die in die Liste. So jetzt mein Bild wird immer vollständiger.

Jetzt hat Gerrit noch was Wichtiges gesagt, er will aber das nicht mit allen Teilen. Ja hier muss ich ihn heute n bisschen einbremsen weil wir haben ja nur n Podcast und wir wollen das ja nicht in echt machen.

Das heißt nämlich, Wir sind jetzt hier bei Autorisierung, nee, bei Authentifizierung, das heißt, ich muss erstmal wissen, wer ist wer ne Gerrit will halt wissen, dass das nur Lara darf, zum Beispiel, dann würde sie in Lara sich authentifizieren müssen als Lara. Was heißt Authentifizierung, also n Login ne gibt Ihre E-Mail-Adressen Passwort oder meldet sich per Google an bei Social Media oder irgend sowas und dann müsste Sie noch Autorisierung haben, sie müsste

autorisiert werden, wenn das mal ursprünglich deine Liste ist, dass die das nun auch lesen darf. Ja, das eine ist ja es ist Lara und das andere ist ja Lara, darf das der klassische Authentifizierung Autorisierung, wenn wir das heute noch mit einnehmen, dann explodiert jeder der Podcast, deswegen machen wir es etwas einfacher Gerd, ich dachte dir das vor, stell dir vor du hättest einen Link so ein bisschen wie bei Google den Scheren könntest wird dir das

reichen? Also irgendeinen kryptischen Link so und dann sagst du hier der könnte zwar jeder der den kennt könnte dann einen Task bearbeiten hier Lara nimmt den. Link ja, so würde ich es gerne machen. Ja hast mich überzeugt, ich schätze mal das wird nachher auch günstiger das. Wird viel günstiger. Kennst du dann mal so 5000 streichen von der Rechnung? Ja, bei Lowcood im Übrigen nicht. Aber genau so. OK, cool. Also dann haben wir dann haben wir die, dann haben wir die.

Die Aufgaben eingesammelt beziehungsweise die Anforderungen eingesammelt. Nicht die Aufgaben.

Ich hab hier gerade gelesen, gleichzeitig sollte man nie machen, dann kann man nicht gerade aussprechen so und ich will da aber noch eine Sache sagen, gleich die wir jetzt schon wissen, die Tasks, die können wir nämlich jetzt anlegen, anzeigen, abhaken und löschen, wo wir das jetzt uns kurz mal im Architektursprech durchgehen lassen, dann übersetze ich mal anlegen create anzeigen read abhaken, Update und löschen delete. Da haben wir das Crude Crad, das

hatten wir schon mal. Ja immer Dreh und Angelpunkt so hier bei den Tasks brauchen wir ein crad System, das kann ich jetzt schon mal, das steht jetzt schon fest bevor wir überhaupt irgendwas weiter machen. Dann haben wir es.

Jetzt müssen wir Entscheidungen treffen, ne, also jetzt haben wir die Anforderungen eingesammelt, wir hoffen, wir hoffen mal, dass Gerrit seine Anforderungen jetzt auch erstmal für die nächsten Minuten hier in dem Podcast im echten Leben für vielleicht die nächsten Wochen stabil ist und wir nicht anderen hin und hereiern müssen. Ja, ich hab noch ne andere Frage. Geht's in irgendeiner Form auch

schon um Anforderungen? Was das Aussehen angeht, also Design, user Interface Design oder sowas oder ist das mal egal? In diesem Beispiel oder diesem Stadium der Entwicklung? Beides richtig, völlig egal in diesem Stadion und auch völlig Wurst für die Software.

Architektur spielt überhaupt keine Rolle, wie du später Anmalst. Ich würde dir das sogar irgendwie ganz hässlich zeigen mit irgendwie vielleicht will ich das nicht machen, wenn ich ein guter Salesman wäre, dann würde ich sagen okay, ich male es erst richtig schön an, dann zeige ich es dir aber. Anmalen ist eine Sache, aber wirklich auch Positionierung von. Passiert alles innerhalb des Frontend, passiert alles mit CSS. Innerhalb von diesen. Javascript hat. Im Prinzip ist alles total

lokal. Für diese UI, hat gar keinen Einfluss auf. Die Architektur. Stimmt nicht ganz. Hätte es vielleicht ein bisschen, wenn wir uns überlegen würden, also wenn wir uns entscheiden würden, was wir nicht tun werden im im, im dass wir ne Multipage application haben, also dass da das Backend quasi deine Seite rendert, dann müssten wir da auch schon überlegen, dass wir vielleicht ne Technologie nehmen, die das schön die schönen rendern kann, sag ich mal.

Das werden wir aber nicht machen, weil wir wollen ja was Modernes machen, das soll auch ein bisschen Inhalt des Themas sein, dass gehört zur Architektur dazu, ganz wichtig, und das kommt jetzt, dass wir uns jetzt für Technologien entscheiden, die nicht schon aus dem Mittelalter sind und die schon den Staub haben ne, sondern wir wollen ja jetzt und das Wichtige, also wir wollen ja jetzt Technologien aussuchen, du

willst ja dann erst ins Feld gehen mit deiner to do App, ja die ist dann ja sowieso schon die Zeit vorangeschritten und jetzt suchen wir uns natürlich schon State of the Art Krams aus, damit das nicht schon veraltet ist. Bevor du überhaupt anfängst. Dann legen wir los. Ist das der nächste Schritt, jetzt das? Ist der nächste Schritt Technologie, um auszusuchen und abzugleichen? Ich habe mir einen kleinen Spicker natürlich heute gemacht, weil es ein komplexes Thema ist.

Ich habe hier geschrieben, jetzt müssen erst mal Entscheidungen getroffen werden auf Grundlage. Und wir müssen die vor allem nicht nur einfach treffen im Stübchen. Und wir müssen die kommunizieren.

Das glaube ich auch. Ein wichtiger Punkt, Software, Architektur, das vergisst man, glaube ich immer, hat ganz viel mit Kommunikation auch zu tun in 2 zu 2 Parteien, nämlich zu dir als derjenige als Beauftragender quasi dir gehört das Projekt Project Owner, Dir gehört das Produkt am Ende des Tages, ich finde, du darfst und solltest auch informiert werden, auch wenn es jetzt technische Entscheidungen sind auf dem entsprechenden Level wie du es verstehst.

Ja, und wir müssen auch kommunizieren ins Team, denn typischerweise entwickeln wir jetzt so n Ding ja nicht alleine, sondern wir müssen mit unseren, mit unserer ganzen Entwickler, die es implementieren sollen, auch sprechen und das auch Requiem so. Ja, also da muss viel kommuniziert werden jetzt an der Stelle so. Gerhard, Jetzt hast du. Jetzt hast du. Auch schon in deiner Vorbereitung geschrieben. Wie setzen wir das jetzt um?

Ja, machen wir jetzt ne Schichtmodell daraus n Monolithen oder nen microservice Modell? Ja das ist auch schon mal ne Entscheidung die wir treffen

müssen. Ja ganz grundsätzlich ja, ist ne ziemlich rhetorische Frage heutzutage, weil wir machen immer Microservices Punkt aus Ende Docker ist halt wer das nicht macht, der hat Halt verloren ja erzähle ich nachher noch ein bisschen genauer warum aber die die Entscheidung müssen wir erstmal treffen ja Schicht Monolith oder microservice wir wissen schon wo es hingehen wird, dann brauchen wir logisch gesehen müssen wir jetzt gucken wir brauchen wir haben ja 3.

Wir haben 3 Komponenten im Prinzip. Wir haben das Frontend, wir haben das Backend und wir brauchen irgendwie eine Datenhaltung. Irgendwo müssen ja diese Daten dein textueller Inhalt und der Status, ob abgehakt oder nicht muss irgendwo persistiert werden über die Starts von deiner von deiner App hinaus.

Also diese 3 Dinge haben wir und für die müssen wir die Technologien raussuchen und bevor wir das machen, müssen wir uns auch noch entscheiden, das hatte ich gerade gesagt, dieses Front der Frontend aussehend aussehen soll soll das halt eine Single Page Application, das hatten wir mal gehe ich jetzt nicht drauf ein, also soll das quasi javascript im Bundle sein und läuft quasi bei dir im Klienten als kleines Progrämmchen. Oder soll das quasi ne Seite

sein, die vom so n bisschen wie die Webseiten früher, die quasi vom Server gerendert werden? Das ist ja noch entscheiden, konkret, was heißt was ist der Unterschied zwischen Single Page und Multipage Application bei Single Page Application Lad ich beim ersten Aufruf gleich alles quasi dieser App. Oder diese Anwendung. Ja, und bei Multipage hab ich vielleicht zwischendurch noch mal n gewisses Laden, wenn ich irgendwie ne Seite Wechsel in der in der App oder sowas.

Typischerweise lädst du immer nach, wenn du ne Seite wechselst und auch bei Singlepage ist es auch schon schön. Du hast dann quasi die ganze Grafik schon runtergeladen im ersten Schuss und dann fragst du nur noch die Daten ab und dann wird es nämlich sauber, dann hast du quasi Visualisierung getrennt von den Datenflüssen und die Daten fragst du über eine API ab. Wieso ist das jetzt relevant hier? Wir haben ja so ne so ne to do Liste, selbst wenn die mehrere Kategorien hat, also mehrere

Listen mit Einträgen könnte. An der Seite stehen eigentlich das. Genau, wir könnten das auch anders entscheiden, aber wir müssen es halt irgendwie entscheiden, bevor wir anfangen können, es umsetzen, das Projekt also inhaltlich n riesen unterschied ist, ob du, ob du jetzt hier n reaction view oder irgend sowas aufziehst oder halt irgendwie OK. Gut Singapage Application ist die Single Page Application. Ja.

Genau. Und dann müssen wir uns dann unterscheiden, dann müssen wir uns die Entscheidung treffen und wir, wir treffen auch gleich die Entscheidung. Ich sag nur, welche wir treffen müssen, erstmal zwischen Backend und Frontend muss dann ne Kommunikation entstehen, dein Frontend muss ja mit dem Backend kommunizieren um irgendwie Task

absagen, anlegen und so weiter. Da brauchen wir also ne, ne ne ne Kommunikationsplattform, da gibt es ich sag mal 3 Klassiker, machen wir ne Rest API oder n Graph QLAPI oder nen RPC basiertes System. Können wir uns das? Müssen wir noch entscheiden, wie, wie funktioniert die Kommunikation dazwischen? Und dann müsst ihr noch uns entscheiden und das ist ein schwieriger Punkt, wie halten wir die Daten? In einer zum Beispiel relationalen Datenbank. SQL oder vielleicht in so einer

modernen No SQL Datenbank? Oder vielleicht auch einfach platt als Files gespeichert, irgendwie auf der Platte so ja sogar keine Datenbank. Ja ich stell nur meinen Raum so. Gut also das sehe ich jetzt mal so an Dingern, die wir jetzt mal auf der höchsten Ebene hier entscheiden. Müssen also das war Frontend, Backend, Datenhaltung, Kommunikation. Und die Entscheidung, ob Single Page oder Multipage. Genau, genau. Und ob Docker oder also Microservices, das Architekturmodell. Ja genau.

So, und die treffen wir jetzt mal schnell, die Entscheidung und ich begründe so ein bisschen vielleicht warum? Als erstes müsste man jetzt ne ganz andere Entscheidung noch treffen, bevor man anfängt das alles zu tun. Also im echten Leben würd ich jetzt erstmal googlen, in die Hand nehmen und sagen, OK ne, tut du App was der Geritter will, na da krieg ich ja bestimmt n Tool für ja also ich würd mir jetzt erstmal die nokowar Tools angucken und sagen. Also vielleicht muss ich das gar

nicht neu programmieren. Vielleicht geb ich dem Gerrit irgendwie bast. Bastel ich das mit dem Tool hin, dann hab ich schon fertig. So ja und? Wenn, wenn es jetzt nicht gerade der Podcast werden und und dass n democase ist, so, dann wären wir jetzt schon fertig. Ja, weil die können das Halt die die. Na ja, gut, oder man würde halt mal vielleicht das ist aber ne andere Aufgabe, beratend dem Kunden sagen Mensch, bist du sicher, dass du sowas jetzt noch entwickelt lassen willst?

Da gibt es schon 1000 Sachen, also das ist vielleicht eher. Ganz genau. Aber ist ja egal. Ja, die To do Lab ist ja nur ein Beispiel. Es könnte ja was komplett Neues sein, darum geht es ja. Heute eben. Aber auch da würde man das Fragen und dann typischerweise haben sich die Kunden dann doch schon ein bisschen informiert, ganz oft.

Crm System und so weiter dann ist doch so viel speziell und anders was man haben will als alles das was man gesehen hat und das kann das schon rechtfertigen, dass ich quasi schon so n Projekt noch mal starte. So anyways OK so und dann wie komme ich zu einer Entscheidung? So und jetzt kommt es natürlich, jetzt ist wieder ein bisschen sehr subjektiv, wie mache ich das? Ja ich gucke halt erst mal was ist überhaupt gerade modern und und vogue, was machen die Großen?

Also was machen die Großen vor allen Dingen, wenn die ein neues

Projekt machen? Das kann man, wenn man die entsprechenden Fachzeitschriften liest, ein bisschen den IT SPRECH und den und die Nachrichten verfolgt hatten, das ganz gut irgendwie im Blut und meine Meinung ist, macht bloß nichts spezielles schwimmen wie die Lemminge in der Masse mit, das ist in der Software total gesund weil dann dann hast du viele Leute die dich dafür interessieren, das ist eine große Community, hast eine gute Dokumentation und viele Leute

benutzen es dann auch und wenn sie viele Leute benutzen, dann hast du immer sowas wie too big to fail, weil wenn dann die Großen meinen sie müssen das abschalten. Dann ist es halt wie bei einer zu großen Bank oder irgendwas die wählen lernen zu groß oder das heißt. Du hast ne gewisse. Ja. Sicherheit, dass die Technologieauswahl, die du dann getroffen hast, auch weiterlebt, ja. Weil zu viele dran hängen, einfach ja und ist überall verbaut wird, gibt ja Sinn. Gibt es Sinn?

Genau, und wenn du halt immer je kleinere modulchen du hast, die irgendwie so am Rand randerscheinungen sind, dass das immer größere Problem, dass der Entwickler oder das Entwicklerteam was dahinter steht, irgendwie mal keinen Bock mehr haben oder irgend sowas, das dann halt weg nicht mehr mantained so, dann hast du halt Ärger am Hacken, weil das musste dann über kurz und lang, musste nicht gleich morgen rausschmeißen, aber es musste irgendwann ersetzen und so

weiter hast halt wieder, man muss auch immer Leute finden die sich dann auskennen mit der Technologie, das ist das zweite Problem genau ja genau du musst halt die Leute haben so ja und dann müssen wir natürlich gucken wenn wir das aus wenn wir das geguckt haben, was ist jetzt hier gerade modern und so weiter dann müssen wir gucken was befriedigt tatsächlich unsere technischen Anforderungen. Also wir können ja nicht irgendwas nehmen, was nur modern ist.

Muss ja auch schon das machen, was wir haben wollen. So, und dann ist eine wichtige Frage, was können meine Mitarbeiter? Also das ist ja manchmal eine sehr wichtige Frage. Es kann ja sein, du wirst eine 30 Jahre lang 30 Jahre alte Software Bude und du hast halt ganz früh und das ist auch in Ordnung, was früher modern war, halt angefangen mich PHP zum Beispiel und so, und da ist nichts mit Single Page Application und wenn du denen

jetzt sagst. Der Gerrit will hier ne to do App. Das könnten die mit ihrem PHP und so weiter mit ihrem Stack sofort machen. Sie werden wahrscheinlich in 2 Tagen fertig. Wenn du den aber sagst ich will das aber schön mit javascript und React als Singlepage Application mit einer postgas Datenbank im Hintergrund ist alles mit no TS.

Dann ist das an der Stelle vielleicht nicht die richtige Entscheidung, weil die ja, die schmeißen alle die Hände hoch und sagen ja, OK, ich fang mal, das ist cool, hab ich noch nie gemacht, ich lerne das mal schnell so. Ja, das ist ja ganz spannend jetzt, also ich bin jetzt der Auftraggeber und hab angenommen, ich hab jetzt immer.

Wirklich gar keinen Plan also von von Software und von Technologie, Stack und so weiter und jetzt komme ich stoß ich vielleicht auf irgendwie so eine Firma die was Software angeht vielleicht ein bisschen in die Tage gekommen ist schon ja und da auf dem PHP oder diesen lamps Tag oder was auch immer, dass da damals unterwegs ist. Wie kann ich.

Vorbeugen. Aber ich geh ja nicht hin und sage, ich hätte jetzt hier gerne Single Patch application, no JS, Java, react oder ne carit, da triffst du n Riesenproblem ja da da. Also wenn du halt das ist halt n Riesenproblem, das ist gar nicht so einfach das vorzubeugen. Wenn du das wissen halt nicht hast.

Ja, das ist wie wenn du dein Auto in ne Werkstatt schiebst und weißt du auch nicht ob die irgendwie noch mit dem manuellen Ding darum knebeln oder ob die modern den Fehlerspeicher auslesen, wüsste ich jetzt halt auch nicht.

Ja, ist halt dann müsste es dir vielleicht die Firma ein bisschen angucken also ich sag mal die Gefahr, dass du auf einem alten Lembstag dann irgendwie so ein Ding hinge donnert gekriegt ist halt wenn der Laden. 30 Jahre alt ist und die vielleicht eher nur immer ein Produkt machen oder so. Dann aber ist schwer zu sagen, deswegen machen wir ja auch so n bisschen diesen Podcast. Deswegen gibt es auch no Know Core Tools. Da weißt du, dass immer alles

modern ist. Aber das ist tatsächlich ne schwierige Entscheidung. Ja, an wen gerätst du und der wird dir mit voller Überzeugung sein, dass die beste Software Architektur ja wir machen das mit PHP und nem Stack. Ja das mag auch sein, vielleicht ist das wenn du mit dieser Firma arbeitest. Das hab ich gerade gesagt, auch

das Beste, dass du es so machst. Ob das absolut beste ist, weiß man nicht so gut, aber das ist halt ein bisschen ein Dilemma sag ich mal an der Stelle ja. So, dann ist es noch wichtig, wenn ich, wenn ich jetzt irgendwie die Entscheidung treffe, ist, das mach ich immer so n bisschen, ich hätte dich

auch schon n bisschen gefragt. Am Anfang kann ich mir irgendwelche Türen offen lassen, ich versuch schon n bisschen zu antizipieren was wird Gerrit machen mit seiner To do App und wann ist die ihm langweilig und auf welche Idee kommt er als nächstes, was man dann noch erweitern könnte?

Nicht ein heikles Spiel, und da verrennen sich viele Softwareentwickler. Ich darf es halt mir die Türen nicht zu weit offen lassen und das System halt viel zu kompliziert anlegen für dieses kleine Problemchen, was er jetzt halt haben hat erstmal Gerrit aber es na ja ich ich antizipiere zum Beispiel vielleicht hat irgendwie mal so ein U Date dran setzen oder irgend sowas also wann der Task zu erledigen sein hat und wir vielleicht eine Erinnerung

kriegen also man kann ja das wild werden mit so to do Apps eine Push notification kriegen irgendwie einen Tag vorher und so weiter und so. Fort möchte ich die von der einen Liste in die andere verschieben über. Irgendwelche Geschichten. Und so genau. Das kann wilde Gestalten annehmen.

Also, und hier ist natürlich das die Kunst, und da gibt es auch kein Heil Rezept oder irgendsowas, hier muss man halt gucken, dass man es ja, dass man es halt nicht zu komplex, aber auch nicht zu spezifisch macht für diesen Case, dass man halt solche erweiterungswünsche halt auch irgendwie noch mit an Bord nehmen kann, sage ich mal so, und jetzt entscheiden wir uns, wir entscheiden uns von der Architektur für Microservices, warum weil also warum genau, weil ich habe ja geschrieben,

alles andere ist Wahnsinn. Natürlich keine, keine gute Begründung, so ja, aber innerhalb von Containern können

wir perfekt entwickeln. Also zur Software Architektur gehört ja nicht nur das abgelieferte Produkt, es gehört ja auch der Weg des Produktes mit den Mitarbeitern habe ich ja gerade gesagt und der soll ja auch möglichst elegant, schlank und schnell klappen und wenn ich halt in einem Container arbeite, das hatten wir schon mal die Folge, dann bin ich halt isoliert und dann kann ich wunderbar und sehr stabil alles testen und darin entwickeln, ohne dass irgendwie zum Beispiel

mein eigenes Betriebssystem und das des nächsten Entwicklers oder sowas einen Einfluss hätte auf diese Software, das war früher ganz oft so, da musstest du auch noch quasi dieses Operating System der Entwickler koordinieren und das was die an Abhängigkeiten Leiblich installiert hatten auf diesen Systemen. Damit immer irgendwie ein gleiches Ergebnis kam beim Testen und so weiter und keine Überraschung, alles nicht mehr alles völlig irrelevant, wenn

wir im Docker sind, nur kurz dazu, ja und wir können was ein viel wichtiger Punkt ist, wir können halt wunderbar hosten, weil das muss ich noch mal ganz laut sagen, heute ist es ja so, dass alles was wir kennen an Cloud immer wenn man, wenn man das Wort Cloud in den Wunden nimmt und AWS und Azure und Headner und Yonos und wie sie alles sind. Heißt das, Wir haben hier nur die Benefits, wenn wir eine microservice Architektur gebaut haben, also Container,

Container, Container? Monolithen geben gar nicht so viel Sinn in der Cloud. Und machen nicht so viel Sinn.

Deswegen Docker ganz klare Entscheidung ist auch gerade und vogue ist immer noch voll Hype, alles prima, das geht auch nicht unter fast alle großen Anwendungen sind so geschrieben, können wir so entscheiden so Frontend entscheiden wir uns für eine Single Page Application, weil weil die sind sehr schnell reaktiv du willst in deiner to do Liste vielleicht später auch so Effekte haben wie Drag and Drop und so weiter das soll irgendwie vielleicht irgendwie alles total schnell gehen, sich

super synchronisieren. Also die Responsiveness und die die, die die Effizienz von SP AS ist immer den den den Server Roundtrips von den Multipage Applications, die müssen ja immer noch mal mit dem Backend telefonieren wenn sie irgendwas machen wollen, auch wenn Sie etwas Neues anzeigen wollen. Überlegen. Und wir haben hier moderne Frameworks unterwegs, da würden wir, also ich entscheide mich jetzt für Rect warum, weil ich es gut kann.

Ne, also mit hier kommt der Mitarbeiter, da sind wir halt hier quasi eingefahren mit React und React ist da gibt es überhaupt nichts gegen zu sprechen, man könnte hätte auf View oder Angular nehmen können, egal aber wie, anscheinend ist hier freacture. Und im Backend reckt es n

Framework richtig. React ist n Framework für die um den um diese Grafik zu realisieren für deine To do App genau und diesen Java Script Framework und wenn wir über Single Page Application sprechen, gucken wir eigentlich. Das kann ich auch noch mal sagen, wir wir, da gibt es gar nicht so viel Auswahl, ehrlich gesagt, es gibt halt so 34 große Javascript Frameworks das haben. Wir schon mal besprochen, glaube

ich. Ja genau, und warum halt Georg Java Script, das muss man jetzt einmal kurz wissen, weil die weil die Browser, die können halt. Die verstehen halt Java Script, die verstehen aber jetzt nicht Python von Natur aus ja und auch nicht irgendwelche anderen wilden Sprachen so. Ja also javascript können die

Halt einfach. Quasi in die Entscheidung, wenn man sagt ich möchte ne Web Applikation oder eine die im Browser lauffähig ist, dann ist javascript klar, da gibt es keinen Weg dran vorbei und dann ist die Frage welches Fond ein Framework ich einsetze. Genau dein Lieblingsframework ist an der Stelle React richtig, aber es gibt durchaus Firmen die das anders sehen oder Personen. Richtig.

Genau so kann man es sagen. Jetzt kommt so also ich korrigiere so ein ganz bisschen hin, es gibt jetzt kommt so ein bisschen der Mode auf Web Assembly, das ist jetzt nicht Java Script, das ist quasi kompilierter Code, ganz besonders schnell ausführt und im Browserübergreifend funktioniert ist was ganz modernes, kann ich leider heute auch hier noch nicht so viel zu sagen, weil ich leider noch nicht Zeit hatte, mich da in Tiefe zu verfassen, da machen

wir bestimmt mal eine Folge drüber, das ist nämlich total spannend, aber. Javascript ist erstmal gesetzt und jetzt ist es so. Jetzt müssen wir uns entscheiden. Quasi jetzt müssen wir uns überlegen, was ist das Backend. Das Backend ist nämlich der Server, ne der der deine, deine, dein das Initiale zur Verfügung stellen. Deiner Single Page Application. Garantiert ne. Das ist derjenige, der die URL

auflöst. Du wirst ja von mir dann irgendwie nen Link bekommen, dann sag ich dir Gerrit, hier ist deine to do App unter HTTPS doppelpunkt doppelslash. Irgendwas ja, und wenn du das Eintippst, dann wirst du quasi einen Server kontaktieren, der in der Cloud bei zum Beispiel Hezner oder Jonas oder wo auch immer steht und da gehorstet wird, der wird eine IP Adresse haben, das hab ich dann alles für dich gemacht. Und ich hab dann quasi diese

diese URL. Diese Domainnamen hatten wir auch, ne Folge schon eingetragen in ne Registry, sodass wenn du diesen Link eingibst, genau dieser Server angesprochen wird und auf diesem Server muss aber da n Programm laufen, der muss quasi lauschen, der kriegt quasi nen. Netzwerkinquest rein und dann müssen Sachen passieren und das muss auch entwickelt werden. Ja, da müssen 2 Sachen passieren, da muss halt diese, da muss halt diese Anwendung

ausliefern. Und er muss quasi ne Schnittstelle zur Verfügung halten, dass du deine Tasks anlegen kannst. Neue Liste anlegen kannst, Task anlegen kannst, das löschen kannst und so weiter und sofort. Ja das macht das ist der Backend Code. Jetzt habe ich wieder. Jetzt habe ich wieder eine Riesen, ein Riesen ja Auswahl in welcher Technologie ich das machen kann, denn das muss nicht die Technologie des Frontend sein, weil das Backend quasi in seinem eigenen Container wieder

läuft. Ne also ich würde das Frontend kommt in den Container und das Backend kommt in Container, das heißt ich kann da jetzt auch Python nehmen oder Go oder Ruby und Rails und so weiter und es gibt ziemlich viele Frameworks also ich sag mal was wenn ich Python jetzt toll fände könnte ich zum Beispiel Django nehmen, das ist ein Python Framework, also ein Backend Framework womit ich ganz easy Rest AP is herstellen kann und die verwalten kann usw.

Das würde ich jetzt hier an dieser Stelle nicht machen, aber grundsätzlich wieder die Entscheidung Programmiersprache, die ich wähle, Programmiersprache genau. Für ein Framework. Und dann für ein Framework. Ja genau da sagst du was, das habe ich ja, erzähle ich mal, so leicht. Eigentlich ist es nicht nur die Programmiersprache, aber denn, denn du machst heute nichts mehr

ohne Frameworks, sage ich mal. Es gibt also es gibt Frameworks, die machen natürlich viel mehr und einen machen ein bisschen weniger und so weiter auf verschiedenen Ebenen und. Aber du würdest also jetzt so ne so n Klassiker wie ne rast API oder Irgendsowas, also die Schnittstelle zum Frontend sag

ich mal. Wie auch immer die aussieht die die machst du wirklich nicht mehr ohne Framework, nur pur in der Sprache ne also dann da du suchst dir quasi Technologie aus und dann ist quasi schon n bisschen festgelegt. Innerhalb der Technologie gibt es dann quasi die Top 3 Frameworks oder Irgendsowas also ich sag mal bei Python würde man wahrscheinlich Django nehmen sag ich mal so das ist das Framework um solche Web apis herzustellen und in Node js.

No js ist quasi das Java Script des Backends. Also no js ist quasi nichts anderes als Java Script, nur das ist quasi auf dem Server laufen kann. Und da hast du typischerweise den Express Express js quasi.

Gibt dir halt einen Webserver. Also wir müssen ein Webserver programmieren, das ist ja das so und das Ganze zum Beispiel mit Express js super machen und dann gibt es zum Beispiel wenn du jetzt eine ganz andere Sprache nimmst früher, ich weiß nicht wie das Moderne ist so vor 56 Jahren, oder das war irgendwie Ruby, also. Programmiersprache und dann gab es dieses Framework, Ruby on Rails.

Die Leute kennen fast immer nur Ruby on Rails, damit ist das bekannt geworden, das ist irgendwie ganz dicht beieinander, so ein Ruby On Wales ist halt quasi das analoge zu Django, das analoge zu Express, JS und so weiter so, das gibt es halt für jede Technologie und im Prinzip kann ich mir das frei aussuchen im Prinzip, ich würde mich jetzt wieder entscheiden für no js warum, weil wenn ich schon javascript implementiere und ich das Full Stack mache mein Team

klein ist. Dann ist es voll praktisch, wenn ich die gleiche Programmiersprache im Backend und Infrontend benutze, komme ich nicht durcheinander, ist so wie als würde ich irgendwie im Büro andauernd irgendwie zwischen Englisch und Deutsch switchen müssen. Kann ich machen, das ist auch kein Problem. Ist aber halt anstrengender, wenn ich jetzt nur eine Sprache, wenn ich nur Englisch sprechen würde oder nur deutsch ist halt cooler, so sehe ich es einfach ne.

Klar, auf jeden Fall und wahrscheinlich noch noch stärker bei einer Technologie dann. Deswegen würde ich sagen, würde ich jetzt sagen, wir entscheiden uns für No js im Backend mit Express js als Webserver. Da kann man super prima. Rest APIS bauen, dafür würde ich mich auch in diesem Falle entscheiden und nicht Graph QL. Das heißt, OK, Die Entscheidung ist jetzt gefallen. Frontend, das war Java Script mit reckt Backend ist NO js mit Express.

Js du hast dich schon entschieden für eine microservice Architektur und du bist jetzt bei der Kommunikation. Also das Thema, Ach nee genau Kommunikation wie kommuniziert Fondant Backend genau mit Datenbank eigentlich. Genau, ganz genau, ganz genau. Das ist jetzt noch die Frage und ich würde jetzt sagen, wir machen es ganz klassisch und machen eine Rest API, das hatten wir auch mal eine Folge, ich erzähle es auch gleich noch mal, wir kommen gleich noch mal drauf, was das dann genau

bedeutet. Wir hätten jetzt auch Graph QL nehmen können oder irgendwie einen RPC Mechanismus. Würde ich an dieser Stelle alles nicht machen. Wir machen Rest API, das heißt das heißt aber als Konsequenz an dieser Stelle müssen wir einmal aufpassen, denn wir hatten ganz am Anfang den Anforderungen aufgenommen, dass du ein Update kriegen sollst, wenn zum Beispiel Lara von Dir ein Task abhakt, jetzt ist es so und jetzt müssen einmal, das heißt du kriegst, du sollst eigentlich.

Event aus dem Backend bekommen zu dir, das nicht so einfach zu lösen mit der Rest API weil ne Rest API im Prinzip das nicht unterstützt, dass du Events aus dem Backend in dein Front End

kommt. Das ist jetzt, das ist halt Software Architektur, solche Sachen muss man halt wissen, man muss halt die auch wenn man die Technologien auswählt genau wissen, wie funktionieren sie tatsächlich und was sind die Limitierungen und das muss man jetzt hier an der Stelle wissen, dass das nicht so einfach geht, das kann man aber trotzdem lösen, indem du polst und das ist in diesem Falle verträgt vertretbar, weil du nur diese einen Informationen Pollen

willst. Du musst halt quasi dann, wenn du deine App anmachst was dann passiert ist. Du fragst halt in regelmäßigen Intervallen. 5 Sekunden oder 10 Sekunden reicht ja vielleicht ja, reicht ja völlig, fragst du halt ab, gibt es ne Änderung, gibt es ne Änderung, gibt es ne Änderung die du halt nicht veranlasst hast? O. K bei Rest API muss ich also Pollen um aus dem Frontend Events aus dem Backend zu bekommen. Das ist die richtig, das ist die Aussage. Wenn du es ganz trivial machst.

Man kann Rest AP is auch aufbohren. Es gibt so long, Pols und so weiter es gibt Mittel und Wege es etwas schicker zu machen. Kombinierst es mit einem Websocket, dann hast du aber nicht mehr pur. Rest API im Prinzip und ist halt aufgebaut. Das West API Gedöns so ja wenn wir es aber schlicht lassen wollen was ich jetzt empfehlen würde für die App dann dann Pollen wir. Auch in Anbetracht dessen, dass wir vielleicht noch was davon sagtest, Anforderungen noch da

hinzukommen. Von von meiner Seite, dass ich über die Zeit überlege, ja, die App sollte dies noch können, das noch können, auch dann ist API jetzt hier noch eine solide Entscheidung. Richtig, weil die, weil es so sein wird, dass du trotzdem nur immer wieder nur diese diese Informationen dieser to do listen. Aktualisieren möchtest, egal was dann noch so passiert. Ja, also das Pollen wird nicht mehr werden, du wirst also ich

würde dann vorsichtig werden. Wenn man also jetzt eine Anwendung hat, wo man alles mögliche, die ganze Zeit Pollen muss, dann ist das vielleicht die Rest ipi nicht mehr das Richtige. Soldaten oder so ein Kram. Genau also so io t. Also wenn ich jetzt jeden einzelnen Sensor und ich habe irgendwie hunderte oder Tausende davon, wenn ich die alle einzeln Pollen müsste die ganze Zeit, dann wird das relativ unübersichtlich. Im Klient steht natürlich viel Netzwerk Traffic, der im Prinzip

kein. OK, keinen Nutzen dazu, aber hier ist es vertretbar würde ich sagen, verstanden und jetzt müssen wir uns noch mal kurz mit der Datenbank entscheiden oder auch nicht oder was oder wie und tatsächlich.

Das ist so krass. Ich hab bei der Vorbereitung dieser Folge hab ich mir gedacht, so OK, das muss ja eigentlich trivial sein und nicht also so ne to do Anwendung irgendwie mal hinzubasteln ich bin echt hängen geblieben bei der bei der bei der Entscheidung tatsächlich weil ich hab mich ja entschieden, ja um Euch das hier mitteilen zu können. Was für ne Datenbank wir eigentlich nehmen.

Dann und als erstes hab ich gesagt ich ich teile einfach mal wie ich gedacht hab ja ich hab erst gedacht so ja OK total easy diese Listen und und und diese Tasks das kannst du halt in einem Jason in einem Jason Objekt darstellen und die klatscht halt einfach auf auf die Platte und liest die halt irgendwie aus. Also gar keine Datenbank, gar keine datenbasierte, genau fallbasierte Datenhaltung. Richtig. Warum habe ich das gedacht?

So weil, weil wir ja gar keine relationalen Anfragen auch haben und so weiter das ist ja, was willst du denn machen, wenn das Frontend aufgeht, quasi wenn der Programmcode geladen wird, dann will ich halt einmal. Die Liste laden, die da quasi encodiert ist über den Link. Wir haben ja gesagt, in der URL steht irgendwie reinokodiert im Prinzip die die ID von der Liste, die du jetzt nur gerade angeschaut haben möchtest.

Und dann hole ich mir halt dieses Datenobjekt das ganze Ding, weil du willst ja sowieso alle Tasks davon anzeigen. Also ich habe hier nichts mit mit wenn wann, wie, was und und und und und und irgendwelchen Curies auf dem Backend früher als so und so und order by und so habe ich alles nicht, also nichts relatives, ich habe auch keine mehreren Tabellen, das kann alles einfach sein. Dann hab ich gedacht, OK, das ist ganz klar, wir brauchen gar keine Datenbank, ja.

Dann hab ich mir überlegt, aber wenn ich das, wenn ich das jetzt hier den Zuhörern verkaufe. Auch schwierig, weil warum jetzt muss man gucken, gibt es Technologien, gute Technologien? Die dir es erlauben, die die, die die feinste Persistieren und zu verändern und in der Datenbank in No JS und leider, leider, leider gibt es eigentlich nicht so richtig überzeugenden Krams. Ich weiß nicht genau, warum es so ist, aber es ist einfach so. Ja, es gibt, ich sag es einfach,

es gibt. Ist heißt es ja, aber früher benutzt, aber da gibt es n paar Schwierigkeiten bei der bei der Asynchronität und das ist wichtig, wir wollen ja das auch schnell machen. Ja, also Datenbanken sind ja deswegen auch da, weil die besonders schnell. Im Daten manipulieren und auslesen können ne wenn ich jetzt irgendwie hemdsärmelig das selber mache, hätte das jetzt empfohlen, schreib es ist auch nicht schwierig.

Ja ich kann einfach n Pfeil schreiben mit Jason Jason Pfeilschreiben und es wieder lesen. Aber dann mach ich das synchron, wenn ich hemdsärmelig mache.

Synchron heißt, ich mach halt quasi das ne, also du bist ja nicht nur du, vielleicht die, die willst ja nicht nur du die Anwendung benutzen, sondern vielleicht sind später gleichzeitig 1000, die irgendwelche Tasks machen und dann hab ich also dann hab ich viele gleichzeitige Lese und Schreibzugriffe aus file System, was ich selber irgendwie hin programmiert habe und das ist dann nicht asynchron, weil wenn ich es asynchron mache muss ich sehr scharf drüber nachdenken

mit während ich schreibe was passiert wenn der andere liest und so weiter da fängt es an richtig kompliziert zu werden. Ist nicht so einfach, deswegen habe ich gedacht, Boah, das kannst du eigentlich auch nicht empfehlen.

So, jetzt also nehmen wir doch eine Datenbank so, und dann habe ich überlegt, ok, dann müsste das eigene No Sequel Datenbank tun, so dann habe ich über, dann habe ich kurz geguckt, was nimmt man da mongo db Mongo DB jetzt kommt was ganz subjektives schließe ich aus weil ich finde den Namen schon mal totale Katastrophe wie kann man eine Datenbank Mongo DB nennen so ja und Mongo hatten wir mal benutzt, die haben halt das ist ein Projekt die die waren Open Source war alles frei von einer

auf den anderen Tag haben wir gesagt Eat besteht so ja wir mussten es halt einkaufen ja. Und er hat, das hat viele Leute sehr stark geärgert. Mich hat das so hart geärgert, dass ich einfach nicht mehr benutzen würde. Ja, fällt also auch weg und dann bleibt eigentlich nur noch 1 übrig, wo ich sage, OK, das das ist ne valide Lösung, n bisschen vielleicht zu dicke Kanone für das kleine Problem machen wir jetzt trotzdem. Und wir holen die Postgrad

Datenbank raus. Also ne SQL basierte Datenbank, da ist das im Prinzip das geilste Ding was so was richtig cooles Halt postgrass immer noch maintains super schnell, super cool und da knallen wir noch NORM dran. Denn wenn ich jetzt nur die Post West Datenbank hab, dann muss ich mich auf einmal mit SQL beschaffen und so weiter und dann diese SQL Outputs die einfach nur stringen sind.

Muss ich dann wieder umwandeln in meiner für meine Rest API und da wieder Jasons rausmachen und um die Jasons Front End zu schicken und so weiter dann hab ich die nächste Woche programmiert. Also da gibt es sowas wie NORM, das heißt Object Relations and mapper. Das ist quasi nen Framework um Datenbanken abzufragen.

Punkt ja und jetzt macht es dir halt viel ein und das ist halt nen n javascript Prämie was ich dann brauche und dann krieg ich quasi schon meine meine Objekte die ich Anfrage in der Datenbank direkt als Objekt tatsächlich und schön hinstrukturiert kann ich einfach weiterreichen auf standardtechnologie standardtechnologie ich sag immer nehmt einen Orm also das ist zum Beispiel eine Komponente, die hab ich noch gar

nicht erwähnt, die kommt aber. Die ist Folge von der Entscheidung, dass ich ne relationale Datenbank einbaue. Dann benutze ich typischerweise ein Oam, das abstrahiert hat, auch quasi über die Datenbanken hinweg, dann könnte ich quasi die Postguards austauschen gegen eine My Sequel oder gegen irgendwas anderes oder Microsoft Datenbank und es würde trotzdem noch funktionieren, weil in diesem Oam steckt diese ganze.

Detailarbeit quasi über diese ganzen Unterschiede, diese kleinen Unterschiede dieser Datenbanken, Interfaces drüber hinwegzuwischen, ich krieg halt immer eine schöne Antwort, sequalize ist da was, man nimmt in Notjs. Einen Sicolace macht sowas ja. OK gut, lass mich kurz rekapitulieren. Also du hast gesagt was die Anforderungen angeht würde es ja eigentlich NN fallbasiertes

System tun. Ja weil ich einfach n Jason oder oder n anderes Jason ist das modernste an der Stelle wahrscheinlich ihr könnt auch Yammel nehmen denk ich mal so n Kram ne einfach einfach beschreibe und und auslese man muss sich erstmal überlegen ist das in irgendeiner Form jetzt soll ich mal zukunftsfähig oder oder skalierbar oder was ist wenn da mal noch ein bisschen mehr als Geredularer in die App nachher reingehen und das benutzen wollen, ja dann kommt

das vielleicht an seine Grenzen und du kannst eigentlich guten Gewissens. Vorschlagen hier im Podcast irgendwie keine Datenbank an der Stelle zu verwenden. Also deine Datenbank Mongo DB stehst du aus aus Gründen und Postgres ist einfach dann das Mittel der Wahl. Am modernsten, am besten. Vielleicht noch Couch, DB Couch db ok, sowas wie mongo glaube ich, aber ich hab einfach überhaupt gar keine Erfahrung mit Couch DB. Das ist vielleicht ne super Lösung, eine bessere.

Das würd ich jetzt, wenn ich jetzt n bisschen mehr Zeit hätte für wirklich dieses Projekt, hätte ich das vielleicht, mir hätt ich gesagt, Gerrit, Ich geh noch mal, guck mir noch mal an, vielleicht coacht die Biere. Da ist ja die Frage, ob du denn die Zeit investierst, um dir noch mal was anderes anzugucken. Oder wenn du. Sagst Let's go, Ich nehm das was ich kann, richtig. Und das ist ja auch nicht verkehrt an der. Stelle.

Nee, genau, und vielleicht sogar risikoloser, weil immer wenn ich mir was neues angucke, ist die Gefahr, dass ich noch was nicht ganz verstanden habe und Fehler mache, ja viel größer, also deswegen genau bei Software Architektur spielt auch immer eine Rolle, hatten wir vorher gesagt, was kann ich gut, wo fühle ich mich wohl, was? Intim?

Ja, dann wird das Produkt besser, aber mit dem Kaviar, dass ich trotzdem nicht den den letzten alten Fisch da raushole, so, ja muss man dann halt irgendwann, irgendwann sollte man sich Coach TV dann mal angucken, vielleicht nicht für dieses Projekt, aber vielleicht ist übernächste kann man dann ja damit realisieren, ne OK. Perfekte Zusammenfassung.

Danke, genau jetzt sind wir eigentlich, jetzt haben wir relativ viele Entscheidungen schon getroffen, jetzt können wir im Prinzip. Jetzt können wir mehr Entscheidungen noch treffen. Es geht jetzt natürlich, es ist immer noch auf einem sehr hohen Level, aber jetzt kann man ein bisschen reingehen. Machen wir auch noch kurz.

Es wird diesmal bisschen längere Folge, aber ich hoffe, es ist mit reingehen noch mal in die Details der einzelnen Bestandteile oder was ich hätte jetzt noch mal gesagt zum allgemeinen Aufbau von dieser Architektur ich. Normal, wenn wenn du. Ja, mach mal so n gern noch mal

so n Rapper so n Überblick. Ich versuch das mal ja genau, also ganz allgemein haben wir jetzt n Frontend, n Backend und ne Datenbank ausgesucht und die würden ihn jetzt in der microservice Architektur jeweils einen Container bekommen, das heißt es laufen dann 3 Container. Dann kann man sich jetzt schon im Kopf vorbereiten, ob man das will oder nicht. Optional wird n vierten Container eventuell vorsehen, das ist n Reverse Proxy. Der wäre dann interessant, wenn man quasi die Anwendung

irgendwann mal skalieren will. Würde quasi der die erste

Annahme machen und dann könnte man quasi mehrere Frontend Container haben, weißt du und der der würde quasi verteilen auf verschiedene so wenn der wenn der das gar nicht mehr schafft, ja, aber den lassen wir jetzt mal kurz weg, also wir bleiben erst mal bei den Dreien vor. Allem das würde ja auch zu dem passen, was du immer sagst. Skalierung ist das Nummer 1 Problem über das alle reden und sich kümmern, ohne dass sie es haben, oder?

Ganz genau, ganz genau. Das ist ja das schicke an den Microservices. Den kannst du halt immer noch easy Dranstecken, ohne dass du irgendwie Schmerzen bekommst, weil alles so schön. Gekapselt ist in den Containern so und dann jetzt würde ich jetzt würde ich sagen, okay, das haben wir jetzt müssen wir überlegen, wie bauen wir das alles zusammen, wo entsteht der Code und da muss man jetzt auch eine Entscheidung treffen. Architektur, Entscheidung finde

ich. Andere würden sagen, OK, das entscheidet jetzt das Entwicklerteam.

Würde sagen, Nein, das entscheidet der Softwarearchitekt hinterleg ich das jetzt alles in einem, also fast wie n Ordner ne pack ich das alles in einen Ordner und versioniere alle 3 zusammen, sehe das quasi als zusammenhängendes Projekt an, das wäre quasi der Mono repo Approach ich weiß nicht ob du das schon mal gehört hast oder ich mache halt mehrere kleine Repositories, also quasi mehrere Projekte, nur das Frontend, das Backend und die Datenbank gibt

das vielleicht verschiedenen Teilen von meinem Team und auch alle 3 Komponenten werden individuell versioniert. Halt irgendwie versionsmäßig zusammenstecken. Ja die frage bisschen überdimensioniert für diese 3 Container, die wir jetzt gerade haben, aber im Prinzip ist das immer ne Frage die sich stellt und da gehen religiöse Kriege

los oder das ist schlimm. Ja und also ich ich gut ich darf es jetzt selber entscheiden, bei mir gibt es keine Diskussion mehr, ist halt Mono repo fertig aus ist halt viel einfacher, denn ich will ja für dich ich begründe das aus meiner Sicht es gibt 1000 Gründe warum es nicht so machen könnte, aber du sollst diese to do App kriegen wenn ich alles in einer in einer Coatbase habe, weiß ich dass es zusammen passt.

Dann kann ich so testen, dann schreibe ich eine Version dran und muss nicht muss nicht bangen, dass irgendwas nicht zusammenpasst oder irgendsowas. Halt auch für alle Entwickler, die da mal gucken sollen. Dann dann die Wissen die halt auch genau was jetzt gerade Phase ist und was zusammengehört. Ja einfach weil es zusammensteht im Fall. Ja, die Falschwertigkeit heilbar. Was wären jetzt die Argumente der anderen Fraktion, also die sagte ja.

Ein ein repo pro Container wahrscheinlich dann oder pro Microservice. Ja, es hat das mit der Arbeitsweise dann später zu tun. Wenn du jetzt quasi wenn du ne Mono repo Code editierst vom Frontend und machst n commit, dann ist das quasi eine ein Versionsupdate.

Zwar hast du nur ne Änderung von Frontend gemacht, aber das Backend und die Datenbankaspekte sind trotzdem mit upgedatet worden, das heißt man kommt sich härter ins Gefecht wenn du jetzt nen und das müsst ja nicht so sein, hätte ich jetzt das Frontend losgekoppelt in sein eigenes Repository, dann können die da Gas geben und ihre agilen Sprints machen und so weiter

und. Dem Backend nichts zu tun und die haben vielleicht einen ganz anderen Pace und machen ihre Versionierung und müssen nicht auf Konflikte achten und nicht

sich andauernd den Code abgeben. Du musst ja immer wenn wenn der die Front entläute was gemacht haben, dann musst du als Back End auch wenn nichts passiert ist musst du deinen Code ja mal wieder synchronisieren und so weiter das kann halt nerven so ja man kann halt wenn man so eine starke Trennung hat in die nicht alle Full Stacks sind wie man sagt, sondern es gibt Halt Frontendlers und Backendlers und die sich nicht ausstehen können, dann ist es vielleicht schöner man hat es irgendwie in

getrennten Repos so ja bloß ich sage halt wenn die sich nicht ausstehen können und arbeiten sowieso gegeneinander, dann kannst du deine to do App dir auch gerade in die Haare schmieren, aber das. Nehme ich nichts. Hast du das Problem auch an einer anderen Stelle? Also wir machen einen Monorail, machen wir genau und jetzt gibt es noch so ein paar Entscheidungen.

Jetzt haben wir ja die, die die Dockers und so weiter jetzt hast du bestimmt auch schon mal gehört, Orchestrierung von Containern, so ist das Fachwort Orchestration ja Container Orchestration warum Orchestration, weil wir ja nicht nur einen Container haben, haben wir gerade gesagt, wir haben ja mindestens mal 3 bei uns. Und die müssen ja jetzt irgendwie alle 3 hochfahren und alle 3 runter und alle upgedatet

werden. Ne und irgendwie haben die was miteinander zu tun, das nennt man Orchestrierung zwischen Containern, die müssen in einem eigenen Netz sein und sich verstehen und so weiter und sofort, ja und vielleicht in der richtigen Reihenfolge irgendwie gestartet werden und so, keine Ahnung, ja das alles Orchestrierung.

Und. Ich mach mal n Buzzword so wenn man Orchestrierung richtig krass treibt über verschiedene Hardware Server hinweg auf der Welt verteilte DATENCENTER und so weiter aber eine Anwendung quasi trotzdem bleibt ne und das du hast quasi so nen internationalen Dirigenten, der das alles dirigiert, dann kannst du sowas wie Kubanitus rausholen, das hast du schon gehört, das ist so die die dickste Waffe der Orchestrierung von Containern.

Ich würde jetzt hier an dieser Stelle sagen, Gerrit Du kriegst kein Kybernetik auch gerne wenn du es gerne hättest oder klingt cool so. Ja Kybernetik ist ja cooler Name. Brauche ich jetzt für meine Kultur brauchst du nichts, aber muss man sich Gedanken drüber machen und. Du willst sagen, es gibt Anwendungsfälle dafür, man sollte sich aber gut überlegen, ob kubanitis und so eine Containerorchestrierung mit Kubanitus. Genau.

Ich würde dir sagen, Garrett, wenn deine, wenn deine Anwendung so cool ist, dass wir irgendwann mal weiß ich nicht 100 000 Klicks haben pro Zeiteinheit und das irgendwie so durchgeht wie was weiß ich, dann müssen wir das schon mal mit Kybernetik skalieren. Vorbereitet. Gerrit, Weil wir alles schön in Containern haben und haben es alles sauber. Da machen wir das später.

Jetzt machen wir erstmal Orchestrierung mit Docker compose, OK auch mal n wichtiger Punkt und da kann man einfach mutig sagen, das ist überhaupt kein Problem Docker compose es kommt halt mit Docker mit also ne dieses dieses Docker ist ja nichts anderes auch wieder als im Prinzip eine Anwendungssoftware die oder ein Tool, ein Entwicklertool was uns hilft und Docker kommt mit Docker Compose mit und das Docker Compose ist nichts anderes als ein yamify man

könnte es auch ein JSON hinschreiben wo quasi jeder Microservice eine Abteilung hat, da spielt es dann tatsächlich drin, Frontend Doppelpunkt und die ganze Konfiguration von Front End Backend, doppelpunkt, unser Backend Krams und dann noch Database doppelpunkt usw. Und das alles in schönem Pfeil.

Und wenn du es starten willst, dann sagst du einfach nur noch Docker compose ab und dann hat es schwul und alles kommt hoch und alles fertig und das wo passiert das im Backend, also in der Anwendung die auf dem Server im Internet liegt, das ist nochmal wichtig zu wissen, ja und diese Anwendung startet tatsächlich auch das Frontend, das ist jetzt ein bisschen komisch im Kopf aber und das Frontend würde dann quasi runtergeladen werden können von einem von einem Browser.

Und jetzt müssen wir noch mal kurz gucken. Das ist nämlich auch wichtig, wenn wir das React machen.

Was entsteht denn, wenn wir mit dem React fertig sind, dann steht nämlich ein Programm in Java Script geschrieben, ja, nämlich dieses ganze Frontend Anwendung, das was du dir am Anfang runterziehst, was alles rendert das CSS und so weiter ne und wo auch drinsteht wie die API Calls zu laufen haben später da steht alles in diesem Programm schon drin, das muss jetzt zur Verfügung gestellt werden, auch von einem Webserver, wir haben nämlich einen Webserver der Dir dieses

dieses javascript Programm für das einmalige Runterladen zur Verfügung stellt und. Zweiten Webserver, nämlich den Backend Webserver, der dir deine API Requests beantwortet. Sind wir noch in der Softwarearchitektur hier gerade ja, OK, gut. Ist wichtig, denn das muss man planen. So und für diesen Webserver, den da musst du auch ne Technologie aussuchen, der dir quasi dein javascript Content zur Verfügung stellt.

Da gibt es sowas, das sind da, da nimmt man halt n Proxy ja n Forward Proxy zum Beispiel, den man auch als Reverse Proxy

machen könnte. N Enginex ja, den wenn wir jetzt kein Reverse Box extra machen, dann nehmen wir Engine X als beides, dann ist das quasi unser Reverse Proxy, der macht dann SSL Termination, das müssen wir auch noch denken, wir müssen überlegen, wo muss man Zertifikate reingeben, denn du willst ja eine sichere To do App haben, das heißt du wirst sie mit sowas wie wenn du kein Geld hast Let's encrypt Zertifikate zaubern, das kann man machen, die sind dann auch quasi die

Erkennen die Browser erkennen die als gültig an, die musst du aber relativ oft updaten, das ist halt der Nachteil ich glaube. Alle 4 Monate laufen die aus und diese Zertifikate gibst du rein in dein Frontend Container, der mit einem Enginex quasi dein Java Script Bundle was du gebaut hast mit React zur Verfügung gestellt für den Client das das muss man auch mal so im Kopf haben, da muss man auch eine Entscheidung treffen. Das wiederhole ich jetzt nicht.

Das macht aber nichts. Vielleicht haben wir ein paar Leute, die jetzt ausgestiegen sind, das macht nichts, nicht so schlimm, aber ich wollte das nur noch mal sagen, was zur Verfügung gestellt werden. Irgendwie. Ja, das ist eigentlich die Kennwortschaft, oder? Ja, genau. So, und das war der, das war

der, das war der Überblick, so wird es aussehen, ne. Und jetzt könnten wir. Jetzt geht es natürlich noch weiter. Im Detail müssen wir jetzt die Datenbank designen, ne, wie sieht die Datenbank aus, das Modell und so weiter und sofort hier würde ich ich mache jetzt ein bisschen schneller, dass wir auch zum Ende kommen, aber ich ich würde hier könnte man jetzt typischerweise wenn man sagen,

OK, wir haben hier listen. Und wir haben Tasks, also könnte man 2 Tabellen machen, Listen und Tasks, und die haben irgendwie, die haben ne Assoziation. Ne list has many tasks oder andersrum gesagt task belongs to list. Ne, dann haben wir so ne ne 1 zu n Beziehung zwischen Task und ne kann man alles machen. Kurz überlegt hab ich gesagt, nee, machen wir nicht, warum nicht, wir benutzen jetzt einfach diese Datenbanken, das ORM nur als Vehikel um das ganz einfache auch einfach zu lassen.

Ja, du kannst nämlich, das ist auch wichtig, das ist auch entscheidend in der Datenbank, entweder alle einzelnen Einträge. Aufspalten du kannst zum Beispiel sagen, OK, das ist der to do Text, das ist ist abgehakt und so weiter alles als obere Tabelleneinträge quasi nehmen und dann die Datentypen festlegen. Oder du sagst einfach nö hab ich alles nicht, hab irgendwie n Ding, das heißt Data und da ist n json hinter, du kannst nämlich in der Datenbank in der Datenbank json Objekte

speichern. Verstehst du den Unterschiedgerät? Also ja, verstehe ich. Entweder habe ich ja 2 Tabellen die sich aufeinander beziehen oder ich hab halt alles untereinander geschrieben und definiere in dem. Eintrag quasi zu welcher

Kategorie es gehört. Eigentlich ja genau, ich würde nämlich jetzt auch sagen, wir haben nur eine Tabelle, die heißt halt irgendwie Listen so ne und die hat im Prinzip nur ein Data Objekt, die hat also ihre Primary id und alles was ihr so braucht created add und so weiter das ganz klar auf der oberen Ebene typischerweise aus dem created add und updated add damit du siehst von das letzte Mal bearbeitet wurde und so und dann hast du aber eigentlich als Content.

Einen Data Dings und da drin ist ein JSON file und das hat zum Beispiel die Tasks drin, einfach als Array. So habe ich es mir nicht vorgestellt. Aber jetzt habe ich. Es verstanden OK, weil also da, da würde jetzt. Aber ist ja schon sehr viel Detail jetzt. Also ich muss mir eigentlich ja das was du sagen willst du, ich muss mir Gedanken drüber machen, wie baue ich meine Datenbank auf. So und jetzt für das Beispiel To do List bietet sich das.

An ja nicht unbedingt, das sind ja die schwierigen Software Architektur, fragen warum ich tease noch mal kurz warum wenn. In der Datenbank ein kompliziertes relationales Modell mache, was man eigentlich machen würde. Es wäre jetzt auch mein erster Habit, würde ich sagen, OK, wir haben diese 2 Tabellen, die setzen wir in Beziehung und so weiter das ist auch alles OK, ja dann kannst du das rausholen, jetzt wusstet ihr aber überlegen. Was soll eigentlich am Ende passieren?

Ich will nämlich am Ende im Frontend, nachdem ich die Rest API angefragt hab, ne ne ne Datenstruktur haben und zwar in nem Jason Objekt quasi im Rahmen was so strukturiert ist, dass sie es auch schick rendern kann, dass sie chic anzeigen kann, denn wenn es noch nicht in dem Zustand ist, muss ich das halt schon wieder umformen und immer wenn ich Daten die ganze Zeit umformen muss, habe ich Fehlerquellen und habe ich natürlich Zeit. Überlegst du es gleich so ab,

wie du es anzeigen? Willst genau das ist der Punkt, das will ich damit sagen. Man kann schon finde ich ist meine Meinung. Man kann schon gerade bei so kleinen Projekten. Ich sag mal die Best Practice ein wenig Dehnen auf der Datenbank Ebene und ist lieber so ablegen, dass es zu der sehr ähnlich ist. Zu der Datenstruktur, die ich auch später wirklich in die Hand nehmen möchte. Frontend, weil dann kann ich auf diesen ganzen wegen wo das alles gereicht wird.

Ich habe ja auch noch eine Rest API wo der Handover kommt von der Datenbankstruktur. Zu dem Frontend dann kann ich das Objekt halt lassen. Kann ich. Wahrscheinlich immer dann besser machen, wenn ich genau weiß, wie, wie ich die Daten im Frontend nutze und Anzeige und so weiter je flexibler ich vielleicht sein will, auch verschiedene Ansichten habe oder verschiedene Front Ends, desto generischer würde ich die Daten dann vielleicht.

Ja, und es hat noch einen riesen Vorteil, wenn ich halt quasi die Daten in der Datenbank als als primäre Daten festlege, dann hat man so ein Problem der der Shima Evolution oder oder Migration. Wenn du dann sagst okay ich möchte aber jetzt noch ein neues Feld haben oder irgend sowas, dann fange ich an die Datenbank irgendwie umzuknebeln das ist immer eine Hölle wenn ich wenn ich quasi die Datenbank layout ändern muss habe ich. Jason kriegt die Datenbank davon nichts mit weiß wieso.

N Blob ist so ja und und ganz oft ist es überhaupt kein Migrationsproblem, wenn ich beim Jason irgendwie was ranklebe oder nicht, das kann ich im Frontend ausfiltern, so ne, deswegen sag ich ist meine meine Meinung ist heutzutage macht die Datenbanken nicht mehr so kleinteilig und so kompliziert. Pack da lieber Jasons rein, die vielleicht dann sogar auch mal n

Array haben. Also die quasi nesting haben ne und eigentlich ne Assoziation sogar ausdrücken zwischen zwischen verschiedenen Dingen. Das ist jetzt keine allgemeine,

aber kann also ich würd es in der to do App so machen, ne kann von großem Vorteil sein, ne. Ich glaube ist klar geworden, dass man sich darüber Gedanken machen muss. Und es gibt wieder verschiedene Optionen. Ja, prima, so, und jetzt machen wir noch als allerletzte Übung. Ich weiß nicht, Gerrit, sag mir mal, wie spät es ist, wir. Haben eine Stunde aufgenommen. Wir haben jetzt echt schon eine Stunde aufgenommen, da müssen wir zum Ende kommen.

Aber ich will noch eine wichtige Sache sagen, die ist noch wichtig, denn dieses Quad, was ich erzählt hatte, und ich glaube, da haben wir vielleicht ein aha Erlebnis jetzt, wie setze ich das um, wie sieht jetzt so eine API aus und wir haben jetzt, wir haben jetzt das Create, das ist ein Post. Und wir das. Das Read ist ein get Verb für http. Ja und das Update ist ein Put

und das Delete ist ein delete. So also haben wir einen Post getput delete und und die Links die jetzt und ich habe ja gesagt das sind ur Ls ja das heißt wir haben einen Post slash Lists was

macht das? Das legt eine Liste an ja also unter Post heißt ja quasi leg an Lists legst du das an und dann würdest du sowas wie ein JSON hinschicken da steckt einfach nur Name drin von der Liste weil wir legen ja noch kein Task dran, so legen wir quasi eine neue Liste machen willst mit so einem Plus aus der dings du hast noch gar nichts, du hast nur das Plus und nächste neue to do Liste an, dann schickst du einen json mit dem Titel Name, Doppelpunkt, Einkaufsliste oder

irgend sowas. Ja gegen den Endpunkt mit dem Post Request gegen Lists ja und dann hast du Get Lists, da kriegst du alle Listen, dann hast du vielleicht noch ein Get Lists mit einer id das ist immer Doppelpunkt ID sieht man manchmal, dann kannst du dir eine bestimmte Liste rausholen, der ist nicht standardmäßig in der Rest API, aber den will ich jetzt da machen weil das unser Use Case ist weil du willst ja mal erstmal eine Liste raus und über den Link codiert ist.

Dann haben wir einen Put auch Lists mit id wurde die ID mit angibst weil das Put macht quasi den Update, da kannst du quasi jetzt da würdest du jetzt sagen ich abhaken, das heißt, bei dem Put kommt auch wieder ne Daten n Payload mit dein json da steht, dann ist dann true oder false. So, und dann hast du noch delete Lists, Doppelpunkt ID und damit kannst du die ganze Liste löschen. Das sind jetzt 44 API calls.

Damit hast du deine Listenanagement fertig und dann machst du noch 4 die da die genauso aussehen, die heißen halt nur Lists, Slash ID, slash Tasks und dann ist es quasi das gleiche noch mal. Dann sagst du du liegst nur quasi mit dem ersten Teil der L fest. Mit welcher Liste du sprechen willst und dann managst du die Tasks genauso mit dem Quad Gramm durch und dann bist du fertig.

Also wir brauchen hier unsere Rest API hat hier im einfachsten Falle 4 oder 8 oder 9. Einträge und diese Einträge, die suchen dann in der Datenbank quasi das entsprechende Json

raus. Also wenn du sagst zum Beispiel Get, dann passiert die Anfrage gegen die Rest API, die sucht es in Datenbank raus, gibt dir diese json zurück und dann kannst du rendern und im Frontend brauchst du nur ein Patch dafür eine einzige Funktion reicht, die haben das heute alles glatt gezogen mit fedge fragst du alle API Calls ab, da kannst du fedgepost fedge und so weiter du kannst alles durchmachen, dann kommt einfach zurück, dass json und dann hast

du es direkt als Objekt in der Hand, in den Ecken kannst direkt hin rendern. Nicht verstanden. Was mache ich mit dem Fedch, warum sollte ich das verwenden?

Das Fett, du musst ja quasi die API, liegt ja auf dem Backend und spricht mit der Datenbank über das ORM und jetzt musst du ja vom Klienten aus diese Datenbank aufrufen, du musst den HTTP request machen, dagegen nehme ich einen mit Post, get delete oder irgendwas und das Fedge ist einfach eine Funktion, die ist quasi schon fest im Browser integriert, das hat mit React nichts zu tun, du kannst sagen Window Patch, also dieses globale Window Objekt das überall da wo du javascript im

Browser sprechen kannst sozusagen fetschen das Fetch heißt hole mir unter dieser URL sprich diese API an ist total easy, ist eine Funktion machst du alles fertig mit der Hochoptimiert weil wenn du es als Pwa machst. Das gehört natürlich auch, das heißt es ist irgendwo. Programmiert in dem Frontend Code. Da steht dann fett und damit du die App hier einfach ansprechen. Ich habe nur die Ach so. Ja, genau. Worüber ich gerade sprechen? Ja, ja ne, wir waren.

Ich war schnell ins Frontend gerutscht und war dabei, wie jetzt quasi das Frontend. Also das wird ja geladen und wie das Frontend quasi die Informationen kriegt, was das Frontend als allererstes macht ist es geht halt auch. Dann würdest du den den den die die ID deiner Liste extrahieren aus der URL und damit darfst du dann Fetch ja fetch und dann get Lists mit dieser ID und dann kriegst du n json Objekt zurück.

Wo drin steht Name der Liste? Und hier sind deine Tasks als Array und da kannst du schon anzeigen, ist fertig.

Ja OK verstanden, gut, das ist ja n Teil der Technologie, die da einfach gewählt wurde, ja. Fälsch ist Teil der Technologie, Patches quasi gehört quasi zur Rest API und ist quasi eingebaut und nicht hat nichts mit React und View und so weiter zu tun, ist halt quasi dann total easy, so dass dann quasi zu lösen, so würde man dann halt das quasi von der Architektur her bauen und man würde sich halt auch für dieses Patch entscheiden, weil

das Fedge, das muss man jetzt auch wissen, warum macht man das dann so, weil wenn du zum Beispiel im Offline Modus sein möchtest oder so, wenn wir es als Pwa machen, dann ist dieses Feature quasi im Hintergrund gecached und was weiß ich nicht alles. Das ist halt so ein Klassiker.

Das ist wirklich eine Entscheidung, die man doch trifft beim Coden dann oder vorher, also ist es Teil der Architektur, das habe ich immer noch nicht ganz geraftet ich würde sagen, es ist Teil der Architektur, weil weil man sich vorher überlegt, wenn ich das so mache, dass ich eine Rest IP hone habe, und wenn ich diese, wenn ich diese Rest api so aufsetze, dann kann ich halt mit einem Patch arbeiten in einem Frontend und dieses Patch ist halt quasi.

Auch wird halt quasi auch für PWR supported, wenn ich das irgendwie anders machen würde. Wenn ich jetzt zum Beispiel nicht auf Rest API gesetzt hätte von der Architektur, sondern ich hätte jetzt irgendwie aus dem Graph QL gemacht oder ich hätte

irgendwie NRPC System genommen, da ist hier nichts mehr mit Fett und so weiter und sofort, ja dann wird es halt alles viel komplizierter. Oder anders, ich sag mal nicht komplizierter, aber es wird halt irgendwie anders, oder deswegen bedingt sich das alles so n bisschen. Das sind alles schon Entscheidungen, die miteinander zu tun. Cool, das ist zweimal Richtung Ende. Ich bin jetzt fertig, ich wollte Gas gegeben, jetzt hab ich dich abgehängt.

Leider war ich dann irgendwie auch scheiße gesprungen und ich wollte hier fertig werden, aber genau ja. So sieht ne so wäre also wenn man jetzt die Architektur machen würde find ich also da würd ich jetzt aufhören mit der Architektur. Jetzt würd ich sagen OK haben wir alles besprochen, jetzt könnt ihr hinprogrammieren so. Das ganz schön umfangreich, aber gut. Am Ende machst du dir ne Stunde oder 2 Gedanken und dann bist du in der Umsetzung nachher um ein Vielfaches schneller denk ich

mal. Ne ganz genau, ist klarer was man macht. Jetzt, ich wollte dich schon noch mal n bisschen so was fragen wie ja was, was kann man falsch machen oder auf dem Weg dahin ne aber das das klingt für mich fast schon so als wenn ich mir da nicht vorher ganz klar drüber bin was ich eigentlich will erreichen will und welche Technologien mir welche vor und Nachteile bieten. Ja inklusive dem vor und Nachteil, dass ich sie entweder

kann oder noch nicht kann. Ja dann bin ich hinten raus eben entsprechend schneller oder langsamer. Ich erzähle eine Anekdote aus unserem Leben, was man falsch machen kann. Ich hab zum Beispiel kein Geheimnis immer noch so, ich hab diese Entscheidung auch treffen

müssen für Teile unserer. Backend persistenz sag ich mal vom App Builder, wo ich auch gesagt hab, nee das hat kein relationalen Aspekt, das knallen wir halt irgendwie als Files direkt irgendwie auf die Platte und hab mir quasi ne Bibliothek geholt die ich dachte die das kann oder nicht genau geguckt und bin in ein tiefes Loch gefallen weil das nämlich das asynchrone, also das gleichzeitige Schreiben und so weiter nicht sauber getrennt hat und das sind wilde Sachen

passiert, wenn auf einmal viele Nutzer das benutzt hatten sind quasi Daten korrumpiert wurden die eigentlich auf der Platte sauber geschrieben hätten sein sollen. Ja, und das ist halt ne Katastrophe. Ja und jetzt hast du aber das ist dann architektonische Entscheidung, ich ganz am Anfang getroffen hab ja jetzt werden die feiert werden halt auf die Platte gelegt und das Ding funktioniert auf einmal nicht, ja. So ne Entscheidung rückst du halt nicht mal eben gerade.

Du machst, da ziehst du eben nicht mal kurz ne Datenbank ein und machst dann irgendwie alles anders, weil dann bei dieser Entscheidung, dass das Ding auf dem auf der Platte liegt, die hat halt für dieses Ganze für den Backend Business Code ne riesen Bedeutung. Ja entweder liest das dann irgendwie aus dem Ordner irgendwie Files raus oder du hast da ne Datenbankverbindung mit dem OM drin und so weiter das ist der Unterschied wie Tag und Nacht, das machst du halt

nicht in 2 Tagen so und dann bist du halt und das kann dann das kann dann schon eine architektonische Fehlentscheidung gewesen sein, weil ich nicht genau weil ich hier nicht genau geguckt habe kann, ist das quasi einer Datenbank äquivalent dieses Tool was du rausgesucht habe und wird es das Abkönnen unter Last unter Skalierung? Sauber irgendwie diese Files abzulegen.

Nein, konnte es halt nicht. Ja, so kann man sich ja kurz ärgern, warum die das nicht hinprügeln konnten so, aber das ist das ist nicht deren Fehler der Open Source Autoren, sondern mein Fehler, weil weil es da bestimmt irgendwie stand. Ja und was habe ich gemacht, ich habe das quasi selber noch mal hingeschrieben, war für mich weniger Aufwand jetzt, aber deswegen habe ich auch so gehabt.

Was ich empfehlen sollte ja, es gibt natürlich jetzt, jetzt gibt es eine Bibliothek Heisenberg, Slash Storage Open Source MIT die, das kann gut ja mit so Files ablegen und rausholen. Und auch also synchron und schnell und so. Aber und ohne Korruption. Mit vielen Tests hat mich aber ne Woche Schmerzen gekostet und Lebenszeit gekostet, weil das passiert natürlich. Sowas ist natürlich immer

maximal blöd, wenn das passiert. Weil du hast ja Kundenprojekte und so weiter du hast nicht Zeit, eigentlich ne Woche irgendwie im Uhrschleim, in dem in den in den untersten, das ist ja ne alles klar und das sind halt da sind halt wenn du ne gute Architektur gemacht hast. Das hab ich an der Stelle dann nicht, ja. Passiert dir sowas nicht und es solltet ihr auch besser nicht passieren, so das ist wichtig,

aber es kann halt schief gehen. Hast du die falsche Wahl getroffen und irgendwas zum Beispiel entspricht den Anforderungen. Ich würd zu langsam auf Dauer, dann hast du n riesenproblem, weil du dann ganze Komponenten

tauschen musst. Und das ist immer größerer Aufwand, ja. Gut, da hast du dann als das ist vielleicht auch wenn man jetzt wieder sich in den Auftraggeber hineinversetzt, echt schwierig, weil man ja da aber vielleicht ne to do App jetzt übergeben bekommt und die funktioniert jetzt super für mich oder für 2 Personen vielleicht für 3 oder 4 oder was und irgendwann. Wieder an die Grenze und dann stehe ich eigentlich wieder bei dir auf der Matte und sage so,

jetzt bitte umbauen. Ja jetzt jetzt bräuchte brauche ich andere Sachen. Also ich würde mir vorher schon ein bisschen Gedanken machen darüber, was später damit noch passieren wird. Ja Möglichkeit. Ja, es gibt halt immer Möglichkeiten innerhalb einer, ob einer Architektur quasi noch zu optimieren und Performance rauszuholen. Manchmal ist aber die Performance einfach ein Ende gesetzt gegeben dem was du da so tust. Wir müssen zum Ende kommen.

Ja, ich habe hinter mir. Ich war mal ne lange Folge. Ich hoffe ihr seid noch dabei geblieben. Ich fand es ziemlich cool und beeindruckend immer wieder irgendwie Burkhardt, wie umfangreich du, der ja Gedanken machst und nun als Architekt Vorgehst, aber gleichzeitig als sehr desimplementiert irgendwie, das ist ja. Häufig dann auch noch mal getrennt.

Eigentlich ne in der Realität, oder wie ist das ja eigentlich schon, aber ich sag immer der also auch in der richtigen Architektur, ich sag mal der richtige Architekt der was vom eigentlichen Handwerk versteht. Der ist vielleicht auch dem dem theoretischen Architekten überlegen, glaube ich. Ja, weil ich, ich glaube, das ist heute noch viel wichtiger als früher. Weil das hatten wir jetzt auch gesehen, in dieser Folge ne viele technologische Auswahlen.

Ich treffe so Frameworks und so weiter, die haben Halt unglaublichen Einfluss auf diese Architektur, das heißt, ich kenn mich schon, also ich sollte mich als als Software Architekt schon ziemlich genau auskennen mit den jeweiligen. Programmiersprache und da drin den jeweiligen modernen Tools sonst. Habe ich echt schwierige Aufgabe, glaube ich. Ja, ich glaube, es ist ganz gesund, wenn man so ein bisschen an der Entwicklungswelt mit dran

bleibt. Ja super prima, dann jetzt wirklich Deckel drauf und danke fürs zuhören euch ja mal gucken wer noch hier gerade noch zuhört kann ja auch Stopp drücken, zwischendurch mal kurz vor. Dem ja, und jetzt, wo wir uns alle 2 Wochen noch gibt, vielleicht. Kann man mal eine längere Folge verdauen? Genau die konnte ich jetzt nicht kürzer machen, aber ich hatte Gerrit das schon angekündigt, ich habe ihn schon gewarnt, dass das lange. Dauert guter Content, darf auch

länger sein, finde ich prima. Also dann bis nächste Woche übernächste Woche. Vielleicht mit Gästen haben wir ja schon mal gesagt und haltet die Ohren steif bis bald. Tschüss aus Hamburg. Einfach komplex wird produziert und präsentiert von Heisenware. Weitere Informationen findest du unterheisenware.com. Vielen Dank fürs Hören dieser Folge und bis nächste Woche Tschüss aus Hamburg.