React v19 - Axios

React v19+ — Axios

0:00 Fast jede Anwendung, die Sie heute bauen, redet mit einem Server. Und erstaunlich oft ist genau diese Stelle die unordentlichste im ganzen Projekt: Hier ein Fetch-Aufruf in der Komponente, dort ein handgeschriebener Header, an dritter Stelle noch eine eigene Fehlerbehandlung. Das funktioniert — bis sich die Basis-URL ändert oder ein Token ablaufen kann.

0:20 Axios ist der Versuch, diese Streuung einzusammeln: ein Client, eine Konfiguration, ein Ort für Auth, Fehler und Abbruch. Heute bauen wir diesen Ort Schritt für Schritt auf, vom ersten Aufruf bis zum abgesicherten und getesteten Client.

HTTP mit Axios in React

0:34 Der Bogen des Tages ist bewusst einfach gespannt: Wir starten beim ersten GET gegen eine öffentliche Schnittstelle und enden bei einem API-Client, den man guten Gewissens ausliefern kann. Dazwischen liegen die Themen, die im Alltag den Unterschied machen — Instanzen und Interceptors, ordentliche Fehlerbehandlung, das Abbrechen veralteter Anfragen und das Zusammenspiel mit dem State Management.

0:56 Sie werden merken: Die eigentliche Arbeit steckt selten im Absenden einer Anfrage, sondern in allem, was drumherum passiert. Bevor wir einsteigen, würde ich gern wissen, wo Sie stehen. Die drei Fragen zielen auf denselben Punkt: Vieles von dem, was Axios mitbringt, hat fast jedes Team schon einmal selbst gebaut — eine kleine Wrapper-Funktion um Fetch, ein Stück Logik, das den Token anhängt, vielleicht sogar ein eigener Abbruchmechanismus.

1:21 Wenn Sie das kennen, werden Sie heute vor allem wiedererkennen und aufräumen. Wenn Sie bislang nur mit Fetch gearbeitet haben, sehen Sie, welche dieser Dinge Sie ab sofort nicht mehr selbst schreiben müssen. Und sagen Sie ruhig, was heute konkret sitzen soll.

Grundlagen & Einordnung

1:36 Beginnen wir mit der Frage, die am Anfang jeder Werkzeugentscheidung steht: Brauchen wir das überhaupt? Fetch ist schließlich im Browser eingebaut, kostet nichts und ist überall verfügbar. Schauen wir uns deshalb zuerst an, was Axios darüber hinaus anbietet — und ab welchem Punkt sich die zusätzliche Abhängigkeit wirklich rechnet.

1:54 Diese Frage stellt sich bei jeder Abhängigkeit neu — und sie ehrlich zu beantworten, ist Teil guter Arbeit. Stellen Sie sich Fetch wie einen Rohbau vor: tragfähig, aber unverputzt. Sie bekommen eine Antwort, müssen sie aber selbst auspacken, selbst prüfen und selbst mit einer Zeitbegrenzung versehen. Axios liefert denselben Rohbau bereits ausgebaut.

2:15 Es basiert ebenfalls auf Promises, packt die Antwort aber automatisch aus, bringt Zeitüberschreitungen mit und kennt Interceptors — also Stellen, an denen Sie sich systematisch in jeden Aufruf einklinken können. Dazu kommt etwas, das oft unterschätzt wird: Derselbe Code läuft im Browser und in Node. Für ein Projekt mit Server-Anteil ist das ein handfester Vorteil.

2:37 Der Nutzen lässt sich gut an einer einfachen Rechnung ablesen. Jeder einzelne Punkt hier — Antwort auspacken, Token anhängen, Zeitlimit setzen — ist für sich genommen eine Kleinigkeit von drei Zeilen. Multipliziert mit fünfzig Aufrufen im Projekt und geteilt durch fünf Entwickler, die es jeweils leicht anders lösen, wird daraus eine Fehlerquelle.

2:57 Genau das ist der eigentliche Gewinn: nicht die gesparten Zeilen, sondern die Einheitlichkeit. Der Fortschrittsbalken beim Hochladen ist der Bonus obendrauf — mit Fetch allein ist er überraschend mühsam zu bauen. Der Einstieg ist bewusst schmal gehalten, mit einer Ausnahme. Nach der Installation steht ausdrücklich ein Blick auf die Version — und das ist keine Formalie.

3:19 Axios ist so weit verbreitet, dass es ein lohnendes Ziel für Angriffe ist; ältere Stände tragen bekannte Sicherheitslücken mit sich. Diese Prüfung kostet Sie einen einzigen Befehl und gehört ab heute zur Routine. Danach binden wir den Client ins Projekt ein, setzen einen ersten Aufruf ab und geben der Antwort einen Typ. Genau in dieser Reihenfolge — erst laufen lassen, dann typisieren.

3:42 Worauf es hier ankommt, sind zwei Details. Erstens: Sie sagen dem Aufruf über den Typparameter, was Sie erwarten — und bekommen ab da im Editor eine echte Führung durch die Daten. Zweitens, und das ist die häufigste Umgewöhnung: Was Sie zurückbekommen, ist nicht der Datensatz, sondern ein Umschlag. Der enthält die Daten, aber eben auch den Statuscode, die Kopfzeilen und die verwendete Konfiguration.

4:06 Das Auspacken hat Ihnen Axios abgenommen; den Umschlag müssen Sie trotzdem öffnen. Wer aus der Fetch-Welt kommt, greift hier anfangs zuverlässig eine Ebene daneben. Jetzt sind Sie dran. Es geht nicht um Schönheit, sondern um den ersten vollständigen Weg: eine öffentliche Schnittstelle abfragen und die Antwort typisiert im Bild anzeigen.

4:26 Erfolgreich sind Sie, wenn echte Daten auf dem Schirm stehen und Ihr Editor Ihnen die Felder vorschlägt, ohne dass Sie irgendwo von Hand ausgepackt haben. Und nutzen Sie die Zusatzaufgabe ruhig: einmal nachzusehen, welche Axios-Version bei Ihnen liegt und ob sie auf einer Schwachstellenliste steht, ist genau die Handbewegung, die später im Projekt Ärger erspart.

4:46 Diese vier Punkte begegnen einem in echten Projekten immer wieder, und drei davon haben dieselbe Wurzel: alte Gewohnheiten. Man greift auf die Antwort statt auf die Daten darin, oder man packt aus, was längst ausgepackt ist. Das legt sich nach zwei Tagen. Der erste und der letzte Punkt sind ernster. Eine veraltete Version ist ein Sicherheitsproblem, kein Stilproblem. Und ein Aufruf ohne Zeitlimit wartet im Zweifel ewig — der Nutzer sieht dann einen Ladebalken, der nie endet.

5:15 Beides sind Einstellungen, die Sie einmal setzen und danach vergessen können.

Requests & Responses im Detail

5:20 Nachdem der erste Aufruf steht, lohnt sich ein genauerer Blick auf das Handwerkszeug: Welche Methoden gibt es, wo genau gehören die Daten hin, und was steckt eigentlich alles in der Antwort? Diese Details klingen trocken, sind aber die Stelle, an der die meiste Zeit mit Suchen verloren geht. Nehmen Sie sich diese Folien als Nachschlagewerk mit; vieles davon schlägt man später genau einmal nach und weiß es dann.

5:43 Die Struktur ist angenehm gleichförmig: Für jedes HTTP-Verb gibt es eine Methode, und jede nimmt am Ende ein Konfigurationsobjekt entgegen. Denken Sie an ein Paketformular — die Adresse ist Pflicht, alles Weitere sind Felder, die Sie ausfüllen können, aber nicht müssen. Zurück kommt wieder der bekannte Umschlag mit Daten, Status, Kopfzeilen und der verwendeten Konfiguration.

6:05 Bemerkenswert ist, was Sie verschicken dürfen: klassisches JSON genauso wie Formulardaten für einen Dateiupload. Der Client kümmert sich darum, dass die passende Inhaltsangabe mitgeht. Der Wert dieser Gleichförmigkeit zeigt sich, wenn ein Projekt wächst. Sie müssen sich für einen Löschaufruf nichts Neues merken, und Sie finden alle relevanten Informationen zur Antwort an einem Ort statt verteilt.

6:28 Zwei Punkte verdienen besondere Aufmerksamkeit. Die Kodierung von Suchparametern klingt nach Kleinkram, entscheidet aber darüber, ob ein Name mit Umlaut oder ein Pluszeichen korrekt beim Server ankommt. Und der Fortschritt beim Hochladen ist das, was aus einer scheinbar eingefrorenen Oberfläche eine erklärbare Wartezeit macht — ein kleiner technischer Haken mit großer Wirkung auf das Empfinden der Nutzer.

6:51 Der rote Faden hier lautet: alles über die Konfiguration, nichts von Hand. Sie wählen die Methode passend zur Absicht, geben Suchparameter als Objekt weiter statt sie an die Adresse zu kleben, und überlassen die Kodierung dem Client. Bei Sonderfällen — geschachtelte Werte, Listen — schalten Sie einen eigenen Serialisierer davor.

7:09 Beim Verschicken entscheiden Sie zwischen JSON und Formulardaten, und beim Empfangen sagen Sie, was Sie erwarten. Der letzte Punkt wird gern vergessen: Wer eine PDF-Datei abholt und nichts angibt, bekommt sie als Text — und damit unbrauchbar. Hier sehen Sie die einzige Stelle, an der die sonst so gleichförmige Signatur kurz stolpern lässt. Bei einem schreibenden Aufruf gibt es drei Positionen: wohin, was, und wie.

7:34 In der Mitte stehen die Nutzdaten, ganz hinten die Konfiguration. Vertauscht man beide — und das passiert häufiger, als man denkt — schickt man versehentlich seine Einstellungen als Datensatz an den Server. Der antwortet dann mit einer Fehlermeldung, die auf alles Mögliche hindeutet, nur nicht auf die wahre Ursache. Merken Sie sich einfach: Die Konfiguration ist immer der letzte Parameter. Bei lesenden Aufrufen rutscht sie deshalb an Position zwei.

8:01 In dieser Übung verbinden Sie das Gelernte zu einer echten Komponente. Sie holen Daten, zeigen sie an und reagieren auf den Statuscode — also darauf, ob der Server zufrieden war oder nicht. Achten Sie besonders auf die Suchparameter: Geben Sie sie als Objekt weiter und prüfen Sie im Netzwerk-Werkzeug des Browsers, wie die fertige Adresse aussieht.

8:21 Wenn Sie Zeit haben, hängen Sie einen Upload mit Fortschrittsanzeige an. Das ist der Moment, in dem aus einer technischen Übung etwas wird, das Ihre Nutzer tatsächlich bemerken würden. Die ersten beiden Punkte kennen Sie schon von der letzten Folie — sie sind so häufig, dass sie die Wiederholung verdienen. Der dritte ist der teuerste: Wer beim Herunterladen einer Datei nicht sagt, dass Binärdaten kommen, bekommt eine beschädigte Datei ohne jede Fehlermeldung.

8:48 Sie sucht man erfahrungsgemäß lange. Der letzte Punkt ist eine angenehme Überraschung: Kopfzeilen unterscheiden nicht zwischen Groß- und Kleinschreibung. Sie müssen also nicht raten, ob der Server die eine oder die andere Variante schreibt — beide finden ihr Ziel.

Instanzen, Konfiguration & Interceptors

9:03 Jetzt kommen wir zu dem Teil, der aus einer Sammlung von Aufrufen einen richtigen API-Client macht. Bisher haben wir jeden Aufruf einzeln vollständig beschrieben. Ab hier bündeln wir alles Wiederkehrende an einer Stelle — und klinken uns mit Interceptors gezielt in jeden Aufruf ein. Ab hier verlassen wir das Einsteigergebiet — was jetzt kommt, unterscheidet ein gewachsenes Projekt von einem Prototyp.

9:27 Eine Instanz ist im Grunde ein vorkonfigurierter Briefkopf. Basis-Adresse, Zeitlimit, Standard-Kopfzeilen — einmal festgelegt, gelten sie für alles, was über diesen Client läuft. Die Interceptors sind das eigentlich Spannende: Denken Sie an die Poststelle einer Firma. Jeder ausgehende Brief bekommt dort automatisch den Firmenstempel, jeder eingehende wird sortiert, bevor er auf den Schreibtisch kommt.

9:51 Genauso hängt ein Interceptor vor dem Versand den Zugangs-Token an und prüft nach dem Empfang, ob etwas schiefging. Ihre Komponenten bleiben von alldem unbehelligt — und genau das ist der Punkt. Der größte Gewinn steht in der zweiten Zeile: ein eigener Bereich für alles, was mit der Schnittstelle zu tun hat, statt Aufrufen mitten in der Anzeige-Logik.

10:12 Warum das so wichtig ist, merkt man beim ersten Umzug. Ändert sich die Basis-Adresse, ändern Sie eine Zeile statt vierzig. Kommt eine neue Authentifizierung, passen Sie einen Interceptor an statt jeder Komponente. Und die zentrale Fehlerbehandlung sorgt dafür, dass Ihre Oberfläche überall dieselbe Sprache spricht — nicht hier eine rohe Servermeldung und dort ein freundlicher Hinweis.

10:35 Die ersten drei Schritte sind Routine, die letzten beiden sind der schwierige Teil — und dafür sollten wir uns Zeit nehmen. Wenn ein Token abläuft, antwortet der Server mit einem Ablehnungscode. Der Interceptor fängt das ab, holt einen neuen Token und wiederholt den Aufruf. So weit, so gut. Kritisch wird es, wenn Ihre Seite gerade fünf Anfragen gleichzeitig laufen hat: Dann laufen fünf Erneuerungen parallel los und behindern sich gegenseitig.

11:00 Deshalb der letzte Schritt — die wartenden Anfragen einreihen, eine Erneuerung durchführen, danach alle gemeinsam weiterlaufen lassen. Zwei Zeilen, die viel Handarbeit ersetzen. Wichtig ist das Muster dahinter: Der Interceptor bekommt die fertige Konfiguration, verändert sie — und gibt sie zurück. Dieses Zurückgeben ist der klassische Anfängerfehler. Wer es vergisst, schickt nichts mehr ab, und der Fehler ist von außen kaum zu sehen; die Anfrage verschwindet einfach.

11:28 Beachten Sie außerdem, dass der Token hier bei jedem Aufruf frisch geholt wird, statt beim Anlegen des Clients einmal eingefroren zu werden. Nur so kommt nach einer Anmeldung auch wirklich der neue Token zum Einsatz. Diese Übung ist das Herzstück des Kapitels. Sie bauen einen eigenen Client mit Basis-Adresse und automatischem Anmelde-Header.

11:48 Der Prüfstein ist angenehm konkret: Öffnen Sie das Netzwerk-Werkzeug und sehen Sie nach, ob wirklich jeder Aufruf den Token trägt, ohne dass Sie ihn irgendwo von Hand gesetzt haben. Wer schneller ist, wagt sich an die Erneuerung samt Warteschlange. Das ist erfahrungsgemäß der anspruchsvollste Teil des ganzen Tages — und gleichzeitig der, den Sie in fast jedem echten Projekt brauchen werden.

12:11 Der erste Punkt ist der grundsätzliche: Sobald Aufrufe in Komponenten wandern, ist die Bündelung wieder dahin. Der zweite ist der Anfragensturm aus dem Vorgehen, gegen den nur die Warteschlange hilft. Der dritte ist das vergessene Zurückgeben aus dem Code — er kostet garantiert einmal eine halbe Stunde Fehlersuche. Und der vierte ist subtil: Wer die mitgelieferte Standard-Instanz verwendet statt der eigenen, verändert eine global geteilte Konfiguration.

12:37 In einem größeren Projekt heißt das, dass eine Bibliothek plötzlich Ihre Kopfzeilen mitschickt. Immer die eigene Instanz nutzen.

Fehlerbehandlung & Abbruch

12:45 Bis hierhin ist alles gutgegangen. Im Alltag geht aber ständig etwas schief: Das Netz ist weg, der Server antwortet mit einem Fehler, oder der Nutzer tippt schneller, als die Antworten zurückkommen. Wie man darauf sauber reagiert, ist das Thema dieses Kapitels — und es ist das, was gute von mittelmäßigen Anwendungen unterscheidet.

13:04 Rechnen Sie in diesem Kapitel mit ein paar Aha- Momenten: Manches, was wie ein rätselhafter Fehler aussieht, hat hier seine Erklärung. Der entscheidende Gedanke ist, dass "Fehler" drei ganz verschiedene Dinge sein können. Erstens: Der Server hat geantwortet, aber ablehnend — das ist der beste Fall, denn Sie wissen genau, was er will.

13:24 Zweitens: Sie haben gefragt, aber niemand hat geantwortet — Netzausfall oder Server nicht erreichbar. Drittens: Es ging schon beim Absenden schief, meist ein Fehler im eigenen Code. Diese drei Fälle verlangen völlig unterschiedliche Reaktionen. Der Type Guard hilft Ihnen dabei, sie überhaupt sauber auseinanderzuhalten. Der AbortController löst ein anderes Problem: Er sagt einer laufenden Anfrage, dass ihre Antwort nicht mehr gebraucht wird.

13:52 Warum lohnt sich der Aufwand? Wegen der Nutzer. Ein "Bitte prüfen Sie Ihre Internetverbindung" ist hilfreich, ein "Fehler 500" nicht — aber unterscheiden können Sie die Fälle nur, wenn Sie sie technisch trennen. Der dritte Punkt ist sogar noch wichtiger, weil sein Ausbleiben zu Fehlern führt, die niemand meldet. Wenn beim schnellen Tippen eine ältere Antwort nach der neueren eintrifft, sieht der Nutzer Suchergebnisse zum falschen Suchbegriff.

14:18 Er wird das nicht als Programmfehler melden, sondern die Software für unzuverlässig halten. Genau solche Dinge kosten Vertrauen. Die ersten beiden Schritte machen aus dem unbestimmten Fehlerobjekt eine verlässliche Auskunft: erst prüfen, dass es sich um einen Axios-Fehler handelt, dann die Fälle trennen. Die Schritte drei und vier gehören untrennbar zusammen — ein Abbruchsignal anhängen und beim Aufräumen tatsächlich abbrechen. Das eine ohne das andere bringt nichts.

14:44 Der optionale Wiederholungsversuch mit wachsenden Wartezeiten ist eine schöne Ergänzung für wacklige Verbindungen, aber mit Bedacht einzusetzen: Was der Server schon einmal fachlich abgelehnt hat, lehnt er auch beim vierten Versuch ab. Dieses Muster sollten Sie im Schlaf beherrschen, denn es taucht überall auf. Der Ablauf ist: Bei jedem neuen Suchbegriff startet der Effekt, legt eine Abbruch-Steuerung an und hängt deren Signal an die Anfrage.

15:10 Der entscheidende Teil ist die Rückgabe am Ende — React ruft sie auf, bevor der Effekt erneut läuft oder die Komponente verschwindet. Genau dort brechen wir die alte Anfrage ab. Das Ergebnis: Egal wie schnell jemand tippt, es kann immer nur die Antwort zum aktuellen Suchbegriff im Zustand landen. Alle überholten Anfragen sind da längst gestoppt.

15:30 Hier bauen Sie genau das Szenario nach, das wir eben besprochen haben — eine Suche, die auf Tastatureingaben reagiert und veraltete Anfragen verwirft. Kombiniert mit einer kurzen Verzögerung vor dem Absenden entsteht daraus ein Verhalten, das Nutzer als selbstverständlich empfinden, das aber ohne diese beiden Bausteine überraschend selten funktioniert.

15:49 Testen Sie bewusst gemein: Tippen Sie sehr schnell und schauen Sie, ob am Ende die passenden Ergebnisse stehen bleiben. Als Ergänzung dann noch der Wiederholungsversuch mit wachsenden Wartezeiten für echte Netzaussetzer. Der letzte Punkt ist der raffinierteste und deshalb eine Erwähnung wert. Wenn Sie eine Anfrage absichtlich abbrechen, meldet der Client das als Fehler — technisch korrekt, aber es war ja Ihre eigene Entscheidung.

16:14 Wer das nicht abfängt, zeigt dem Nutzer bei jedem Tastendruck kurz eine rote Fehlermeldung. Das wirkt kaputt, obwohl alles genau wie geplant läuft. Prüfen Sie deshalb immer, ob der Fehler ein Abbruch war, und ignorieren Sie ihn dann bewusst. Die drei anderen Punkte fassen zusammen, was passiert, wenn man dieses Kapitel überspringt.

Axios + React State Management

16:34 Jetzt wird es Zeit für eine ehrliche Einordnung. Alles, was wir bisher gebaut haben, funktioniert — führt aber in jeder Komponente zu denselben drei Zuständen: lädt gerade, ist fehlgeschlagen, hat Daten. Schauen wir uns an, wie man diese Wiederholung loswird und welche Rolle Axios dann noch spielt. Und wir klären eine Frage, die viele Teams zu spät stellen: Wo genau gehören Serverdaten eigentlich hin?

16:58 Hier ist eine Einsicht, die vielen Projekten Jahre gekostet hat: Daten vom Server sind kein normaler Zustand. Sie gehören Ihnen nicht — sie liegen woanders, können sich dort ändern und veralten in Ihrer Anwendung schleichend. Der Versuch, sie wie lokale Werte zu behandeln, führt zwangsläufig zu immer denselben Fragen: Wann neu laden? Wie zwischenspeichern? Was tun bei paralleler Anzeige?

17:22 TanStack Query beantwortet diese Fragen einmal für alle. Axios verliert dabei nicht an Wert, sondern bekommt eine klarere Rolle: Es holt die Daten, mehr nicht. Und macht das gut. Die ersten beiden Punkte sind die Arbeitsteilung, die letzten beiden die Absicherung — und die verdient einen Moment. Ein Typparameter ist eine Behauptung über die Daten, keine Prüfung.

17:44 Sagt Ihr Code "hier kommen Nutzer" und der Server liefert etwas anderes, merkt das niemand, bis die Oberfläche bricht. Zod schließt diese Lücke, indem es zur Laufzeit tatsächlich nachschaut. Der richtige Ort dafür ist die Grenze — dort, wo fremde Daten in Ihr System kommen. Danach dürfen Sie sich auf Ihre Typen verlassen, weil sie einmal wirklich überprüft wurden.

18:07 Bemerkenswert an dieser Reihenfolge ist, wie wenig sich für Axios ändert: Der Aufruf, den Sie schon geschrieben haben, wandert unverändert in eine Funktion. Alles Weitere kommt obendrauf. Schritt drei ist die Laufzeitprüfung von eben, Schritt vier regelt das Schreiben — und das Wichtige daran ist die Ungültigkeitserklärung danach: Wer etwas ändert, muss sagen, welche zwischengespeicherten Daten dadurch veraltet sind.

18:30 Der letzte Schritt geht noch weiter und zeigt die Änderung sofort an, bevor der Server bestätigt hat. Das fühlt sich schnell an, verlangt aber einen sauberen Rückweg, wenn es doch schiefgeht. Hier sehen Sie die drei Schichten in ihrer natürlichen Ordnung. Der Schlüssel ganz oben ist die Adresse im Zwischenspeicher — daran erkennt Query, ob es diese Daten schon hat und welche später ungültig werden müssen.

18:53 In der Mitte holt Axios die Daten, genau wie zuvor. Und darunter passiert das Entscheidende: Die Antwort geht nicht direkt weiter, sondern erst durch die Prüfung. Passt sie nicht, bricht es hier ab — an der Grenze, mit einer klaren Meldung. Nicht irgendwo tief in der Oberfläche, wo ein Feld unerwartet leer ist. Diese Übung führt alles zusammen: Lesen, Anlegen, Ändern, Löschen — mit Zwischenspeicher, mit Typen und mit Laufzeitprüfung.

19:19 Der schönste Moment kommt, wenn Sie nach dem Anlegen eines Eintrags die Liste für ungültig erklären und zusehen, wie sie sich von selbst aktualisiert. Kein manuelles Nachladen, kein händisches Einfügen in den Zustand. Wer die Zusatzaufgabe angeht, zeigt die Änderung schon vor der Serverantwort an — und lernt dabei, warum ein sauberer Rückweg bei Fehlern dazugehört.

19:41 Der letzte Punkt fasst das Missverständnis zusammen, das am häufigsten vorkommt: Man setzt Typparameter, ist zufrieden und hält die Daten für abgesichert. Das sind sie nicht — der Typ verschwindet beim Übersetzen, geprüft hat niemand etwas. Typen und Laufzeitprüfung sind zwei verschiedene Sicherheitsnetze, und nur zusammen tragen sie.

20:00 Die vergessene Ungültigkeitserklärung im dritten Punkt ist der Klassiker mit dem typischen Symptom: Der Nutzer legt etwas an, sieht es nicht, legt es nochmal an — und nach dem Neuladen stehen zwei Einträge da.

Sicherheit, Testing & Produktionsreife

20:12 Bleibt die Frage, was zwischen "läuft bei mir" und "kann raus" liegt. Drei Dinge: die Sicherheit der Abhängigkeiten, der Schutz vor fremden Anfragen — und Tests, die verlässlich sind, weil sie kein echtes Netz brauchen. Diese drei Punkte werden gern auf später verschoben — und sind genau die, die man am Tag der Auslieferung nicht mehr nachholen kann.

20:33 Hinter dem etwas sperrigen Begriff Lieferketten-Sicherheit steckt eine unbequeme Wahrheit: Sie führen fremden Code aus. Ihre Abhängigkeiten haben wiederum eigene Abhängigkeiten, und irgendwo in dieser Kette kann ein kompromittiertes Paket landen. Ein Lockfile ist dagegen die einfachste Versicherung — es hält exakt fest, welche Stände einmal geprüft wurden.

20:54 Der zweite Punkt ist ebenso schlicht: Alles, was im Browser läuft, kann gelesen werden. Es gibt kein geheimes Frontend. Und der dritte betrifft Tests, die auf Netzwerkebene ansetzen: Statt Ihren Code auszutricksen, antwortet ein abgefangener Server — Ihre Anwendung merkt keinen Unterschied. Die Testfrage verdient eine Einordnung, weil hier oft der falsche Weg eingeschlagen wird.

21:17 Wer den HTTP-Client selbst durch eine Attrappe ersetzt, testet am Ende vor allem seine Attrappe. Setzt man dagegen auf Netzwerkebene an, läuft Ihr echter Client mit echten Interceptors — nur die Gegenstelle ist gestellt. Solche Tests halten auch, wenn Sie später den Client wechseln. Der letzte Punkt ist ein leicht übersehener Gewinn: Drei unabhängige Abfragen nacheinander dauern dreimal so lang wie nötig.

21:41 Gebündelt kosten sie so viel wie die langsamste — bei gleichem Aufwand im Code. Diese fünf Schritte sind eine gute Abschlussliste vor dem Ausliefern. Wichtig ist, dass die ersten drei nichts sind, was man einmal macht und abhakt. Eine Version, die heute sauber ist, kann nächste Woche eine gemeldete Lücke haben — deshalb gehört die Prüfung in die Bauleitung, nicht in den Kalender.

22:03 Der CSRF-Schutz in Schritt zwei betrifft alle, die mit Sitzungs-Cookies arbeiten: Ohne ihn kann eine fremde Seite im Namen Ihres angemeldeten Nutzers Anfragen auslösen. Zwei Konfigurationszeilen schließen diese Tür. Das ist eine kleine Konfiguration mit großer Wirkung, und sie zeigt noch einmal, warum sich die Instanz aus Kapitel drei gelohnt hat.

22:25 Vier Zeilen an einer Stelle — und jeder Aufruf im gesamten Projekt bekommt ein Zeitlimit und den CSRF-Schutz. Zum Zeitlimit eine praktische Anmerkung: Zehn Sekunden sind ein brauchbarer Ausgangswert, aber kein Naturgesetz. Ein Dateiupload braucht mehr, eine Vorschlagsliste beim Tippen deutlich weniger. Setzen Sie den allgemeinen Wert konservativ und weichen Sie bei einzelnen Aufrufen bewusst davon ab.

22:49 Zum Abschluss bringen Sie Ihren Client in einen Zustand, in dem Sie ihn guten Gewissens übergeben würden: mit Schutz vor fremden Anfragen, mit Zeitlimit, und mit Tests, die ohne Internetverbindung laufen. Der letzte Punkt ist mehr wert, als er klingt — Tests, die vom Netz abhängen, schlagen irgendwann grundlos fehl, und nichts untergräbt das Vertrauen in eine Testsuite schneller.

23:09 Die Zusatzaufgabe mit der automatischen Aktualisierung ist der Schritt von der einmaligen Prüfung zur dauerhaften Gewohnheit. Diese vier Punkte sind die Zusammenfassung dessen, was in echten Projekten tatsächlich schiefgeht. Der zweite verdient eine Warnung: Ein Zugangsschlüssel im Frontend-Code ist auch dann öffentlich, wenn er in einer Umgebungsvariablen steht — beim Bauen wandert er einfach mit ins ausgelieferte Paket.

23:33 Wenn Sie einen Dienst ansprechen müssen, der einen geheimen Schlüssel verlangt, gehört dazwischen ein eigener Server. Es gibt keinen Trick, der das umgeht, und jeder vermeintliche kostet Sie irgendwann die Rechnung eines Fremden. Schauen wir zurück auf den Weg des Tages. Wir haben mit der Frage begonnen, ob sich ein eigener HTTP-Client überhaupt lohnt, und die Antwort steckt in diesen vier Zeilen: nicht wegen einzelner Bequemlichkeiten, sondern weil alles Wiederkehrende an einen Ort wandert.

24:00 Ein Client mit Interceptors, ein sauberer Umgang mit Fehlern und Abbrüchen, eine klare Rolle im Zusammenspiel mit dem State Management, und eine Version, der Sie vertrauen können. Was Sie mitnehmen, ist weniger eine Bibliothek als eine Ordnung für die Stelle, an der Ihre Anwendung mit der Außenwelt spricht.

Fragen & Weiterarbeiten

24:17 Alle Beispiele und Übungslösungen finden Sie in der Freigabe — nehmen Sie sich besonders den Client mit Interceptor als Vorlage mit, das ist der Teil, den Sie morgen im eigenen Projekt brauchen. Für alles Weitere ist die offizielle Dokumentation überraschend gut lesbar; der Migrationsleitfaden lohnt sich, wenn Sie einen älteren Stand aktualisieren.

24:37 Und wenn im eigenen Code eine Frage auftaucht, die wir heute nicht beantwortet haben: Schreiben Sie uns. Vielen Dank für Ihre Aufmerksamkeit.