Export
Der Export macht aus Deinem Mockomat-Modell Dateien, die Dir gehören. Es gibt zwei Formate:
| Format | Was Du erhältst | Verfügbar in |
|---|---|---|
| OpenAPI-Spezifikation | Eine OpenAPI-3.0.3-YAML-Datei mit einem Schema pro Tabelle | Jedem Tarif mit Konto |
| Code-Paket | Ein ZIP mit einem generierten NestJS-Backend für Deine Tabellen | Professional und höher |
Code-Pakete erfordern mindestens die Rolle Bearbeiter und Bearbeitungszugriff auf das Projekt. Der Export ändert Dein Projekt nie, und der generierte Code hat keine Laufzeitabhängigkeit von Mockomat.
Export-Assistent mit den Schritten Format und Optionen.
Einen Export starten
Öffne Export in der App. Der Export-Assistent führt Dich durch vier Schritte:
- Projekt — wähle das Projekt, das exportiert werden soll.
- Exportformat — OpenAPI-Spezifikation oder Code-Paket.
- Export konfigurieren — für Code-Pakete zeigt dieser Schritt das Paket, das Dein Tarif enthält.
- Prüfen & exportieren — bestätigen. Eine OpenAPI-Datei wird sofort heruntergeladen; ein Code-Paket wird im Hintergrund erzeugt und erscheint mit einem Download-Link, sobald es fertig ist.
Bietet Deine App noch keine Code-Pakete an, exportiere in der Zwischenzeit die OpenAPI-Spezifikation.
Auswahl des Exportformats: OpenAPI-Spezifikation oder Code-Paket.
OpenAPI-Spezifikation
Der OpenAPI-Export schreibt Dein Modell als components.schemas: ein Schema pro Tabelle, mit ihren Attributen als Eigenschaften, Pflichtattributen, Enum-Werten und Relationen. Er enthält keine Pfade. Nutze ihn, um das Datenmodell mit anderen Werkzeugen zu teilen, oder als Ausgangspunkt eines Vertrags, den Dein Backend-Team umsetzt.
Code-Paket
Das Code-Paket ist ein generiertes Projekt, das Du selbst ausführen, ändern und deployen kannst.
| Paket | Tarife | Inhalt |
|---|---|---|
| Pro | Professional, Business | NestJS-Backend |
| Enterprise | Enterprise | NestJS-Backend + Angular-Frontend |
Was das Backend enthält
- Eine NestJS-Anwendung mit einer GraphQL-API (Code-first), ein Modul pro Tabelle: Entität, Resolver, Service sowie Ein- und Ausgabetypen.
- Pro Tabelle: eine paginierte Listenabfrage mit Suche, eine Abfrage per ID und Mutationen zum Anlegen, Aktualisieren, Löschen und Wiederherstellen von Datensätzen.
- TypeORM-Entitäten für MySQL / MariaDB.
- Authentifizierung: Anmeldung mit JWT und ein Benutzermodul. Beim ersten Start legt das Backend einen Admin-Benutzer an und gibt dessen Passwort einmalig in der Konsole aus.
- Eine Docker-Compose-Datei, die MySQL und Redis startet, und eine README mit den Einrichtungsschritten.
Der heutige Generator hat Grenzen, die Du kennen solltest, bevor Du mit dem Code planst:
- Er zielt auf MySQL / MariaDB und enthält immer Authentifizierung und die Docker-Compose-Datei. Die Datenbank- und Optionsschalter im Assistenten verändern das Paket noch nicht.
- Relationen zwischen Deinen Tabellen werden nicht generiert. Ergänze sie selbst in den generierten Entitäten und Services.
- Generierte Spalten akzeptieren leere Werte: Das Flag Pflichtfeld eines Attributs wird noch nicht angewendet.
Lokal ausführen
Die README im Paket listet die Schritte auf. Kurz gesagt, im Backend-Ordner:
npm install
cp .env.example .env # dann die Datenbank-Zugangsdaten eintragen
npm run migration:run
npm run start:devDas Backend erwartet eine MySQL- oder MariaDB-Datenbank und Redis.
Übersicht über die Struktur des generierten Backend-Projekts.
Vor dem Export
Geh zuerst die Runtime-Validierungs-Checkliste durch. Ein sauberes Modell ergibt saubereren Code:
- Namen folgen Deinen Konventionen — Tabellen- und Attributnamen werden zu Klassen-, Typ- und Feldnamen.
- Attributtypen stimmen — sie werden zu Spalten- und GraphQL-Feldtypen.
- Durchsuchbare Attribute werden zu den Suchfeldern der generierten Listenabfrage, und sortierbare Attribute werden als sortierbare Listenspalten markiert.
Operationen und Parameter, die Du im API Design (Englisch) entworfen hast, prägen Deine Mock-API; das generierte Backend bringt pro Tabelle eigene Standardabfragen und -mutationen mit.
Was Du nach dem Export prüfen solltest
Modulgrenzen und Benennung
- Entspricht jedes Modul einer Tabelle Deines Modells?
- Sind Modul-, Service- und Resolver-Namen konsistent und aussagekräftig?
Eingaben und Validierung
- Enthalten die Eingaben zum Anlegen und Aktualisieren die erwarteten Felder?
- Ergänze Validierung für die Felder, die Deine Anwendung verlangt — generierte Felder sind optional.
Relationen
- Ergänze die Relationen Deines Modells in den generierten Entitäten, mit der Richtung und Kardinalität, die Du entworfen hast.
- Lade verknüpfte Datensätze in den Services so, wie Deine Anwendung es braucht.
Checkliste für das Code-Review nach dem Export.
Checkliste für die Übergabe nach dem Export
- Verantwortung pro Modul festlegen — jedes Modul braucht eine verantwortliche Person, die es erweitert.
- Generiertes kennzeichnen — vermerke, welche Dateien generiertes Gerüst sind und welche eigene Geschäftslogik brauchen.
- Bekannte Lücken festhalten — Geschäftsregeln, externe Integrationen und Hintergrundjobs werden nicht generiert.
- Eine Ausgangsversion committen — committe den generierten Code als erste Version und verzweige von dort.
- Umgebungen konfigurieren — Datenbankverbindungen, Umgebungsvariablen und Deployment-Pipelines.
- Früh testen — generierter Code kompiliert, aber prüfe das Verhalten früh mit Integrationstests.
Erster lokaler Start und Prüf-Checkliste.
Eigentum am Code
Der generierte Code gehört Dir: keine Laufzeitabhängigkeit von Mockomat, keine Lizenzgebühren auf die Ausgabe, keine Einschränkung der kommerziellen Nutzung. Ändere ihn, betreibe ihn auf Deinen eigenen Servern oder bei einem beliebigen Hosting-Anbieter und teile ihn mit Kunden oder Partnern.