Export

Export verbindet Modellabsicht und eigene Backend-Implementierung. Es nimmt Dein validiertes Mockomat-Projekt und generiert ein produktionsreifes NestJS-Backend, das Dir vollständig gehört — keine Laufzeitabhängigkeit von Mockomat, kein Vendor-Lock-in.

Der generierte Code gehört Dir. Du kannst ihn modifizieren, erweitern, deployen und kommerzialisieren — ohne Einschränkungen.

Export-Ziele

Der Export sollte ein Starter-Backend erzeugen, das:

• Lesbar ist — sauberer, gut strukturierter Code, der NestJS-Konventionen und Best Practices folgt.
• Strukturiert ist — nach Domain-Modulen mit klarer Verantwortungstrennung organisiert.
• Nachvollziehbar ist — jedes generierte Modul, jede Entität und jeder Resolver ist auf Dein Mockomat-Modell zurückführbar.
• Bereit für Team-Ownership ist — Codequalität, auf der ein Entwicklungsteam sofort aufbauen kann.

Das Ziel ist nicht, Backend-Entwicklung zu ersetzen — sondern die repetitive Scaffolding-Phase zu eliminieren und Deinem Team zu ermöglichen, sich ab dem ersten Tag auf Geschäftslogik zu konzentrieren.

ex-01-export-configMissing

Export-Konfigurationspanel mit Zieloptionen.

Eingabequellen

Der Export kann ein Backend aus zwei Quellen generieren:

Mockomat-natives Projekt

Verwende Deine bestehenden Projektmetadaten — alle Entitäten, Attribute, Relationen, Zuordnungen und API-Konfigurationen werden als Generierungseingabe verwendet. Dies ist der empfohlene Weg für die meisten Nutzer.

OpenAPI-Import

Lade eine OpenAPI-Spezifikation (JSON oder YAML) hoch und generiere ein Backend direkt aus der Spezifikation. Dies ist nützlich, wenn Du bereits einen API-Vertrag außerhalb von Mockomat definiert hast und die Implementierung generieren möchtest.

ex-01b-input-sourcesMissing

Export-Quellauswahl: Mockomat-Projekt oder OpenAPI-Import.

Export-Optionen

Beim Starten eines Exports konfigurierst Du mehrere Optionen, die die Form des generierten Backends bestimmen:

API-Stil

Option	Beschreibung
GraphQL (code-first)	Generiert Resolver, Objekttypen und Eingabetypen mit NestJS-GraphQL-Dekoratoren.
REST (OpenAPI-basiert)	Generiert Controller mit Route-Dekoratoren und Swagger-Annotationen.
Beide	Generiert sowohl GraphQL-Resolver als auch REST-Controller für dieselben Domain-Modelle.

Persistenzschicht

Option	Beschreibung
TypeORM (SQL)	Generiert Entitäten mit TypeORM-Dekoratoren für relationale Datenbanken (PostgreSQL, MySQL, MariaDB).
Mongoose (MongoDB)	Generiert Schemas und Modelle für MongoDB via Mongoose.
In-Memory	Generiert einfache In-Memory-Stores für schnelles Prototyping ohne Datenbank-Setup.

Authentifizierungs-Scaffolding

Das generierte Projekt enthält optionales JWT-Authentifizierungs-Scaffolding:

• Einen einfachen User-Entitäts-Stub
• JWT-Guard-Konfiguration
• Dekoratoren für geschützte Endpunkte
• Login- und Registrierungs-Endpunkt-Stubs

Dieses Scaffolding bietet einen Ausgangspunkt — Du ersetzt die Stubs mit Deiner tatsächlichen Authentifizierungslogik.

Was generiert wird

Der Export erzeugt ein vollständiges, lauffähiges NestJS-Projekt:

/nestjs-backend
  /src
    /modules
      /customer
        customer.module.ts
        customer.controller.ts    (REST) or customer.resolver.ts (GraphQL)
        customer.service.ts
        customer.entity.ts
        /dto
          create-customer.dto.ts
          update-customer.dto.ts
      /order
        order.module.ts
        order.controller.ts
        order.service.ts
        order.entity.ts
        /dto
          create-order.dto.ts
          update-order.dto.ts
    /common
      /filters
      /interceptors
      /pipes
    app.module.ts
    main.ts
  package.json
  tsconfig.json
  README.md

Was jede Datei enthält

Datei	Zweck
Entity	Datenbankschema-Definition mit Dekoratoren (TypeORM oder Mongoose)
Service	Geschäftslogik-Schicht mit CRUD-Operationen und Relationsbehandlung
Controller/Resolver	API-Schicht, die Endpunkte mit Eingabevalidierung exponiert
DTOs	Datentransferobjekte mit class-validator-Dekoratoren für Eingabevalidierung
Module	NestJS-Modul, das Service, Controller und Entity verbindet
Common	Gemeinsame Filter, Interceptors und Pipes, die modulübergreifend verwendet werden

Typischer Export-Ablauf

1. Modell- und Runtime-Bereitschaft validieren

Vor dem Export durchlaufe die Runtime-Validierungscheckliste. Bestätige, dass:

• Alle Entitäten vollständige Attributzuordnungen haben.
• Relationen in der Vorschau korrekt aufgelöst werden.
• Filter- und Sortieroperationen wie erwartet funktionieren.
• Keine ungelösten Hinweise verbleiben.

Ein sauberer Runtime-Validierungsdurchlauf erhöht die Qualität des generierten Codes erheblich.

2. Export-Optionen wählen

Wähle Deinen API-Stil, Deine Persistenzschicht und Authentifizierungspräferenzen. Wenn Du unsicher bist, beginne mit GraphQL + TypeORM — dies ist die häufigste Konfiguration für NestJS-Backends.

3. Paket generieren

Klicke auf Generieren und warte, bis das Backend-Projekt erstellt wird. Der Generierungsprozess liest Deine vollständige Modellkonfiguration und erzeugt alle Dateien in einem einzigen Durchlauf.

4. Herunterladen und lokal ausführen

Das generierte Projekt wird als .zip-Datei geliefert. Entpacke es und führst Du aus:

npm install
npm run start:dev

Das Backend startet auf einem lokalen Port mit aktiviertem Hot Reload. Du kannst die API sofort mit Deinem bevorzugten GraphQL-Client oder REST-Tool testen.

5. An das Implementierungsteam übergeben

Das generierte Projekt ist ein Ausgangspunkt, kein fertiges Produkt. Übergib es Deinem Entwicklungsteam mit klarem Kontext über:

• Was generiert wurde und warum
• Welche Teile produktionsbereit sind
• Welche Teile benutzerdefinierte Implementierung benötigen

ex-02-generated-structureMissing

Übersicht der generierten Backend-Projektstruktur.

Was nach dem Export zu prüfen ist

Nach der Generierung Deines Backends überprüfe diese Bereiche, bevor Du darauf aufbaust:

Modulgrenzen und Benennung

• Entspricht jedes Modul einer Domain-Entität aus Deinem Mockomat-Modell?
• Sind die Modul-, Service- und Controller-Namen konsistent und aussagekräftig?
• Entspricht die Dateiorganisation den Konventionen Deines Teams?

DTO- und Validierungsabdeckung

• Enthalten die DTOs alle Pflichtfelder?
• Sind class-validator-Dekoratoren korrekt angewendet (z. B. @IsString(), @IsNumber(), @IsOptional())?
• Unterscheiden sich Create- und Update-DTOs angemessen (Create erfordert alle Felder, Update erlaubt partielle)?

Resolver-/Controller-Struktur

• Sind alle beabsichtigten Endpunkte generiert?
• Stimmen die Routenpfade oder Abfragenamen mit Deinem API-Design überein?
• Sind Guards und Dekoratoren korrekt angewendet?

Relationsbehandlung

• Sind Entitätsrelationen mit den korrekten Dekoratoren definiert (@OneToMany, @ManyToOne, @ManyToMany)?
• Behandelt die Service-Schicht das Laden von Relationen (eager vs lazy)?
• Sind Kaskadierungsoptionen angemessen konfiguriert?

ex-02b-code-reviewMissing

Checkliste für die Code-Überprüfung nach dem Export.

Übergabe-Checkliste nach dem Export

Verwende diese Checkliste bei der Übergabe des generierten Projekts an Dein Implementierungsteam:

• Verantwortung nach Modul/Domain zuweisen — jedes Modul sollte einen klaren Verantwortlichen haben, der für seine Erweiterung zuständig ist.
• Definieren, was generiert vs. benutzerdefiniert bleibt — markierst Du, welche Dateien generiertes Scaffolding sind und welche benutzerdefinierte Geschäftslogik benötigen.
• Bekannte Lücken erfassen — dokumentiere Features, die Mockomat nicht generiert (komplexe Geschäftsregeln, externe Integrationen, Hintergrundjobs).
• Versionskontrolle einrichten — committe den generierten Code als Deine initiale Baseline und branche davon ab.
• Umgebungen konfigurieren — richte Datenbankverbindungen, Umgebungsvariablen und Deployment-Pipelines ein.
• Die vollständige Testsuite ausführen — auch wenn generierter Code kompiliert, verifiziere das Verhalten frühzeitig mit Integrationstests.

ex-03-post-export-runMissing

Erster lokaler Start und Verifikations-Checkliste.

Code-Eigentum

Generierter Code gehört zu 100% Dir. Es gibt keine Laufzeitabhängigkeit von Mockomat, keine Lizenzgebühren auf die generierte Ausgabe und keine Einschränkungen bei der kommerziellen Nutzung. Du kannst:

• Jede Zeile des generierten Codes modifizieren
• Auf jeder Infrastruktur deployen (AWS, GCP, Azure, On-Premise)
• In kommerziellen Produkten ohne Namensnennung verwenden
• Mit Kunden, Partnern oder Open-Source-Communities teilen

Das generierte Projekt ist eine Standard-NestJS-Anwendung. Jeder NestJS-Entwickler kann es sofort erweitern.

Tipp für Paid-Nutzer

Paid User

Verwende den Export an stabilen Meilensteinen, nicht nach jeder kleinen Änderung. Das hält Code-Reviews fokussiert und reduziert Churn. Ein guter Rhythmus ist der Export nach größeren Domain-Änderungen, nicht nach einzelnen Attribut-Anpassungen.

Enterprise-Tipp

Enterprise User

Behandeln Du Export-Artefakte als verwaltete Liefergegenstände. Füge Release-Notes und Entscheidungskontext für die Nachvollziehbarkeit bei. Nimm die Mockomat-Projektversion und eine Zusammenfassung der Modelländerungen seit dem letzten Export in Deine Release-Dokumentation auf.

Integrator-Deployment-Hinweis

Developer / Integrator

Das generierte Backend folgt Standard-NestJS-Mustern und kann in jeder Node.js-Hosting-Umgebung deployt werden. Für containerisierte Deployments fügst Du ein Dockerfile hinzu und passe die main.ts-Konfiguration für Deine Zielplattform an. Keine Mockomat-spezifische Runtime oder SDK erforderlich.