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.