Melden Sie einen Nutzer in einer session-basierten App ab, vergisst der Server ihn bei der nächsten Anfrage. Melden Sie ihn in einer JWT-basierten App ab, bleibt das Token, das er besitzt, gültig, bis es abläuft – es sei denn, Sie haben einen zusätzlichen Mechanismus dafür gebaut. Dieser Unterschied ist die eigentliche Entscheidung hinter „JWT vs. Session". Der Rest folgt daraus. Was eine Session tatsächlich speichert Eine Session hält den Zustand des Nutzers auf dem Server und gibt dem Browser nur einen Schlüssel zum Nachschlagen. ...

Suchen Sie “Welpe” in einem System, das nur Stichwörter abgleicht, und ein Dokument über Hundetraining taucht nicht auf, obwohl jeder, der beide liest, sie als eng verwandt bezeichnen würde. Stichwortsuche vergleicht Zeichenketten. Sie weiß nicht, dass “Welpe” und “Hund” fast dasselbe bedeuten. Embeddings lösen genau das. Sie verwandeln einen Text in eine Liste von Zahlen, einen Vektor, der so platziert wird, dass Texte mit ähnlicher Bedeutung nah beieinander landen, unabhängig davon, welche Wörter verwendet werden. ...

Packen Sie einen fetch()-Aufruf in ein try/catch, rufen Sie einen Endpunkt auf, der mit 404 antwortet, und der catch-Block läuft nie. Das Promise wird aufgelöst. res.json() parst, was auch immer der Server zurückgeschickt hat, oft ein Fehler-Payload wie {"error": "user not found"}, und der Rest der Funktion behandelt es als den angeforderten Datensatz. Keine Exception, keine Konsolenwarnung. Die falschen Daten wandern weiter, bis etwas anderes daran zerbricht. 1 2 3 4 5 6 7 8 9 async function getUser(id) { try { const res = await fetch(`/api/users/${id}`); const user = await res.json(); return user; // bei einem 404 ist das { error: "user not found" } } catch (err) { console.error('Failed to load user:', err); } } Dieses catch greift nur bei einer Anfrage, die nie abgeschlossen wird. Alles andere braucht eine Prüfung, die Sie selbst schreiben müssen. ...

Eine Funktion, die sich selbst aufruft, hat eine maximale Tiefe, und die ist kleiner, als die meisten erwarten: 1.000 Aufrufe in CPython standardmäßig, etwa 10.000 bis 15.000 in Node und in Browser-Engines, je nachdem, wie viel jeder Frame belegt. Wird dieses Limit überschritten, wird das Programm nicht einfach langsamer. Es stürzt ab. Python löst RecursionError: maximum recursion depth exceeded aus; JavaScript löst RangeError: Maximum call stack size exceeded aus. Beide Fehler haben die gleiche Ursache, und wenn Sie sie einmal verstanden haben, wissen Sie, wann Rekursion das richtige Werkzeug ist und wann sie zum Risiko wird. ...

Sie bauen ein Dashboard: Header, Sidebar, Hauptbereich, Footer. Sie greifen zu Flexbox, weil das nun mal das Layout-Werkzeug ist, das Sie kennen – und zwanzig Minuten später stapeln sich drei verschachtelte display: flex-Container, die Sidebar hält ihre Breite nur mit einer willkürlichen Pixelzahl, und der Footer schwebt mitten auf der Seite, sobald der Inhalt kurz ist. Das ist kein Flexbox-Bug. Sie wenden ein eindimensionales Werkzeug auf ein zweidimensionales Problem an. ...

Stellen Sie go vor einen Funktionsaufruf, und diese Funktion läuft nebenläufig zum Rest des Programms, verwaltet von der Go-Runtime statt vom Betriebssystem. Eine zu starten ist der einfache Teil. Der schwierige Teil ist, zwei Goroutinen ein Ergebnis übergeben zu lassen, ohne dass sie sich gegenseitig den Zustand kaputt machen, und genau das ist die Aufgabe von Channels. Was ist eine Goroutine? Eine Goroutine ist eine Funktion, die unabhängig von der Funktion läuft, die sie gestartet hat, verwaltet von der Go-Runtime und nicht vom Betriebssystem. Ein OS-Thread reserviert ein Megabyte oder mehr Stack und kostet den Kernel echte Zeit für die Planung. Eine Goroutine startet mit einem Stack von etwa 2 KB, der bei Bedarf wächst, und die Runtime multiplext viele Goroutinen auf eine Handvoll OS-Threads. Tausende davon zu starten ist normal. ...

Eine Klasse, die einen Nutzer in der Datenbank speichert, ihm eine Willkommens-E-Mail schickt und eine Quittung formatiert, ist eine Änderung davon entfernt, zwei Funktionen zu zerstören, mit denen sie nichts zu tun hat. Fassen Sie das E-Mail-Template an, riskieren Sie den Schreibzugriff auf die Datenbank. Fassen Sie das Quittungslayout an, riskieren Sie die E-Mail. SOLID ist der Sammelbegriff für fünf Regeln gegen genau diese Art von Verknotung, jede aus einem anderen Blickwinkel. Sie teilen eine Idee: Eine Klasse soll nur einen Grund haben, sich zu ändern, und der Rest des Codes soll davon abhängen, was etwas zu tun verspricht, nicht davon, wie es das tut. ...

Zwei Anfragen treffen im Abstand von einer halben Millisekunde auf denselben “100€ abheben”-Endpunkt. Das Konto hat 150€. Beide Anfragen lesen diesen Kontostand, beide sehen genug Guthaben, beide werden genehmigt, beide ziehen 100€ ab. Das Konto landet bei -50€, und kein Codepfad hätte das zulassen dürfen. Das ist eine Race Condition: Das Ergebnis hängt davon ab, welche Operation zufällig zuerst fertig wird, und “zuerst” war nie eine Entscheidung, die der Code getroffen hat. ...

Ein Suchfeld, das bei jedem Tastendruck eine Anfrage auslöst, schickt für “redis” fünf Anfragen, von denen vier veraltet sind, bevor die Antwort zurückkommt. Ein scroll-Handler, der das Layout neu berechnet, läuft hunderte Mal pro Sekunde und lässt die Seite stottern. Beide Fälle haben dasselbe Problem: Das DOM-Event feuert viel öfter, als der Handler laufen muss. Debounce und Throttle lösen das auf zwei unterschiedliche Arten. Was Debounce macht und was Throttle macht Debounce wartet, bis das Event für eine festgelegte Zeit nicht mehr feuert, und läuft dann einmal. Jeder neue Aufruf setzt die Uhr zurück. Hört das Event nie auf, läuft die Funktion nie. Ein Suchfeld ist der klassische Fall: warten, bis der Nutzer beim Tippen pausiert, und dann eine Anfrage für das zuletzt Eingegebene schicken. ...

Was ein Decorator wirklich mit Ihrer Funktion macht Sie wollen jede Funktion zeitlich messen, die eine langsame externe API aufruft. Sie können time.perf_counter()-Aufrufe in jede einzelne einfügen, oder die Messung einmal schreiben und überall anwenden. Ein Decorator ist die zweite Option: eine Funktion, die eine andere Funktion nimmt, sie in zusätzliches Verhalten einwickelt und die eingewickelte Version unter dem ursprünglichen Namen zurückgibt. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import time def timed(func): def wrapper(*args, **kwargs): start = time.perf_counter() result = func(*args, **kwargs) elapsed = time.perf_counter() - start print(f"{func.__name__} took {elapsed:.3f}s") return result return wrapper @timed def fetch_price(ticker): time.sleep(0.2) # Platzhalter für einen Netzwerkaufruf return 142.50 fetch_price("AAPL") # fetch_price took 0.201s @timed über def fetch_price ist die Kurzform von fetch_price = timed(fetch_price). Python ruft timed einmal auf, direkt nachdem fetch_price definiert wurde, und bindet den Namen fetch_price neu an das, was timed zurückgibt. Das ist alles, was das @ tut. ...