Simulationstypen
Alles in dieser Dokumentation läuft auf derselben Mock-Engine; was sich unterscheidet, ist, wo eine Simulation lebt und wer sie deployt. Es gibt vier Arten, eine zu betreiben, und sie schließen sich nicht aus: Teams entwickeln oft gegen eine gehostete Simulation, lassen eine portable Kopie in der CI laufen und halten einen Codegen-Service für eigene Logik.
App-Simulationen
Der Standard. Vollständig im Browser gebaut und konfiguriert: OpenAPI-Specs und statische Endpunkte hinzufügen, auf Deploy klicken, und die Simulation antwortet unter ihrer URL. Alles in den Abschnitten Erstellen, Konfigurieren, Replays und Beobachten dieser Doku arbeitet auf einer App-Simulation.
Wähle sie, wenn du einen gehosteten Mock willst, den dein ganzes Team erreicht, ohne Installation und mit jeder Änderung in der App.
Siehe App-Simulationen.
Simulationen aus GitHub
Dieselbe gehostete Simulation, aber das Repository ist die Quelle der Wahrheit: Specs, statische Endpunkte und Konfiguration liegen als Dateien, und ein Push deployt sie über die GitHub Action, mit einer URL pro Branch und Pull Request. Die Action liefert beide Projektformen: einen portablen Ordner, der unverändert bedient wird, oder ein Codegen-Projekt, das aus dem Quellcode gebaut wird. Die App zeigt diese Simulationen schreibgeschützt; eine zu ändern heißt, das Repo zu ändern.
Wähle sie, wenn Mocks wie Code reviewt werden sollen und jeder Branch seine eigene Umgebung braucht.
Siehe Simulationen aus GitHub.
Portable Simulationen
Ein Ordner aus Specs, statischen Dateien und Konfiguration, den die Engine unverändert bedient, wo immer sie läuft: lokal mit der CLI, in Docker, in der CI oder gehostet über den Portable-Modus der GitHub Action. Das Layout ist dasselbe, das App-Simulationen beim Deploy verpacken, die Formate bleiben also austauschbar.
Wähle sie, wenn der Mock als einfache Dateien leben soll: Arbeit offline, CI-Pipelines, ein Repo, das dein Team reviewt, oder alles, was dein Netz nicht verlassen darf.
Siehe Portable Simulationen.
Codegen-Simulationen
Ein generierter Go-Server: Die Engine macht aus deiner Spec typisierte Handler, die du öffnen und bearbeiten kannst, sodass Antworten echte Logik, Zustand und Rechnung tragen, wo Generierung allein nicht reicht. Die Spec verlässt dein Repository nie, was sie auch von jedem Upload-Limit befreit.
Wähle sie, wenn der Mock Verhalten braucht, das keine Konfiguration ausdrücken kann.
Siehe Codegen-Simulationen.
Und die fertige Art
Payment- und Identity-Sandboxes sind auch Simulationen, auf derselben Engine und mit fertig eingebautem Anbieterverhalten: Szenarien, Fehlerbilder und realistische Daten von Haus aus. Sie haben ihren eigenen Bereich.
Siehe Resiliente Backends.
Die Wahl
| Du willst | Nimm |
|---|---|
| Einen gehosteten Mock, den das Team im Browser bearbeitet | App-Simulation |
| Mocks im Code-Review, eine URL pro Branch | Aus GitHub |
| Denselben Mock offline, in Docker oder CI | Portable |
| Handler mit echter Logik darin | Codegen |
| Einen Payment- oder Identity-Anbieter, der einfach läuft | Backend-Sandbox |
Was immer du nimmst, die Engine ist dieselbe: Eine Spec generiert die Antworten, statische Endpunkte pinnen exakte, und Kontexte formen die Daten. Später den Typ zu wechseln heißt, dieselben Dateien anders zu packen, nie von vorn anzufangen.