Zum Hauptinhalt springen

External-Service-Labor

SvelteKit ruft einen separat betriebenen Rust-Dienst über einen typisierten, authentifizierten serverseitigen Client auf — Live-Status, echte Latenz, Vertragsvalidierung und ehrliche Fehlerbehandlung.

Diese Seite spricht nie selbst mit dem Dienst. Jede Schaltfläche sendet an SvelteKit, dessen Server den runtime-lab-Dienst aufruft — einen eigenen Rust-Prozess in einem eigenen Container — mit einem Zugangsschlüssel, den der Browser nie sieht. Jeder Wert unten wird bei diesem Aufruf gemessen.

browser → +page.server.ts → client.ts → runtime-lab (Rust, eigener Container)

Ziele

Ein Ziel ist ein Ort, an dem der Dienst läuft — serverseitig konfiguriert und hier nur per Name gewählt, nie per URL. Aufgerufen wird erst, wenn du auf Prüfen drückst.

Lokaler Container

Nicht konfiguriert

Der Dienst in einem eigenen Podman-Container neben dem Dev-Server.

Entfernter Host

Konfiguriert

Dasselbe Image bei einem kostenlosen Hoster, erreichbar über HTTPS. Kostenlose Hosts schlafen bei Leerlauf; der erste Aufruf kann etwa eine Minute dauern.

Auswerten

Sende eine vordefinierte Bestellung an die Regel-Engine. Die Seite sendet nur den Namen der Vorgabe; den Request-Body bestimmt der Server. Eine Ablehnung ist die Antwort der Engine, kein Fehler.

Fehlerübungen

Das Zeitbudget der Anfrage ist bereits aufgebraucht. Der Client beginnt keine Arbeit, die er nicht beenden kann — nichts wird gesendet.

Sendet einen gültig geformten, aber falschen Bearer-Schlüssel. Der Dienst selbst lehnt ihn mit 401 ab.

Sendet eine Bestellung außerhalb der Grenzen an den Prüfungen des Clients vorbei. Der Dienst validiert erneut und antwortet mit 400.

Diese Sitzung

Aufrufe aus diesem Browser-Tab, neueste zuerst. Für jeden Aufruf auf dem Server gemessen; nichts wird gespeichert, nichts geschätzt. Zeiten in Millisekunden; ein Strich bedeutet: nicht beobachtet.

Noch keine Aufrufe.

Die Grenze

  • Ein Vertrag: Die Rust-Typen erzeugen openapi.json, daraus entstehen die TypeScript-Typen, gegen die der Service-Client validiert. Eine Änderung auf einer Seite lässt einen Test scheitern, bevor sie eine Anfrage scheitern lässt.
  • Der Dienst prüft seinen Bearer-Schlüssel selbst und startet ohne ihn gar nicht. Der Schlüssel liegt in rein serverseitiger Konfiguration und erreicht nie diese Seite, eine Logzeile oder eine Fehlermeldung.
  • Ziele sind serverseitig festgelegt; diese Seite benennt sie nur und kann nirgendwohin zeigen. Es gibt keinen Proxy und kein CORS — der Browser spricht nie mit dem Dienst.
  • Jeder Aufruf hat eine Frist und eine begrenzte Antwort und endet in genau einem Ergebnis. Nur idempotente Aufrufe werden wiederholt — einmal und nur, wenn keine Antwort ankam.
  • Der Dienst ist optional: Nur diese Seite hängt von ihm ab. Stoppe ihn, und diese Seite meldet ihn als nicht erreichbar, während der Rest der Website weiterläuft.
  • Dasselbe Container-Image läuft lokal unter Podman und bei einem kostenlosen Hoster — nur Port und Zugangsschlüssel ändern sich.

Geht dieses Pattern noch besser? Sag uns, wie.

Feedback geben