HTTP und typisierter Datenzugriff

HTTP und typisierter Datenzugriff

0:00 Ich fange mit einem Satz an, der TypeScript-Entwicklern manchmal weh tut: Ein Typ ist ein Versprechen des Compilers. Die Schnittstelle hat es nie gegeben. Sie schreiben hin, dass die Antwort so aussieht — und niemand prüft das zur Laufzeit. Wenn das Gegenüber ein Feld umbenennt, merkt es Ihr Compiler nicht, Ihr Build nicht und Ihre Tests meistens auch nicht.

0:20 In diesem Modul geht es darum, wie man Datenzugriff so baut, dass Abweichungen dort auffallen, wo sie entstehen.

Navigation, Daten und Formulare

0:28 Wir bleiben im dritten Tag. Die Navigation steht, jetzt geht es um das, was durch die Leitung kommt. Und um die Grenze zwischen Ihrer Anwendung und allem, was Sie nicht kontrollieren.

HttpClient und typisierte Antworten

0:39 Beginnen wir mit dem Werkzeug selbst — und mit der Frage, wo die Aufrufe eigentlich stehen sollten. Der Datenzugriff wird beim Start eingerichtet und bringt vier Dinge mit: typisierte Antworten, gebündelte Fehlerbehandlung, das Abfangen von Anfragen und Testwerkzeuge. Die letzten beiden sind die, die man beim ersten Hinschauen unterschätzt.

0:59 Wichtig ist der Ort: Die Aufrufe gehören gebündelt in einen Service je Fachbereich, nicht verteilt über Komponenten. Das klingt nach Ordnungsliebe und hat einen sehr praktischen Grund, der auf der übernächsten Folie kommt. Ein unspektakulärer Service — und in der Fußzeile steht der Satz, um den es geht: Der Typparameter beschreibt die erwartete Antwort, geprüft wird er zur Laufzeit nicht.

1:22 Worauf es hier ankommt: Dieser Service ist die einzige Stelle, die die Adressen der Schnittstelle kennt. Keine Komponente kennt sie. Ändert sich die Adresse, ändert sich eine Datei. Das ist der Unterschied zwischen einer Änderung von zehn Minuten und einer Suche über das ganze Projekt, bei der man eine Stelle übersieht. Vier Punkte, und der vierte ist der architektonisch wichtigste: Komponenten kennen das eigene Modell, nicht die Felder der Schnittstelle. Das ist genau die Grenze aus Modul acht.

1:51 Die ersten drei sind praktisch: Die Adressen stehen an einer Stelle. Eine Vertragsänderung trifft eine Datei. Und der Zugriff lässt sich als Ganzes austauschen und testen — was wir in Modul sieben vorbereitet haben. Wenn Sie so wollen, ist dieser Service der Ort, an dem die Außenwelt endet und Ihre Anwendung anfängt. Der erste Punkt ist das Gegenteil von allem eben Gesagten und trotzdem verbreitet: Jede Komponente ruft direkt auf, und die Adresse steht überall.

2:19 Der zweite ist der, der dieses Modul motiviert: Der Typ der Antwort wird geraten und nie gegengeprüft. Und der dritte ist eine Eigenheit, über die jeder Umsteiger einmal stolpert: Ein Aufruf ohne Abonnement wird nie ausgeführt. Die Anfrage geht einfach nicht raus — kein Fehler, keine Meldung, nichts. Man sucht dann im Netzwerk-Tab nach einer Anfrage, die es nie gab.

Funktionale Interceptors

2:42 Kommen wir zu den Querschnittsaufgaben — also allem, was jede Anfrage betrifft und das man nicht in jeden Aufruf schreiben möchte. Ein Interceptor ist heute eine Funktion: Sie bekommt die Anfrage und eine Weiterleitungsfunktion und gibt einen Strom von Ereignissen zurück. Registriert werden sie beim Einrichten des Datenzugriffs, und zwar in der angegebenen Reihenfolge — das ist wichtig.

3:05 Anfragen sind unveränderlich; Änderungen entstehen durch Klonen. Und es gibt einen typisierten Kontext, mit dem Sie einzelne Anfragen markieren können — etwa um für genau eine das Zwischenspeichern abzuschalten. Denken Sie an die Poststelle einer Firma: Alles, was rausgeht, bekommt denselben Stempel. Ein Beispiel, wie es in Spurweite wirklich gebraucht wird: Jede Anfrage soll wissen, von welchem Standort sie kommt. Worauf es ankommt, ist das Klonen.

3:32 Die Anfrage wird nicht verändert — sie ist unveränderlich —, sondern es entsteht eine neue mit dem zusätzlichen Kopf. Wer das übersieht und stattdessen zuweist, bekommt keinen Fehler; es passiert nur nichts. Und beachten Sie, dass hier eine Abhängigkeit bezogen wird: Auch in einer Interceptor-Funktion steht Ihnen die Dependency Injection zur Verfügung.

3:53 Der erste Punkt ist der eben genannte: verändern statt klonen, und es geschieht schlicht nichts. Der zweite ist ein Schichtverstoß, den man leicht begeht, weil der Interceptor so zentral liegt: Er trifft fachliche Entscheidungen statt technischer. Der dritte ist ein Datenschutzthema, das in Modul achtzehn wiederkommt: Ein Interceptor protokolliert Inhalte, die nicht protokolliert werden dürfen.

4:16 Und der vierte ist ein Wartungsproblem: Die Reihenfolge wird umgestellt, und plötzlich fehlt ein Kopf bei den wiederholten Anfragen.

Fehler, Wiederholung und Abbruch

4:24 Jetzt zu dem Teil, der in Demos nie vorkommt und im Betrieb den Unterschied macht: Was passiert, wenn es nicht klappt? Fehlerhafte Antworten kommen als eigener Typ zurück. Und dann beginnt die Arbeit: Netzfehler, Serverfehler und fachliche Ablehnungen brauchen verschiedene Behandlungen — das kennen wir aus Modul acht. Besonders wichtig ist die Frage der Wiederholung. Sie ist nur bei gefahrlos wiederholbaren Aufrufen zulässig. Ein zweites Anlegen eines Auftrags ist es nicht.

4:52 Und noch ein Punkt, den man gern vergisst: Laufende Anfragen sollten enden, wenn der Benutzer die Ansicht verlässt. Vier Zeilen, vier verschiedene Reaktionen — und das ist die eigentliche Aussage. Bei einer Zeitüberschreitung bieten Sie einen neuen Versuch an; das Netz in einer Werkstatthalle ist nicht immer gut, und der Benutzer weiß das.

5:13 Bei einem Serverfehler brechen Sie ab und melden, ohne technische Details. Bei einer fachlichen Ablehnung zeigen Sie am Feld an, was los ist — der Auftrag ist gesperrt, das ist keine Störung, sondern eine Information. Und bei einer abgelaufenen Sitzung führen Sie zur Anmeldung. Vier Lagen, vier Antworten, und keine davon ist „Fehler aufgetreten".

5:34 Der erste Punkt ist der teuerste, den ich kenne: Ein Schreibaufruf wird automatisch wiederholt und legt zweimal an. Bei einem Reparaturauftrag ist das ärgerlich; bei einer Bestellung wird es teuer. Der zweite ist die Sammelbox von Modul acht, hier in ihrer technischen Form: Alle Fehler werden gleich behandelt. Und der dritte ist der, den jeder Benutzer schon gesehen hat und niemand versteht: Der technische Fehlertext erscheint unverändert in der Oberfläche, samt Statuscode und Pfad.

Daten am API-Rand prüfen

6:03 Damit zum Thema, mit dem ich angefangen habe. Und zu der Stelle, an der sich entscheidet, ob ein Fehler früh oder spät auffällt. Ein Typparameter sagt dem Compiler, was Sie erwarten. Zur Laufzeit prüft ihn niemand. Kommt ein Feld nicht oder in anderer Form, fällt das erst später an unerwarteter Stelle auf — meistens im Template, meistens als leere Anzeige.

6:25 Eine Prüfung am Rand wandelt fremde Daten in Ihr eigenes Modell und weist Unerwartetes sofort ab. Stellen Sie sich eine Warenannahme vor: Die Lieferung wird beim Eingang geprüft, nicht erst in der Montage. Dort wäre nämlich unklar, ob das fehlende Teil verloren ging oder nie geliefert wurde. Vier Schritte, und der erste ist der konzeptionelle: das eigene Modell getrennt vom Antwortformat beschreiben.

6:49 Das fühlt sich zuerst nach doppelter Arbeit an — zwei Typen für dieselbe Sache. Der Gewinn zeigt sich beim ersten Mal, wenn die Schnittstelle ein Feld umbenennt und Sie genau eine Datei anfassen. Schritt drei ist der, bei dem Disziplin gefragt ist: bei Abweichung sofort und sichtbar abbrechen, nicht stillschweigend auffüllen.

7:07 Und in der Fußzeile steht ein praktischer Hinweis: Die Ressourcen-APIs nehmen eine Prüffunktion direkt entgegen — dazu kommen wir im nächsten Modul. Vier Punkte, und sie beschreiben alle dieselbe Verschiebung: Der Fehler fällt dort auf, wo er entsteht, nicht drei Ansichten weiter. Das ist der ganze Gewinn — und er ist beträchtlich, wenn man einmal einen halben Tag damit verbracht hat, eine leere Anzeige zurückzuverfolgen.

7:32 Die Anwendung arbeitet nur mit dem eigenen, vollständigen Modell. Eine Änderung der Schnittstelle wird sofort sichtbar statt schleichend. Und die Fehlersuche endet am Rand, nicht im Template. Der erste Punkt ist der, der am besten gemeint ist und am meisten schadet: Fehlende Felder werden mit Standardwerten aufgefüllt. Ein leerer String statt eines fehlenden Kennzeichens — und schon ist der Fehler unsichtbar.

7:56 Der zweite: Die Prüfung steht in der Komponente und wiederholt sich je Aufrufer, in leicht abweichender Fassung. Und der dritte ist die Ausgangslage, die wir vermeiden wollen: Das Antwortformat wird direkt als eigenes Modell verwendet. Dann ist jede Änderung am Gegenüber eine Änderung in Ihrer ganzen Anwendung.

Übung

8:14 Binden wir Spurweite an. Und zwar mit einer Schnittstelle, die absichtlich auch mal nicht funktioniert. Spurweite bekommt seine Daten aus einer vorbereiteten Schnittstelle mit Aufträgen, Fahrzeugen und Standorten. Das Besondere: Sie antwortet auf Wunsch fehlerhaft — einmal mit einem Serverfehler, einmal mit einer Antwort, in der ein Pflichtfeld fehlt.

8:35 Das sind die beiden Fälle, die im Betrieb wirklich auftreten und die in keiner Entwicklungsumgebung je vorkommen. Deshalb bauen wir sie hier bewusst nach, statt darauf zu warten. Das Lernziel bringt es auf den Punkt: HTTP so kapseln, dass Fehler- und Formatabweichungen ein festgelegtes, sichtbares Verhalten haben. Festgelegt und sichtbar — beides zählt.

8:56 Das Erfolgskriterium nennt drei Teile, und der letzte ist die Probe: Beide Fehlerfälle erzeugen je eine definierte Reaktion. Nicht dieselbe. Wer früh fertig ist, ergänzt eine Wiederholung für genau die Aufrufe, bei denen sie gefahrlos ist — und muss dafür erst einmal entscheiden, welche das sind. Fünf Schritte in aufsteigender Schwierigkeit. Bündeln und umwandeln sind mechanisch. Der Interceptor ist schnell geschrieben.

9:23 Interessant wird es ab Schritt vier: Serverfehler auslösen und die Reaktion festlegen. Achten Sie darauf, dass Sie wirklich festlegen und nicht nur beobachten — was sieht der Benutzer, und was kann er als Nächstes tun? Und Schritt fünf ist der, der die Disziplin verlangt: das fehlende Pflichtfeld am Rand abweisen, statt es aufzufüllen. Die Versuchung, einen leeren String einzusetzen, ist groß.

9:48 Der erste Punkt ist der, der die ganze Kapselung wieder aufhebt: Das Antwortformat wandert unverändert durch die ganze Anwendung. Der zweite ist der gefährliche: Die Wiederholung trifft auch den Aufruf, der einen Auftrag anlegt. Und der dritte ist typisch für Interceptors: Er setzt den Kopf, und kein Test prüft das je — bis jemand die Reihenfolge ändert.

10:08 Im nächsten Modul schauen wir uns an, wie derselbe Datenzugriff aussieht, wenn er dem Zustand folgt statt einem Aufruf.