Schemas mit Pydantic v2

Schemas mit Pydantic v2

0:00 Fast jede Python-Anwendung, die Daten entgegennimmt, beginnt gleich: Man schreibt ein paar Modelle, die beschreiben, wie ein Datensatz aussieht. Das funktioniert am ersten Tag hervorragend. Schwierig wird es später — wenn ein Feld umbenannt werden soll und plötzlich fremde Clients kaputtgehen. Oder wenn dieselbe Rechenformel an vier Stellen im Code steht und an dreien davon inzwischen anders.

0:22 In diesem Modul geht es deshalb nicht um Pydantic als Werkzeug zum Einlesen von Daten. Es geht um Pydantic als die Stelle, an der ein Dienst festlegt, was er nach außen zusagt und was er intern für gültig hält. Zwei Aufgaben, die beide ins Schema gehören.

Die Anwendung — Rampenlicht Dispo

0:37 Bevor wir über Verträge und Regeln reden, brauchen wir etwas zum Anfassen. Architekturentscheidungen lassen sich schlecht im Leeren diskutieren — sie ergeben erst Sinn, wenn man den Fall kennt, an dem sie sich bewähren müssen. Wir schauen uns deshalb zuerst die Anwendung an, die uns durch alle sechs Module begleitet. Und vor allem die Stellen, an denen sie heute noch weh tut, denn die sind der eigentliche Lehrplan dieses Seminars.

1:02 Stellen Sie sich einen Verleih für Veranstaltungstechnik vor. Rampenlicht vermietet Scheinwerfer, Mischpulte und Bühnenelemente aus drei Niederlassungen. Wer ein Sommerfest plant, bekommt ein Mietangebot: eine Liste von Geräten mit Menge und Tagessatz, ein Zeitraum, ein Rabatt. Der Vertrieb schreibt diese Angebote, die Disposition gibt sie frei. Das ist ein überschaubares Geschäft, und genau deshalb eignet es sich so gut.

1:26 Alles, was wir in diesem Seminar an Architektur besprechen, hat hier eine handfeste Entsprechung — von der Frage, ob ein Rabatt zu hoch ist, bis zu der Frage, was passiert, wenn vier Prüfungen gleichzeitig laufen. Die Aufteilung ist bewusst konventionell — ein Einstiegspunkt, ein Modul für die Schemas, ein Paket für die Endpunkte, dazu ein Speicher.

1:47 Interessant ist weniger, was dasteht, als was fehlt: eine Datenbank. Die Angebote leben zunächst in einem einfachen Dictionary im Arbeitsspeicher. Das ist keine Nachlässigkeit, sondern Absicht. Solange kein Datenbankzugriff dazwischenkommt, lässt sich sauber zeigen, was allein die Schemas leisten. Im zweiten Modul tauschen wir das Dictionary gegen echte Persistenz — und Sie werden sehen, wie wenig sich an den Schemas dadurch ändern muss.

2:13 Das ist bereits ein Ergebnis der Trennung, über die wir gleich sprechen. Vier Punkte, und alle vier haben denselben Kern: Wissen liegt an der falschen Stelle. Die Schemas kennen die Form der Daten, aber keine einzige Regel — dass eine Menge positiv sein muss, weiß niemand. Die Feldnamen aus Python fallen ungefiltert nach außen, jede interne Umbenennung wird damit zum Bruch für alle Aufrufer.

2:37 Und die Summenformel steht dort, wo sie gebraucht wird, also mehrfach. Das ist der Zustand, in dem sehr viele Dienste jahrelang laufen. Er ist nicht falsch, er skaliert nur nicht mit dem Geschäft. Genau deshalb fangen wir hier an und nicht bei der Datenbank. Diese erste Aufgabe verlangt noch keine Zeile Code. Starten Sie die Anwendung und öffnen Sie die automatisch erzeugte Dokumentation.

3:00 FastAPI zeigt Ihnen dort schwarz auf weiß, was der Dienst zusagt: welche Endpunkte es gibt, welche Felder sie erwarten, welche Typen. Und dann suchen Sie gezielt nach dem, was dort nicht steht. Nehmen Sie sich drei Felder vor und formulieren Sie zu jedem eine Regel, die eigentlich gelten müsste, die aber heute niemand durchsetzt.

3:19 Der Blick lohnt sich, weil er den Rest des Moduls trägt — wir schließen genau diese Lücken, eine nach der anderen.

Pydantic als Vertrag und Regelwerk

3:26 Wir haben gesehen, wo es hakt. Jetzt schauen wir uns an, wie Pydantic dieses Problem einrahmt. Die meisten begegnen der Bibliothek als etwas, das Anfragedaten einliest und Typen prüft — das ist richtig und deutlich zu wenig. Wir sortieren deshalb erst einmal, welche zwei Aufgaben ein Schema eigentlich hat, und schauen danach, was die zweite Hauptversion mitbringt, um beide zu erfüllen.

3:50 Ein Schema hat zwei Aufgaben, und sie werden gern verwechselt. Die erste ist der Vertrag: Was schickt die Außenwelt, was bekommt sie zurück. Der muss stabil bleiben, denn fremde Systeme verlassen sich darauf. Die zweite ist die Integrität: Was macht ein Angebot überhaupt gültig. Ein Mietende vor dem Mietbeginn ist typmäßig völlig in Ordnung — beides sind Datumswerte — und fachlich trotzdem Unsinn.

4:14 Denken Sie an einen Türsteher, der zwei Dinge gleichzeitig macht: Er prüft die Eintrittskarte, und er prüft, ob Sie überhaupt hineindürfen. Beides gehört an die Tür, nicht in den Saal. Der auffälligste Unterschied zu Version 1 liegt unter der Haube: Der Kern von Pydantic ist in Rust geschrieben. Validierung und JSON-Serialisierung laufen also als kompilierter Code, nicht als interpretiertes Python.

4:39 Für einen Dienst, durch dessen Schemas jede einzelne Anfrage und jede einzelne Antwort läuft, ist das kein Detail. Aber der eigentliche Gewinn ist ein anderer: Version 2 gibt uns zwei Methoden an die Hand, die überall gelten — nicht nur im HTTP-Body. Damit lässt sich dasselbe Regelwerk auch auf Daten anwenden, die über ganz andere Wege hereinkommen. Darauf kommen wir im letzten Kapitel zurück.

5:03 Wenn Sie aus Version 1 kommen, ist diese Übersicht Ihre Landkarte. Wichtiger als die einzelnen Namen ist das Muster dahinter: Version 2 hat die Methoden konsequent mit einem Präfix versehen. Das wirkt umständlich, hat aber einen guten Grund — es macht Schluss mit Namenskollisionen zwischen Pydantic-Methoden und Ihren eigenen Feldern.

5:22 Ein Feld namens json war früher ein Problem, heute nicht mehr. Einige der alten Namen funktionieren noch, aber verlassen Sie sich nicht darauf. In neuem Code haben sie nichts zu suchen, und die Validatoren haben sich ohnehin so verändert, dass altes Wissen nicht eins zu eins trägt. Der erste Punkt ist der, der am häufigsten spät auffällt.

5:42 Wenn Sie ein Modell in ein Dictionary verwandeln, bekommen Sie standardmäßig echte Python-Objekte zurück — ein Datum bleibt ein Datumsobjekt. Das sieht im Debugger völlig in Ordnung aus. Erst wenn dieses Dictionary irgendwo als JSON verschickt werden soll, knallt es, und zwar meist an einer Stelle weit weg von der Ursache.

6:01 Der zweite Punkt ist grundsätzlicher: Pydantic prüft Typen. Dass ein Rabatt von zweihundert Prozent eine gültige Fließkommazahl ist, hält es nicht auf. Für diesen Sprung von der Form zur Fachlichkeit brauchen wir Validatoren.

Verschachtelte Angebote und Aliase

6:15 Fangen wir mit der ersten der beiden Aufgaben an: dem Vertrag nach außen. Die Frage dahinter beschäftigt jedes Team früher oder später — wie hält man eine Schnittstelle stabil, ohne sich intern für immer die Hände zu binden? Denn beides will man ja: außen Verlässlichkeit für die Aufrufer, innen die Freiheit, Dinge umzubenennen, wenn man es besser weiß.

6:35 Aliase sind die Antwort darauf, und sie sind erstaunlich unspektakulär. Ein Alias ist im Grunde ein Künstlername. Intern heißt das Feld so, wie es sich in Python gut anfühlt — mit Unterstrichen, klein geschrieben. Nach außen trägt es einen anderen Namen, den die Clients kennen. Der Nutzen zeigt sich erst, wenn etwas umbenannt werden soll: Sie ändern den internen Namen, der Künstlername bleibt, und niemand draußen merkt etwas.

7:00 Ohne diese Trennung ist jede Aufräumaktion im Code eine Änderung an einer öffentlichen Schnittstelle. Und das ist der Grund, warum solche Aufräumaktionen in vielen Projekten nie stattfinden — sie sind schlicht zu teuer geworden. Sie sehen hier eine Konvention, keine technische Notwendigkeit: innen Unterstriche, außen die zusammengeschriebene Variante mit Großbuchstaben in der Mitte.

7:23 Python schreibt sich so, JavaScript schreibt sich so — und der Alias ist genau die Naht dazwischen. Beachten Sie vor allem die letzte Zeile der Fußnote: Dieselben Aliase müssen auch auf dem Lesemodell stehen. Passiert das nicht, nimmt die Anfrage den einen Namen entgegen und die Antwort schickt den anderen zurück. Der Dienst spricht dann zwei Verträge gleichzeitig, und das ist schlimmer, als hätte er nie einen gehabt.

7:46 Worauf es hier ankommt, sind zwei Zeilen. Die eine hängt dem Feld den Künstlernamen an. Die andere, die Konfigurationszeile, erlaubt, dass Daten auch unter dem internen Namen hereinkommen dürfen. Warum braucht man das? Weil Ihr eigener Code die Modelle ja ebenfalls baut — Testdaten, Startbestände, interne Aufrufe. Ohne diese Erlaubnis müssten die alle plötzlich den Künstlernamen benutzen, und Sie hätten sich die Umbenennung, die Sie gerade vermeiden wollten, durch die Hintertür wieder eingehandelt.

8:16 Merken Sie sich also: Der Alias öffnet die Tür nach außen, diese Konfiguration hält sie nach innen offen. Der rote Faden dieser fünf Schritte ist einfach: erst erlauben, dann benennen, dann spiegeln, dann nachweisen. Die ersten beiden Schritte sind Handwerk. Der vierte ist der, den man gern vergisst — das Lesemodell muss dieselben Aliase tragen wie das Schreibmodell.

8:38 Und der fünfte ist der, der Sicherheit gibt: Schicken Sie einmal Daten unter dem Künstlernamen und einmal unter dem internen Namen. Kommen beide durch, stimmt die Konfiguration. Antworten müssen Sie übrigens nicht gesondert prüfen — FastAPI serialisiert von sich aus über den Alias, und genau das ist auch der nächste Stolperstein.

8:58 Der erste Punkt ist frisch und wichtig: Die ältere Konfigurationsoption, die Sie in fast jedem Tutorial im Netz finden, ist überholt. Sie wird in der nächsten Hauptversion verschwinden. Schreiben Sie also nicht ab, was Sie gestern gelesen haben. Der dritte Punkt ist der subtilste: Dass Antworten unter dem Alias hinausgehen, ist eine Leistung von FastAPI — nicht von Pydantic.

9:20 Sobald Sie ein Modell selbst in ein Dictionary verwandeln, etwa um es in eine Warteschlange zu legen, müssen Sie den Alias ausdrücklich anfordern. Zwei verschiedene Schichten, dieselbe Wirkung — und deshalb eine Verwechslung, die still passiert. Diese Aufgabe ist die Probe aufs Exempel. Suchen Sie sich ein Feld und benennen Sie es intern um — richtig um, nicht nur ein bisschen.

9:43 Danach muss dreierlei gelten: Die Antwort des Dienstes sieht unverändert aus. Eine Anfrage mit dem alten JSON-Namen wird weiter angenommen. Und Ihr interner Code, der Testbestand zum Beispiel, funktioniert mit dem neuen Namen. Wenn alle drei Punkte stimmen, haben Sie die Trennung verstanden. Wenn einer davon bricht, zeigt Ihnen genau dieser Bruch, welche der beiden Konfigurationsseiten Sie noch nicht gesetzt haben.

Berechnete Felder für Summen und Marken

10:08 Der Vertrag steht. Kommen wir zu dem Ärgernis, das wir eingangs gesehen haben: der Summenformel, die an vier Stellen im Code lebt und an dreien davon inzwischen anders aussieht. Solche Duplikate entstehen nie mit Absicht. Sie entstehen, weil ein neuer Endpunkt schnell fertig werden musste und die Rechnung eben schon woanders stand.

10:26 Wir ziehen sie jetzt an die einzige Stelle, an der sie eigentlich hingehört — ins Modell selbst. Ein berechnetes Feld ist ein Wert, der nicht gespeichert, sondern hergeleitet wird. Es steht im Modell, es taucht in der Antwort auf, aber niemand kann es hineinschicken. Dieser letzte Punkt ist der entscheidende. Denken Sie an den Kassenbon im Supermarkt: Die Summe steht darauf, aber Sie können sie nicht selbst eintragen.

10:52 Sie ergibt sich aus dem, was im Wagen liegt. Genauso hier — der Gesamtbetrag eines Angebots ist keine Angabe des Aufrufers, sondern eine Folge der Positionen. Ein Client, der ihn trotzdem mitschickt, wird schlicht ignoriert. Das Muster hier ist eine ganz normale Python-Property, die zusätzlich als Feld markiert wird. Wichtig ist die Reihenfolge der beiden Markierungen — sie stehen übereinander, und andersherum greift die Sache nicht.

11:18 Das ist einer dieser Fehler, die keine hilfreiche Meldung erzeugen; das Feld fehlt einfach in der Antwort, und man sucht eine Weile. Der eigentliche Gewinn zeigt sich aber erst auf der nächsten Folie: Diese Felder können aufeinander aufbauen. Der Gesamtbetrag greift auf die Zwischensumme zu, die Großauftragsmarke auf den Gesamtbetrag. So entsteht eine Kette statt vier unabhängiger Kopien derselben Rechnung.

11:42 Lesen Sie diese Tabelle von oben nach unten, dann sehen Sie die Kette: Jede Zeile benutzt das Ergebnis der Zeile darüber. Das ist mehr als Bequemlichkeit. Angenommen, das Geschäft entscheidet, dass Rabatte künftig nur noch auf einen Teil der Positionen gelten. Dann ändert sich genau eine Zeile — und alle darüber liegenden Werte stimmen automatisch weiter.

12:02 Hätten Sie die Formel an vier Stellen im Code stehen, müssten Sie vier Stellen finden. Die vierte finden Sie erfahrungsgemäß erst, wenn sich ein Kunde über eine falsche Rechnung beschwert. Der letzte der vier Punkte klingt technisch, ist aber der, der im Alltag zählt: Die berechneten Werte gehen unter ihrem Künstlernamen hinaus, genau wie alle anderen Felder.

12:23 Der Vertrag nach außen bleibt also aus einem Guss — der Client sieht nicht, welches Feld gespeichert und welches hergeleitet ist, und das muss er auch nicht. Für ihn ist ein Angebot ein Angebot. Diese Geschlossenheit ist der Grund, warum es sich lohnt, die Herleitung ins Modell zu ziehen und nicht in den Endpunkt. Der Endpunkt sollte transportieren, nicht rechnen.

12:45 Hier geht es um eine fachliche Kennzahl, nicht um eine technische. Ab einem bestimmten Betrag gilt ein Angebot als Großauftrag, und daran hängen später andere Regeln — etwa ein höherer Rabattdeckel. Bauen Sie diese Marke als abgeleitetes Feld. Und machen Sie danach die Gegenprobe, die den eigentlichen Punkt zeigt: Schicken Sie ein Angebot, bei dem der Client die Marke selbst mitsetzt, und zwar falsch.

13:08 Wenn Ihr Modell richtig gebaut ist, ändert das genau nichts. Die Marke ergibt sich aus dem Betrag, nicht aus dem Zuruf.

Fachregeln zentral mit Validatoren

13:16 Bisher ging es um Form und um abgeleitete Werte. Jetzt kommt der Teil, der aus einem Schema erst ein Regelwerk macht: die Frage, was ein Angebot überhaupt gültig sein lässt. Das ist der Sprung von der Technik zur Fachlichkeit. Ein Datum ist ein Datum, da gibt es nichts zu prüfen — aber ob dieses Datum an dieser Stelle Sinn ergibt, weiß nur Ihr Geschäft.

13:37 Und genau dieses Wissen ziehen wir jetzt neben die Daten. Es gibt zwei Sorten von Regeln, und sie brauchen zwei verschiedene Werkzeuge. Die erste Sorte betrifft ein einzelnes Feld: Eine Menge muss größer als null sein, ein Text darf nicht leer sein. Solche Regeln lassen sich mit dem Typ verheiraten und dann überall wiederverwenden — Sie definieren einmal, was eine positive Menge ist, und benutzen das an fünf Stellen.

14:02 Die zweite Sorte spannt sich über mehrere Felder: Das Mietende darf nicht vor dem Mietbeginn liegen. Diese Regel kann erst greifen, wenn das ganze Modell steht — beide Werte müssen ja vorliegen. Der Schlüssel steht in der Markierung über der Methode: Sie sagt, dass diese Prüfung nach dem Bauen des Modells laufen soll. Vorher wäre sie sinnlos, weil die Felder noch gar nicht alle gesetzt sind.

14:25 Und dann ist da noch die letzte Zeile, die harmlos aussieht und es nicht ist: Die Methode gibt das Modell zurück. Vergisst man das, gibt sie nichts zurück — und Pydantic nimmt dieses Nichts als Ergebnis. Das Modell ist danach leer. Kein Fehler, keine Meldung, nur ein Objekt ohne Inhalt. Ein Klassiker, über den fast jeder einmal stolpert.

14:46 Das Prinzip hinter dieser Tabelle ist Wiederverwendung statt Wiederholung. Sie definieren einmal, was in Ihrem Projekt ein nicht leerer Text ist — einschließlich der Frage, ob Leerzeichen am Rand vorher abgeschnitten werden. Danach schreiben Sie an jedem Feld nur noch diesen Namen hin. Der Gewinn zeigt sich, wenn die Regel sich ändert.

15:05 Soll ein Text künftig mindestens drei Zeichen haben statt einem, ändern Sie eine Zeile, und alle Felder ziehen mit. Nebenbei liest sich das Modell dadurch besser: Da steht nicht mehr, dass ein Feld ein Text ist, sondern was für ein Text es ist. Diese fünf Schritte führen zu einer Regel, die man gern unterschätzt. Der erlaubte Rabatt hängt nämlich von der Größe des Auftrags ab — auf einen Großauftrag darf mehr gewährt werden als auf ein kleines Angebot.

15:32 Damit ist es per Definition eine feldübergreifende Regel: Sie braucht den Gesamtbetrag, und der ergibt sich erst aus allen Positionen. Genau deshalb kann sie nicht am einzelnen Feld hängen. Achten Sie auf den letzten Schritt: Sie werfen einen ganz normalen Wertefehler. FastAPI übersetzt den von sich aus in eine Antwort mit dem Code 422 — Sie müssen dafür nichts weiter tun.

15:55 Der letzte Punkt weist schon auf das nächste Kapitel voraus, und er ist der wichtigste von allen. Solange Ihre Regeln im Endpunkt stehen, gelten sie genau dort. Kommt dasselbe Angebot über einen anderen Weg herein — aus einem Partnersystem, aus einer Warteschlange —, läuft es an all diesen Prüfungen vorbei. Das ist kein hypothetisches Szenario, das ist der Normalfall in gewachsenen Systemen.

16:17 Und es ist der eigentliche Grund, warum wir die Regeln so hartnäckig ins Schema ziehen: Nicht wegen der Eleganz, sondern weil das Schema jede Tür bewacht und der Endpunkt nur eine. Zwei Testfälle machen diese Aufgabe aus, und sie unterscheiden sich nur in der Größe des Angebots. Dreißig Prozent auf einen Großauftrag müssen durchgehen.

16:37 Dieselben dreißig Prozent auf ein kleines Angebot müssen abgelehnt werden — mit einer Meldung, aus der hervorgeht, warum. Achten Sie auf diesen zweiten Teil. Eine Fehlermeldung, die nur sagt, dass etwas ungültig ist, hilft dem Aufrufer nicht weiter. Sie soll den Deckel nennen, der gilt. Fehlermeldungen sind ein Teil Ihrer Schnittstelle, auch wenn sie selten so behandelt werden.

Validieren an allen Grenzen

17:00 Zum Abschluss die Frage, die den ganzen Aufwand dieses Moduls erst rechtfertigt: Was passiert eigentlich mit Daten, die niemals durch einen HTTP-Endpunkt kommen? Denn wenn unsere schönen Regeln nur für den einen Weg gelten, über den zufällig ein Browser spricht, haben wir wenig gewonnen. In gewachsenen Systemen ist HTTP oft nicht einmal der Hauptweg. Schauen wir uns also an, wie dasselbe Regelwerk auch alle anderen Türen bewacht.

17:25 In jedem realen System gibt es mehr als eine Tür. Ein Partnerbetrieb liefert nachts eine Datei mit Angeboten. Eine Warteschlange bringt Nachrichten aus einem anderen Dienst. Ein Webhook meldet eine Änderung. In allen drei Fällen landet bei Ihnen ein rohes Dictionary — kein HTTP-Body, kein FastAPI, kein deklariertes Anfragemodell.

17:47 Und trotzdem sollen dieselben Regeln gelten. Genau dafür gibt es die Methode, mit der man ein Modell aus beliebigen Daten baut. Sie wendet alles an: die Aliase, die eingeschränkten Typen, die feldübergreifenden Validatoren. Ohne Ausnahme. Zwei kleine Funktionen, und sie stehen für die beiden Richtungen. Die eine nimmt ein rohes Dictionary entgegen und macht daraus ein geprüftes Modell.

18:11 Die andere geht den Weg zurück und macht aus einem Modell ein Dictionary, das nach außen verschickt werden kann. Bei der Rückrichtung sind zwei Angaben wichtig: die eine sorgt für die Künstlernamen, die andere dafür, dass die Werte JSON-tauglich sind — ein Datum wird dabei zur Zeichenkette. Was hier entsteht, ist im Grunde eine Schleuse. Alles, was hinein oder hinaus will, geht durch dieselbe Prüfung, egal auf welchem Weg es gekommen ist.

18:37 Das ist der Ertrag des ganzen Moduls, zusammengefasst in einem Satz: Eine neue Regel im Schema gilt sofort an allen drei Türen. Sie müssen sie nicht im Endpunkt nachziehen, nicht im Importer, nicht im Exporter. Und umgekehrt gilt: Wenn irgendwo eine Regel fehlt, dann fehlt sie überall — das ist zwar unangenehm, aber wenigstens gleichmäßig und damit auffindbar.

18:57 Verstreute Regeln haben die unangenehme Eigenschaft, an vier Stellen zu existieren und an der fünften zu fehlen, und diese fünfte ist genau die, über die die falschen Daten hereinkommen. Der erste Punkt ist eine Falle, in die man genau einmal tappt. Wenn FastAPI selbst validiert, weil Sie ein Anfragemodell deklariert haben, übersetzt es Fehler automatisch in eine saubere Antwort mit dem Code 422.

19:21 Rufen Sie die Validierung dagegen von Hand auf, ist das ein ganz normaler Programmfehler — und der Aufrufer bekommt einen internen Serverfehler zu sehen. Aus seiner Sicht ist Ihr Dienst kaputt, obwohl er selbst falsche Daten geschickt hat. Fangen Sie den Fehler also ab und antworten Sie ehrlich. Das ist eine Zeile Code und ein großer Unterschied in der Fehlersuche.

19:43 Der Kern dieser Aufgabe ist der Vergleich. Schicken Sie dasselbe fehlerhafte Angebot einmal über den normalen HTTP-Endpunkt und einmal über den neuen Importweg. Beide Male muss dieselbe Antwort herauskommen — derselbe Code, dieselbe Meldung. Wenn das gelingt, haben Sie den Kern dieses Moduls in der Hand: Validierung ist eine Eigenschaft Ihrer Modelle, nicht eine Eigenschaft Ihrer Endpunkte.

20:06 Und wenn stattdessen ein interner Serverfehler kommt, wissen Sie jetzt genau, welche Zeile fehlt.

Was jetzt trägt

20:12 Halten wir fest, was wir gewonnen haben. Der Vertrag nach außen ist stabil und von der internen Benennung entkoppelt. Summen und Kennzahlen entstehen an einer Stelle und lassen sich nicht fälschen. Die Fachregeln stehen dort, wo die Daten stehen — auch die, die mehrere Felder betreffen. Und all das gilt an jeder Tür des Dienstes.

20:31 Was bisher fehlt, ist ein Gedächtnis: Unsere Angebote leben noch in einem Dictionary im Arbeitsspeicher und sind beim nächsten Neustart weg. Im zweiten Modul geben wir ihnen ein Zuhause in einer Datenbank — asynchron und typsicher.