#162 Event Sourcing & Märchen mit Golo Roden von the native web

Event Sourcing mit Golo Roden von the native web.

Im Engineering Kiosk Adventskalender 2024 sprechen befreundete Podcaster⋅innen und wir selbst, Andy und Wolfi, jeden Tag kurz & knackig innerhalb von wenigen Minuten über ein interessantes Tech-Thema.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Event Sourcing

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://andygrunwald.com/)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Bluesky: https://bsky.app/profile/engineeringkiosk.bsky.social
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:05 - 00:00:57)

Willkommen zu einem weiteren Türchen vom Engineering Kiosk Adventskalender. Heißt das eigentlich Advents oder Adventkalender? Vermutlich so eine österreichische Sache. Auf jeden Fall geht es heute um mein Lieblingsthema Datenhaltung bzw. Datenbanken. Aber bevor wir ganz tief in das Thema einsteigen, verrate ich ein lang gehütetes Geheimnis von mir. Und zwar warum SQL, Ÿousand und NoSQL gemeinsam einfach nicht funktionieren. Mit diesem geballten Wissen könntet ihr eigentlich jetzt schon abschalten, aber es kommt noch mehr. Und zwar in dieser Episode geht es um die Änderungen von Datensätzen und wie man diese nachvollziehbar machen kann bzw. Um das grundlegende Konzept und die Herausforderungen damit. Heute wieder einmal nicht von uns und auch nicht von einem befreundeten Podcast, sondern von einem befreundeten YouTuber. Viel Spaß mit Golo Roden.

Golo Roden (00:00:58 - 00:02:17)

Hallo und herzlich willkommen zur heutigen Folge. Mein Name ist golo Roden und ich habe heute die große Ehre, hier zu Gast sein zu dürfen. Ich erzähle dir heute ein bisschen was über Event Sourcing. Aber bevor wir jetzt einsteigen in was das ist, ist die viel wichtigere Frage erst, warum solltest du dich damit überhaupt beschäftigen? Also wofür ist das wichtig? Was hast du davon und wozu braucht man das Ÿousand? Und das interessante ist, dass ich dir das eigentlich gar nicht groß erklären muss, denn du benutzt Eventsourcing tatsächlich sogar schon jeden einzelnen Tag. Nur ist dir vielleicht nicht bewusst, dass man das Event Sourcing nennt. Tja, und wo bzw. In welchem Zusammenhang benutzt du das? Das ist ganz einfach. Du benutzt Event Sourcing immer dann, wenn du dein Girokonto benutzt. Weil jetzt müssen wir mal kurz überlegen, wie sieht denn eine normale oder sagen wir mal besser eine übliche Datenhaltung aus? Naja, normalerweise nimmt man eine Datenbank, sei es jetzt eine relationale, SQL basierte Datenbank, eine NoSQL Datenbank oder sonst irgendwas und speichert dort die Daten. Oder besser gesagt, man speichert den Status quo. Und dann immer wenn sich an diesem Status quo irgendetwas verändert, dann macht man ein Update. Und wenn man den Status quo dann irgendwann nicht mehr haben möchte, dann kann man auch ein Delete machen, um die Daten zu löschen.

Wolfi Gassler (00:02:17 - 00:02:17)

Zweitausendein.

Golo Roden (00:02:18 - 00:08:53)

Und dieses Vorgehen, das ist so normal und das wird uns Entwicklerinnen und Entwicklern so sehr quasi von klein auf eingetrichtert, so zu arbeiten, dass wir das eigentlich überhaupt nicht mehr hinterfragen, ob das ein sinnvoller Ansatz ist, ob man das anders machen könnte und so weiter. Man macht es halt einfach so. Aber so von Zeit zu Zeit merkt man, dass das vielleicht nicht immer ganz das wahre ist, dass also auch dieses Modell mit Daten zu arbeiten seine Nachteile hat. Und das merkt man meistens als erstes dann zweitausendein, wenn man Daten löschen möchte. Denn wenn sie einmal weg sind, dann sind sie halt weg. Und das will man ja oft auch einfach nicht. Und deshalb geht man dann gerne hin und das ist sicherlich was, was du schon mal gesehen hast oder was du vielleicht auch schon mal selbst umgesetzt hast. Dann geht man hin und führt ein isdeleted Feld ein und dieses ist deleted Feld. Das kann man dann per Update auf true setzen, wenn man einen Datensatz quasi löschen möchte, oder auch wieder auf false, wenn man ein undilead machen möchte. Und damit hat man eine undelete Logik geschaffen. Dann muss man halt nur bei der Anzeige der Datensätze alle Datensätze rausfiltern, bei denen dieses deleted Feld auf true steht. Und das Ganze nennt sich softdelete. Und wie gesagt, ich bin mir sicher, das hast du schon mal irgendwie gesehen, gehört, genutzt oder ähnliches. Ja, und jetzt stellt sich natürlich die warum machen wir das so? Also was ist das Problem mit delete? Und die Antwort, die ist eigentlich ganz wenn wir etwas einmal gelöscht haben, dann können wir es nicht mehr rückgängig machen. Das heißt, ein Undilead ist eben gerade nicht möglich, wenn wir es richtig gelöscht haben. Und vor allem, man weiß ja auch gar nicht mehr, dass da mal was da gewesen war vorher, denn man hat es ja jetzt gerade gelöscht. Das heißt, wenn das Löschen an sich ein geschäftsrelevanter Vorgang ist, über den man vielleicht später noch mal reden möchte, dann verliert man den gerade dabei. Insofern ist löschen in gewissem Sinne eine blöde Idee. Man könnte sagen, es ist in Anführungszeichen. Wenn man jetzt mal richtig drüber nachdenkt, dann fällt ja vielleicht auf, dass das gleiche auch für Update gilt. Auch Update ist so gesehen keine gute Idee, denn auch ein Update verliert ja Daten. Und zwar die Daten, die vorher da waren, denn die werden ja durch den neuen Wert überschrieben und der alte, der ist danach halt einfach weg. Das heißt, auch hier gilt, wenn die alten Daten in irgendeiner Form geschäftsrelevant waren, dann verliert man die. Und das ist halt tatsächlich häufig der Fall, denn historische Daten zu haben, das wäre oft extrem wertvoll. Also du willst z.B. wissen, wie dein Kontostand früher einmal war. Naja, ohne historische Daten wirst du das nicht rausfinden. Du willst wissen, wie sich dein Kontostand im Laufe der Zeit verändert hat. Ohne historische Daten wirst du auch das nicht herausfinden. Du willst vielleicht eine Zeitreihenanalyse machen? Naja, das wird schwierig ohne historische Daten. Du brauchst einen Audit Log. Auch hier, naja, ich denke, du kennst die Antwort langsam. So, und deine Bank, die hat ja genau all diese Probleme. Und wie lösen die das? Ganz einfach, die speichern nicht den Status quo, also einfach deinen Kontostand und überschreiben den jedes Mal, denn dann wäre überhaupt nicht nachvollziehbar, wie dieser Kontostand zustande gekommen ist oder wie deine Zahlungshistorie in den vergangenen x Monaten so war oder dies oder das oder jenes, sondern die Bank will das alles wissen. Und deshalb nutzt deine Bank kein CRUD, so nennt man das nämlich. CRUD ist ein Akronym und steht für create, read, update, delete. Was machen sie stattdessen? Ganz einfach, sie verzichten auf die in anführungszeichen bösen Aktionen, also Update und Delete und nutzen nur noch Create und Read. Mit einem Read macht man ja ohnehin nichts kaputt, aber die Frage ist natürlich, was man halt nur mit einem Create noch großartig anfangen kann. Und was sie hier machen, ist, dass sie nicht den Status quo speichern, sondern die Veränderungen, die zum Status quo geführt haben. Sie führen sozusagen ein Protokoll, an das ein Ende immer nur etwas angehängt werden kann. Und das nennt man dann in der Fachsprache ein Append only log. Und damit kommt Transparenz rein, man erhält eine unglaublich gute Analysier und Auswertbarkeit und so weiter. Also vom Konzept her so ein bisschen wie Git, nur halt für Daten. Und der Witz ist, dass du das natürlich nicht nur für ein Konto so machen kannst, das kannst du für alles mögliche nutzen. Wenn du einen Onlineshop betreibst, kannst du das auf deinen Warenkorb übertragen. Also welche Artikel wurden in den Warenkorb hineingelegt, welche wieder rausgenommen, wo wurde die Anzahl verändert, wann wurde bestellt und so weiter. Oder wenn du eine Maschinensteuerung baust, wann wurde welcher Schalter betätigt, wann ist die Kontrollleuchte angegangen, wann und von wem wurde die Maschine in den Wartungsmodus geschaltet und so weiter. Und der Punkt ist, wenn du alles an solchen Ereignissen sammelst, die aus Business Sicht relevant sind, dann bekommst du ganz automatisch historische Daten, ein Audit Log und eine super gute Analysierbarkeit. Und das Beste ist, du kannst dann heute fragen über deine Daten beantworten, von denen du gestern noch nicht wusstest, dass sie dir mal jemand stellen wird. Und zwar auf den Daten der Vergangenheit. Das heißt, du kannst deine Daten eben auch rückwirkend noch auswerten, weil du nicht nur den Status quo hast, sondern eben die vielen kleinen Schrittchen, die sich im Lauf der Zeit zum Status quo aufsummiert haben. Und das nennt man Event Sourcing. Das heißt, unterm Strich ist Event Sourcing erstmal einfach nur ein grundlegend anderes Konzept, um Daten zu speichern. Und einen Vorteil habe ich dir noch nicht erzählt. Dadurch, dass du bei den Events nämlich tatsächlich versuchst, sie sprechen zu machen, kommst du endlich weg von diesen rein technischen Begriffen create, update, delete. Denn wenn du einfach nur weißt, der Warenkorb wurde geupdatet, geupdatet, geupdatet und dann noch mal geupdatet, das sagt einfach nichts aus. Viel aussagekräftiger ist doch, wenn du weißt, dass Artikel x hineingelegt wurde, dann Artikel y, dann von Artikel x die Anzahl erhöht wurde und schließlich die Bestellung aufgegeben wurde. Und falls du all das nicht glaubst und denkst, naja, ist irgendwie schon mal ganz interessant zu hören, was Event Sourcing so ist, brauche ich aber glaube ich eher nicht, Quad ist für uns gut genug, dann geh doch mal hin und versuch gerade jetzt in der Weihnachtszeit eine Geschichte zu erzählen, nur mit den Verben create, update und delete. Und spätestens wenn du deinen Kindern erklären musst, warum der Wolf das Rotkäppchen im Bösen, großen, dunklen Wald updatet, indem er ihr Isdeleted Feld auf True setzt, mit der Intention, dass der Jäger später ein Undilete machen kann, dann merkst du, wie bescheuert das ist, nicht direkt zu erzählen, was eigentlich passiert ist. Und wenn das schon für Märchen nicht funktioniert, warum versuchen wir dann viel komplexere business stories mit Crud zu erzählen? Das war mein Take für heute. Ich hoffe, es hat dir gefallen und du fandest es interessant. Und wenn du mehr über Event Sourcing erfahren möchtest, dann melde dich gerne bei mir. Und jetzt wünsche ich dir aber erstmal noch eine schöne Vorweihnachtszeit. Pass gut auf dich auf, bleib gesund und dann bis zum nächsten Mal, wie und wo auch immer das sein wird. In diesem Sinne, mach's gut. Ciao.

Wolfi Gassler (00:08:54 - 00:09:32)

Danke dir, Gollo, für die Episode und das Wissen zu Event Sourcing. Und wenn du noch mehr von Golo Roden hören willst oder vor allem natürlich sehen willst, dann schau auf seinem YouTube Kanal the Native Web vorbei. Dort gibt es noch viel Developer Content. Und golo war auch zu Besuch bei uns im Podcast. Und zwar in Episode 117 haben wir über Vanilla Web gesprochen und ob es überhaupt so viele JavaScript Frameworks benötigt oder ob man immer JavaScript Frameworks einsetzen sollte. Alle links findest du dazu natürlich in den Shownotes. Und wenn dir diese Episode gefallen hat, würden wir uns auf eine Bewertung in deiner Lieblings Podcast App natürlich freuen und ich gehe jetzt Schneemann bauen. Bis morgen.