App-Simulationen

Eine App-Simulation ist die Art, die du im Browser baust: anlegen, mit Services füllen, deployen, und sie antwortet unter ihrer URL. Sie ist die Standard-Art, die der Rest dieser Doku stillschweigend annimmt, und nichts daran verlangt eine Installation.

Eine Simulation, viele Services

Eine Simulation ist ein Behälter für Services, und jeder Service ist eine API. Eine einzelne Simulation bedient mehrere nebeneinander, so wie dein Produktivsystem mit mehreren Abhängigkeiten spricht; eine URL kann damit für dein ganzes Backend stehen. Services kommen aus drei Quellen:

• Deine eigene OpenAPI-Spec, hochgeladen und unter einem Pfadpräfix gemountet.
• Eine Katalog-Spec: Stripe, Twilio, Auth0 und die anderen, in zwei Klicks hinzugefügt.
• Statische Endpunkte, von Hand geschriebene Antworten, die sich über ihr erstes Pfadsegment zu Services gruppieren.

Sie mischen sich frei. Eine typische Simulation trägt die eigene API des Teams aus einer Spec, einen Zahlungsanbieter aus dem Katalog und eine Handvoll statischer Endpunkte für die Ecke, die sonst nichts abdeckt - alles unter <domain>/app/<deine-org>/<slug>, jeder Service auf seinem Präfix, alles mit einem Deploy ausgeliefert.

Siehe OpenAPI-Spec hochladen und aktualisieren, Aus dem Katalog starten und Endpunkte und statische Antworten.

Alles hängt an der Simulation

Die Simulation ist die Einheit, an der alles andere hängt, und ihre Seitenleiste ist die Karte:

• Quellen sind, was sie bedient: die Endpunkte, der Katalog für mehr davon und die Kontexte, die generierte Daten formen.
• Aufzeichnungen sind, was sie sich merkt: der Anfragenverlauf und die eingefangenen Replays.
• Einstellungen sind, was sie formt: Name und Icon, die Laufzeit der Bereitstellung, wer sie erreichen darf und die eigene Konfiguration jedes Service.

Zwei Simulationen teilen hier nichts. Jede hat ihre eigene URL, ihren eigenen Verlauf und ihre Aufzeichnungen, ihre eigene Zugriffsrichtlinie; darum ist eine Simulation pro Projekt oder Umgebung der übliche Schnitt.

Der Kreislauf

Alles wird in der App bearbeitet und beim Tippen gespeichert; die laufende Simulation liefert weiter den letzten deployten Stand, bis du auf Deploy klickst, und ein Deploy dauert Sekunden. Diese Trennung macht eine App-Simulation angenehm zum Iterieren: Sammle so viele Änderungen, wie du willst, liefere sie aus, wenn es passt, und die URL bleibt dieselbe.

Siehe Simulation erstellen für die erste und Deploy und URLs dafür, was ein Deploy tut.

Wann eine andere Art besser passt

• Mocks, die in einem Repo leben und wie Code reviewt werden sollen: Deploye sie aus GitHub.
• Derselbe Mock offline oder in der CI: Fahre ihn portabel.
• Antworten, die echte Logik brauchen: Generiere eine Codegen-Simulation.

Später zu wechseln heißt, dieselben Dateien anders zu packen: Jeder Deploy einer App-Simulation erzeugt ohnehin das portable Paket, das dir Lokal ausführen in die Hand gibt.