Erste Schritte

Dieser Abschnitt hilft einem neuen Nutzer, in einer Sitzung vom ersten Zugang zu einem verlässlichen ersten Workflow zu gelangen. Am Ende hast Du ein funktionierendes Domain-Modell mit zugeordneten Daten, eine live GraphQL-API, die Du abfragen kannst, und ein klares Verständnis der nächsten Schritte.

Was Du erstellen wirst

In diesem Leitfaden wirst Du:

1. Auf Mockomat zugreifen und Deinen Arbeitsmodus wählen.
2. Eine Domain-Tabelle erstellen, die ein echtes Geschäftskonzept repräsentiert.
3. Attribute mit passenden Typen und Zuordnungen hinzufügen.
4. Mindestens eine Relation zu einer anderen Entität herstellen.
5. Dein Modell über die Live-Runtime in der Vorschau anzeigen.
6. Validieren, dass die API die erwarteten Datenstrukturen zurückgibt.

Der gesamte Prozess dauert etwa 15 Minuten.

gs-01-start-entryMissing

Einstiegspunkt von der Landingpage zum App-Workspace.

Schritt 1: Wähle Deinen Zugangs-Modus

Mockomat bietet zwei Zugangs-Modi, die jeweils für eine andere Arbeitsphase konzipiert sind:

Gastmodus (Schnellstart)

Der Gastmodus ist der schnellste Weg zu einer funktionierenden Mock-API. Keine Registrierung, kein Setup — öffne einfach Mockomat und beginne mit der Modellierung.

Was Du erhältst:

• Ein temporäres Projekt, dessen Mock-Endpunkt sich mit seinem Freigabe-Token öffnet
• Voller Zugang zum Modellierungsboard, zur Attributkonfiguration und zur Vorschau
• Derselbe gemeinsame Datenpool und dieselben Zuordnungstypen wie in jedem Tarif
• Ein live GraphQL-Endpunkt, den Du sofort abfragen kannst

Einschränkungen:

• Deine Arbeit bleibt in diesem Browser, bis Deine 24-stündige Gast-Sitzung endet. Die 24 Stunden laufen ab dem Beginn Deiner Gast-Sitzung, die die App beim ersten Öffnen in diesem Browser startet; ein Projekt, das Du später anlegst, hat also weniger Zeit. Eine stündliche Bereinigung löscht das Projekt danach, es kann also bis zu einer Stunde länger bestehen bleiben.
• Löschst Du die Cookies, geht Deine Arbeit früher verloren; registriere Dich, um sie zu behalten — die App bietet an, das Projekt in Dein Konto zu übernehmen
• Nur ein Projekt gleichzeitig
• Kein Team-Sharing oder Projektmanagement
• Keine API-Schlüssel — der Endpunkt öffnet sich mit dem Freigabe-Token des Projekts

Der Gastmodus ist ideal für schnelle Ideenvalidierung, Demos und die Evaluierung, ob Mockomat zu Deinem Workflow passt.

Kontomodus (Persistenter Workspace)

Der Kontomodus fügt Persistenz, Projektmanagement und die Möglichkeit hinzu, Deine Nutzung im Laufe der Zeit zu erweitern.

Was Du erhältst (Starter, kostenlos):

• 1 gespeichertes Projekt (ab Professional mehr)
• Persistente Modelle, die Browser-Sitzungen überdauern
• 1.000 API-Anfragen pro Tag
• Die Runtime-Vorschau jedes Projekts in der App (Aufrufe aus Deinem eigenen Code brauchen API-Schlüssel — ab dem Professional-Tarif)

Wann Du wechseln solltest:

• Wenn Dein erstes Modell sich als nützlich erweist und Du es behalten möchtest
• Wenn Du Deine Arbeit teilen möchtest — über Vorschau- und Kollaborationslinks oder, ab Professional, indem Du Teammitglieder einlädst
• Wenn Du über mehrere Sitzungen hinweg iterieren möchtest

Anleitung für Gast und Starter

Free User

Starte im Gastmodus, um ein konkretes Domain-Szenario schnell zu testen. Konzentriere Dich auf Namensklarheit, Pflichtfelder und Datenverhalten. Wenn Dein Modell nach einigen Abfragen standhält, erstelle ein kostenloses Konto, um es zu speichern.

Anleitung für registrierte Nutzer

Registered User

Wechsle zum Kontomodus, sobald Dein erstes Modell nützlich ist. Persistenz und Wiederholbarkeit werden wertvoller als reine Sofort-Geschwindigkeit. Mit einem Konto bleibt Dein Projekt erhalten, bis Du es löschst, und ab Professional kannst Du Dein Team einladen.

gs-02-guest-workspaceMissing

Gast-Workspace mit erster Domain-Tabelle.

Schritt 2: Modelliere einen echten Domain-Ausschnitt

Ein Domain-Ausschnitt ist eine kleine, zusammenhängende Teilmenge Deines Geschäftsmodells. Beginne mit ein oder zwei Entitäten, die etwas Reales in Deinem System repräsentieren.

Wähle aussagekräftige Namen

Vermeide generische Beispielnamen. Verwende die tatsächliche Geschäftssprache, die Dein Team bereits nutzt:

Gute Beispiele:

• Customer, Subscription, Invoice
• Order, Payment, Shipment
• Product, Category, Review
• Employee, Department, TimeEntry

Vermeiden:

• Table1, TestEntity, MyModel
• Data, Item, Thing

Aussagekräftige Namen machen Dein Modell selbstdokumentierend und sofort nützlich für Teamdiskussionen.

Attribute hinzufügen

Jede Entität benötigt Attribute, die ihre Daten beschreiben. Beim Hinzufügen von Attributen beachte:

Eigenschaft	Zweck	Beispiel
Name	Beschreibender Bezeichner	firstName, totalAmount, isActive
Typ	Datentyp	String, Integer, Boolean, Date
Pflichtfeld	Muss immer einen Wert haben	true für email, false für middleName
Durchsuchbar	Nimmt an der searchTerm-Suche teil	true für name, title

Die Flags Sortierbar und Filterbar ändern die Mock-API nicht: Du kannst nach jedem Attribut sortieren, das an eine Datenspalte gebunden ist, und Filtern nutzt die Parameter, die Du im API-Design an einer Operation definierst.

Praxistipp: Beginne mit 4–6 Kernattributen pro Entität. Du kannst später immer weitere hinzufügen, aber ein fokussiertes Modell liefert besseres Feedback als ein breites, oberflächliches.

Feldzuordnungen wählen

Jedes Attribut benötigt eine Datenquelle. Mockomat unterstützt drei Zuordnungstypen:

Datenquelle (SOURCE) — Importierte Daten

Binde das Attribut an eine Spalte des gemeinsamen Datenpools — importierte Datensätze: offene Daten, wo es eine geprüfte Quelle gibt, generierte Beispieldaten für die Blueprints. Die Runtime liefert die importierten Zeilen und erfindet nie Werte. Ideal für Namen, Adressen, Produktdaten, Kategorien, Datumsangaben und Beträge.

Konstante (CONSTANT) — Feste Werte

Legt einen festen Wert am Attribut fest, z. B. einen Standardstatus ("active"). Die Runtime liefert ihn in jeder Zeile, in Zeilen importierter Daten ebenso wie in Zeilen, die aus Wertepools zusammengesetzt werden.

Berechnet (COMPUTED) — Ausdrücke

Speichert einen Ausdruck über andere Felder, z. B. einen vollständigen Namen aus Vor- und Nachname. Die Runtime wertet Ausdrücke nicht aus, daher ist ein berechnetes Feld nicht Teil der Antwort. Der Attribut-Editor bietet Berechnet nicht mehr an; ein Attribut, das bereits eine berechnete Zuordnung hat, behält sie und wird als nicht ausgewertet gekennzeichnet.

gs-03-first-tableMissing

Erste Tabellenerstellung und Attributeinrichtung.

Eine Relation herstellen

Sobald Du eine Entität modelliert hast, füge eine zweite hinzu und verbinde diese:

1. Erstelle eine zweite Tabelle (z. B. Order, wenn Deine erste Customer war).
2. Definiere den Relationstyp: Hat ein Kunde viele Bestellungen (1:n)? Gehört eine Bestellung zu genau einem Kunden?
3. Lege die Richtung fest: Welche Entität besitzt die Relation?

Relationen sind entscheidend, um zu testen, wie Deine API verschachtelte Daten handhabt. Ein Modell mit mindestens einer Relation liefert Dir deutlich reichhaltigeres Vorschau-Feedback.

gs-03b-first-relationMissing

Erste Relationseinrichtung zwischen zwei Entitäten.

Schritt 3: Über die Vorschau validieren

Die Vorschau dient nicht nur für Demos. Sie ist ein Qualitätsprüfpunkt für das Modell. Jedes Mal, wenn Du Dein Modell änderst, führst Du eine Vorschau aus, um zu bestätigen, dass die Änderung sich wie erwartet verhält.

Was Du prüfst solltest

Feldlesbarkeit — Ergeben die zurückgegebenen Feldnamen Sinn? Sind sie konsistent (durchgehend camelCase, keine Abkürzungen)?

Datenstruktur-Konsistenz — Gibt jedes Feld den erwarteten Typ zurück? Sind Strings tatsächlich Strings, Zahlen tatsächlich Zahlen?

Relationsverhalten — Wenn Du eine Eltern-Entität abfragen, erscheinen Kind-Entitäten korrekt verschachtelt? Stimmt die Kardinalität (Array für 1:n, einzelnes Objekt für 1:1)?

Fehlende Zuordnungssignale — Ist eine Tabelle nicht an importierte Daten gebunden, sagt die Vorschau das, und die API liefert keine Zeilen für sie. Binde die Tabelle, bevor Du fortfährst.

Filter- und Sortierverhalten — Probiere einen Parameter aus, den Du an der Operation definiert hast, und sortiere mit sortField nach einem Attribut. Ergeben die Ergebnisse Sinn?

Häufige Vorschau-Probleme

Problem	Wahrscheinliche Ursache	Lösung
Feld gibt null zurück	Keine Zuordnung konfiguriert	Das Attribut an eine Datenspalte binden (Datenquellen-Zuordnung)
Relation gibt leeres Array zurück	Relation nicht korrekt definiert	Relationsrichtung und Zielentität prüfen
Sortierung hat keine Wirkung	sortField ist nicht der Name eines zugeordneten Attributs	Den Namen eines an eine Datenspalte gebundenen Attributs verwenden
Filter gibt alle Datensätze zurück	Die Operation definiert keinen Parameter für dieses Argument	Den Parameter im API-Design hinzufügen

gs-04-first-previewMissing

Erste Vorschau mit zugeordneten und nicht zugeordneten Feldern.

Schritt 4: Deine API abfragen

Sobald die Vorschau korrekt aussieht, ist Deine Mock-API bereits live. Rufe sie aus jedem GraphQL- oder HTTP-Client mit einem API-Schlüssel des Projekts auf — API-Schlüssel gibt es ab dem Professional-Tarif. Ein Gastprojekt nutzt stattdessen sein Freigabe-Token (?token=…). Details findest Du unter Integratoren.

Der Endpunkt für Dein Projekt lautet:

POST /mock/{dein-projekt-slug}/graphql
Authorization: Bearer mck_your_api_key

Probiere eine einfache Listenabfrage:

query {
  customers(page: 1, pageSize: 10) {
    items {
      id
      firstName
      lastName
      email
      orders {
        id
        totalAmount
        createdAt
      }
    }
    total
  }
}

Die Antwort enthält die importierten Zeilen, auf die Deine Zuordnungen zeigen, wobei Relationen automatisch aufgelöst werden.

gs-04b-first-queryMissing

Erste GraphQL-Abfrage gegen den live Mock-Endpunkt.

Schritt 5: Den nächsten Pfad bestimmen

Nach Deinem ersten erfolgreichen Modell- und Abfragezyklus hast Du mehrere Richtungen:

• Dein Modell vertiefen — mehr Entitäten hinzufügen, Attribute verfeinern, weitere Relationen herstellen.
• API-Exposition konfigurieren — definieren, welche Operationen verfügbar sind, Abfrage-Namenskonventionen festlegen.
• In Richtung Export gehen — wenn das Modell stabil genug ist, die Code-Generierung erkunden, um ein produktionsreifes NestJS-Backend zu erhalten.
• Blueprints verwenden — vorgefertigte Domain-Vorlagen erkunden, um zukünftige Projekte zu beschleunigen.
• Mit Deinem Team teilen — ein Konto erstellen (wenn im Gastmodus) und Mitarbeiter einladen.

Anleitung für Paid-Nutzer

Paid User

Standardisiere nach der ersten Validierung Deine Tabellenbenennung und Operationsstrategie. Dies erleichtert später Zusammenarbeit und Governance. Definiere Konventionen früh — sie gewinnen mit wachsendem Projekt an Wert.

Anleitung für Enterprise-Nutzer

Enterprise User

Behandle den ersten Workflow als Pilotmuster. Definiere Konventionen früh (Benennung, Zuständigkeit, Validierungskriterien) und verwende diese teamübergreifend wieder. Ein gut strukturierter Pilot wird zur Vorlage für jedes folgende Projekt.

gs-05-next-stepsMissing

Entscheidungspunkt nach dem ersten erfolgreichen Vorschau-Zyklus.

Was Du jetzt hast

Nach Abschluss dieses Leitfadens hast Du:

• Ein Domain-Modell mit mindestens einer Entität, aussagekräftigen Attributen und konfigurierten Datenzuordnungen
• Einen live GraphQL-API-Endpunkt, der Zeilen des Datenpools zurückgibt
• Die Bestätigung, dass sich Dein Modell bei echten Abfragen wie erwartet verhält
• Ein klares Verständnis des Workflows Modell → Vorschau → Abfrage

Von hier aus erkunde Kernkonzepte, um die Architektur hinter dem zu verstehen, was Du gerade erstellt hast, oder tauche in den Workspace ein für einen detaillierten Leitfaden zu den Modellierungswerkzeugen.