Codegen-Simulationen

Eine Codegen-Simulation ist ein generierter Go-Server: Die Engine liest deine Spec und schreibt typisierte Handler für jede Operation. Von Haus aus liefert jeder Handler denselben generierten Mock wie jeder andere Simulationstyp - der Unterschied ist, dass du die Datei öffnen und übernehmen kannst, Operation für Operation, wo immer eine Antwort echte Logik, Zustand oder Rechnung braucht. Die Spec verlässt dein Repository nie, was sie auch von jedem Upload-Limit befreit.

Von der Spec zum Service

Ein Befehl generiert ein Service-Paket aus einer Spec:

go run github.com/mockzilla/mockzilla/v2/cmd/gen/service@latest \
  -name petstore \
  https://petstore3.swagger.io/api/v3/openapi.json

petstore/
  gen.go           # generierte Typen, Handler, Registrierung - nie anfassen
  service.go       # deine Geschäftslogik - wird nie überschrieben
  middleware.go    # deine Middleware - wird nie überschrieben
  setup/
    codegen.yml    # was generiert wird
    config.yml     # Laufzeitverhalten
    context.yml    # Werte für generierte Daten
    openapi.json   # die Spec

Die Trennung ist der Vertrag: gen.go wird neu generiert, wann immer die Spec sich ändert, service.go und middleware.go werden einmal geschrieben und bleiben deine. Die API zu aktualisieren heißt, die Spec zu aktualisieren und go generate ./... zu laufen - deine Logik überlebt jede Neugenerierung.

Ein Handler, wenn du einen brauchst

Jede Operation bekommt eine Methode in service.go. Gib nil, nil zurück und der generierte Mock antwortet; darum verhält sich ein frischer Codegen-Service wie jede andere Simulation. Übernimm, wo es zählt:

func (s *service) GetPetByID(ctx context.Context, opts *GetPetByIDServiceRequestOptions) (*GetPetByIDResponseData, error) {
    resp, err := opts.GenerateResponse()   // beim generierten Mock anfangen
    if err != nil {
        return nil, err
    }
    resp.Body.ID = opts.PathParams.PetId   // und ihn dann sich verhalten lassen
    resp.Body.Name = "Custom Pet"
    return resp, nil
}

Anfragen und Antworten sind aus der Spec typisiert, der Compiler fängt also, was ein handgeschriebener Mock still falsch machen würde. middleware.go ist dieselbe Idee eine Ebene höher: Authentifizierung, Logging, Anfragen umschreiben, über den ganzen Service.

Konfiguration

Alles Konfigurierbare liegt in setup/:

• codegen.yml steuert die Generierung selbst: welche Handler entstehen, ob middleware.go generiert wird, Filterung.
• config.yml ist dieselbe Laufzeitkonfiguration wie bei jedem Simulationstyp - Latenz, Fehlerinjektion, ein Upstream mit Mock-Fallback, Caching, Replay. Die Optionen decken sich mit der Seite Service-Einstellungen.
• context.yml formt die generierten Daten, genau wie überall sonst.

Die vollständigen Referenzen liegen bei der Engine: Codegen-Modus und Codegen-Konfiguration.

Ausführen und deployen

go build erzeugt ein einzelnes, in sich geschlossenes Binary: Lass es lokal laufen, in der CI oder auf jeder Maschine, ohne Laufzeitabhängigkeiten. Für eine gehostete URL baut und deployt der Codegen-Modus der GitHub Action das Projekt bei jedem Push, Branch-URLs inklusive.

Starte vom Template, das CI, den API-Explorer und Beispiel-Services fertig mitbringt: mockzilla-codegen-template

Wann Codegen die richtige Art ist

Greif dazu, wenn der Mock sich verhalten muss: eine Signatur prüfen, einen Zähler führen, Anfragefelder mit Rechnung zurückgeben, Auth durchsetzen. Für alles darunter kommt Portable ganz ohne Code ans Ziel - und die beiden teilen sich ihre Konfiguration, portabel anzufangen und später zu generieren verliert also nichts.