Kernkonzepte

Mockomat basiert auf einem zentralen Prinzip: Domain-Intent sollte vom Modell bis zur Runtime sichtbar bleiben.

Jede Entscheidung, die Du triffst — eine Entität benennen, einen Feldtyp definieren, eine Relation herstellen — fließt durch eine verbundene Pipeline: von Deinem Domain-Modell über die API-Definition in das Live-Runtime-Verhalten und letztlich in ein generiertes Backend, das Dir gehört. Diese Seite erklärt die konzeptionellen Ebenen, die dies ermöglichen.

1. Domain-Ebene: Was das System bedeutet

Die Domain-Ebene ist die semantische Grundlage Deines Projekts. Du definiert die Struktur und Bedeutung Deiner Daten, bevor API- oder Implementierungsdetails festgelegt werden.

Entitäten und Tabellen

Eine Entität (oder Tabelle) repräsentiert ein echtes Geschäftskonzept: Customer, Order, Invoice, Subscription. Jede Entität hat einen Namen, eine Reihe von Attributen (Spalten) und optional eine oder mehrere Relationen zu anderen Entitäten.

Benennung ist wichtig. Mockomat ermutigt Du, die tatsächliche Geschäftssprache Deines Teams zu verwenden, anstatt generische Beispielnamen. Ein Modell mit Customer und Subscription kommuniziert Absicht weitaus besser als Table1 und Table2.

Attribute

Jedes Attribut hat:

• Name — ein beschreibender Bezeichner (z. B. firstName, totalAmount, isActive)
• Typ — der Datentyp, z. B. String, Integer, Float, Boolean, Date, JSON, Enum
• Pflichtfeld-Flag — ob das Feld immer einen Wert haben muss
• Durchsuchbar-Flag — ob das Feld an der searchTerm-Suche von Listenoperationen teilnimmt
• Sortierbar- und Filterbar-Flag — werden mit dem Modell gespeichert; Sortierbar markiert im Code-Export außerdem sortierbare Listenspalten

Von diesen Flags ändert nur Durchsuchbar die Mock-API. Sortieren funktioniert mit jedem Attribut, das an eine Datenspalte gebunden ist (sortField), und Filtern nutzt die Parameter, die Du an einer Operation definierst (siehe API Design (Englisch)).

Relationen

Relationen verbinden Entitäten und drücken geschäftliche Besitz- oder Referenzmuster aus:

• Eins-zu-Eins (1:1) — z. B. User → Profile
• Eins-zu-Viele (1:n) — z. B. Customer → Order[]
• Viele-zu-Viele (m:n) — z. B. Product ↔ Category

Jede Relation hat eine Richtung und eine Kardinalität. Die Relationsdefinition bestimmt, wie die Runtime Abfragen auflöst: Wenn Du eine Order abfragen, werden die zugehörigen Customer-Daten basierend auf diesen Definitionen aus der zugrunde liegenden Datenquelle zusammengestellt.

Warum diese Ebene wichtig ist

• Reduziert Benennungsdrift — alle im Team verwenden das gleiche Vokabular.
• Verbessert teamübergreifende Abstimmung — Frontend- und Backend-Entwickler teilen ein Modell der Wahrheit.
• Macht Architektur überprüfbar — Domain-Intent ist explizit, nicht im Code vergraben.
• Ermöglicht Automatisierung — Code-Generierung, API-Exposition und Runtime-Verhalten leiten sich alle von dieser Ebene ab.

cc-01-domain-layerMissing

Domain-Ebenen-Modell mit Entitäten und Relationen.

2. API-Definitionsebene: Wie das System exponiert wird

Die API-Ebene übersetzt Domain-Intent in eine Abfrage- und Operationsoberfläche. Mockomat verwendet einen Code-First-GraphQL-Ansatz: Deine Modelldefinitionen werden automatisch in ein vollständig typisiertes GraphQL-Schema übersetzt.

Dynamische Schema-Generierung

Wenn ein Projekt aktiviert wird, generiert Mockomat ein GraphQL-Schema im laufenden Betrieb:

1. Modelldefinitionen laden — alle Entitäten, Attribute, Relationen und Konfigurationen aus dem Projekt lesen.
2. GraphQL-Typen konstruieren — jede Entität wird zu einem GraphQL-Objekttyp; jedes Attribut wird zu einem typisierten Feld.
3. Abfrage-Einstiegspunkte konstruieren — Listen- und Detailabfragen werden für jede Entität generiert.
4. Resolver registrieren — Feld-Level-Resolver handhaben Datenabruf, Zuordnung und Relationsauflösung.
5. Anfragen entgegennehmen — das Schema ist sofort bereit, Abfragen zu bedienen.

Das bedeutet, Du schreibst niemals Schema-Dateien manuell. Das Schema ist immer mit Deinem Modell synchronisiert.

Abfragestruktur

Jede Entität generiert automatisch zwei Abfragetypen:

• Listenabfrage — gibt eine paginierte Sammlung mit optionaler Filterung und Sortierung zurück.
• Detailabfrage — gibt ein einzelnes Element anhand seines Bezeichners zurück.

Wenn Du beispielsweise eine Product-Entität modellieren, könnten die generierten Abfragen so aussehen:

query {
  products(page: 1, pageSize: 20, sortField: "price", sortDirection: ASC) {
    items {
      id
      name
      price
      category {
        id
        name
      }
    }
    total
  }
}

query {
  product(id: "abc-123") {
    id
    name
    price
    description
  }
}

Filterung

Filter werden pro Operation im API-Design definiert — feste Scope-Filter und Parameter des Aufrufers, jeweils mit einem Operator:

Operator	Beschreibung	Anwendbare Typen
eq	Gleich	Alle Typen
neq	Ungleich	Alle Typen
gt / gte	Größer als / größer oder gleich	Zahlen, Datumsangaben
lt / lte	Kleiner als / kleiner oder gleich	Zahlen, Datumsangaben
in	Einer der Werte einer Liste	Alle Typen
like	Enthält (ohne Groß-/Kleinschreibung)	Strings
notIn	Keiner der Werte einer Liste (nur Scope-Filter)	Alle Typen
isNull / isNotNull	Ist null / ist nicht null (nur Scope-Filter)	Alle Typen

Alle Filter einer Operation werden mit AND verknüpft; OR und Verschachtelung gibt es zur Anfragezeit nicht.

Sortierung

Sortiert wird mit sortField (ein Attributname) und sortDirection — aufsteigend (ASC) oder absteigend (DESC).

Paginierung

Mockomat verwendet seitenbasierte Paginierung:

• page — Seitennummer, beginnend bei 1 (Standard: 1)
• pageSize — Datensätze pro Seite, höchstens 100 (Standard: Standard-Seitengröße der Operation, 25, sofern nicht geändert)

Die Antwort verpackt die Datensätze in items, neben total, page und pageSize.

cc-02-endpoint-configMissing

API-Definition und Endpunktkonfigurationsansicht.

3. Runtime-Ebene: Wie Verhalten validiert wird

Die Runtime-Ebene ist der Ort, an dem Deine Modell- und API-Entscheidungen gegen echte Abfrageausführung getestet werden. Sie beantwortet die Frage: Verhält sich das System so, wie Du es beabsichtigt hast?

Wie die Mock-Runtime funktioniert

Die Mock-Runtime-Engine ist der Kern des Mockomat-Werts. Du akzeptiert GraphQL-Abfragen und übersetzt sie durch eine vierstufige Pipeline in MongoDB-Operationen:

1. GraphQL-Request-Parser — parst den eingehenden Abfragestring in einen abstrakten Syntaxbaum (AST).
2. Query-Planner — analysiert den AST zusammen mit Modell-Metadaten, um einen Ausführungsplan zu erstellen.
3. MongoDB-Query-Builder — übersetzt den Ausführungsplan in eine MongoDB-Aggregationspipeline.
4. Result-Assembler — formt MongoDB-Ergebnisse um, damit sie der erwarteten GraphQL-Antwortstruktur entsprechen.

Diese Pipeline läuft bei jeder Abfrage. Da MongoDB Daten in flachen (denormalisierten) Sammlungen speichert, simuliert die Runtime relationale Strukturen — sie verbindet verwandte Daten, löst verschachtelte Felder auf und stellt die endgültige Antwort zusammen, als käme sie von einem vollständig relationalen Backend.

Vorschau vs. externe Nutzung

Der gleiche Runtime-Endpunkt bedient zwei Zielgruppen:

• Vorschau — die In-App-Runtime-Seite, auf der Du Abfragen testest, Antwortstrukturen inspizierst und Verhalten während der Modellierung validierst.
• Externe Konsumenten — Deine Frontend-Anwendung, Deine Test-Suite oder Deine CI-Pipeline, die denselben Mock-API-Endpunkt aufruft.

Beide verwenden denselben REST-Endpunkt: POST /mock/{slug}/graphql. Das bedeutet, was Du in der Vorschau validieren, ist genau das, was externe Konsumenten erhalten.

Was Validierung in der Praxis bedeutet

Runtime-Validierung bedeutet nicht nur „gibt die Abfrage Daten zurück". Du bestätigt:

• Feldstrukturen — sind die zurückgegebenen Typen und Strukturen wie erwartet?
• Relationsauflösung — werden verschachtelte Objekte korrekt aufgelöst?
• Paginierungsverhalten — erzeugen page und pageSize konsistente Ausschnitte?
• Sortierstabilität — erzeugt die Sortierung nach einem Feld eine vorhersagbare Reihenfolge?
• Filtergenauigkeit — stimmen Filterausdrücke mit der korrekten Datenteilmenge überein?
• Null-Behandlung — werden optionale Felder korrekt als null dargestellt, wenn keine Daten vorhanden sind?

cc-03-runtime-flowMissing

Modell-zu-Runtime-Fluss mit Validierungsprüfpunkten.

4. Datenquellen und Feldzuordnung

Jedes Attribut in Deinem Modell benötigt eine Datenquelle. Mockomat unterstützt drei Zuordnungstypen, die bestimmen, woher Feldwerte stammen (der Attribut-Editor bietet Datenquelle und Konstante an und zeigt Berechnet nur bei Attributen, die bereits eine berechnete Zuordnung haben):

SOURCE — Importierte Datensatzspalten

Bindet ein 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.

Verwende dies, wenn Du möchtest:

• Realistische Namen, Adressen, Produktdaten, Kategorien oder Messwerte
• Große Mengen vielfältiger Daten
• Daten, die in Demos und beim Testen authentisch wirken

CONSTANT — Konstante Werte

Legt einen festen Wert am Attribut fest. Die Runtime liefert ihn in jeder Zeile, in Zeilen importierter Daten ebenso wie in Zeilen, die aus Wertepools zusammengesetzt werden.

Verwende dies, wenn Du möchtest:

• Standard-Statuswerte (z. B. "active")
• Feste Konfigurationswerte

COMPUTED — Abgeleitete Werte (nicht ausgewertet)

Speichert einen Ausdruck über andere Felder desselben Datensatzes (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.

cc-04-data-sourcesMissing

Feldzuordnungskonfiguration mit verschiedenen Datenquellentypen.

Datenquellenverfügbarkeit

Free User

Jeder Tarif, auch Gast-Sitzungen, hat dieselben Zuordnungstypen und denselben gemeinsamen Datenpool.

5. Projektisolierung und Multi-Tenancy

Jedes Mockomat-Projekt arbeitet in seinem eigenen isolierten Kontext:

• Gemeinsamer, schreibgeschützter Datenpool — Mock-Daten stammen aus einem gemeinsamen Pool importierter Datensätze; ein Projekt liest nur die Tabellen, an die es gebunden ist, und verändert Pool-Daten nie.
• Unabhängiges Schema — das GraphQL-Schema wird pro Projekt basierend auf seinem spezifischen Modell generiert.
• Slug-basierte Endpunkte — jedes Projekt erhält einen eindeutigen URL-Pfad (/mock/{slug}/graphql).
• Mandanten-Scoping — Modelle, Mitglieder und API-Schlüssel gehören zu einem Mandanten, und jede Anfrage wird dagegen geprüft, was strikte Isolation zwischen Organisationen gewährleistet.

Das bedeutet, mehrere Teams können gleichzeitig an verschiedenen Projekten arbeiten, ohne jedes Risiko von Datenlecks oder Schema-Konflikten.

Enterprise-Limits

Enterprise User

Die Isolation ist in jedem Tarif gleich. Enterprise wird mit unserem Vertrieb vereinbart: Limits wie Projekte, Anfragen und Teamgröße werden pro Vertrag angepasst.

6. KI + Architektur gemeinsam

KI beschleunigt die Erstellung. Mockomat bewahrt Strukturqualität und Erklärbarkeit, während sich Anforderungen weiterentwickeln.

Die Plattform ist darauf ausgelegt, neben KI-Tools zu arbeiten, nicht sie zu ersetzen. Während KI schnell Code-Fragmente generieren kann, bietet Mockomat den strukturellen Kontext, der KI-generiertem Code oft fehlt:

• Schema-Konsistenz — Dein Domain-Modell ist die einzige Quelle der Wahrheit, unabhängig davon, ob Du es manuell oder mit KI-Unterstützung erstellst.
• Runtime-Verifizierung — jede Änderung kann über die Vorschau-Pipeline validiert werden, bevor sie die Produktion erreicht.
• Nachvollziehbare Entscheidungen — Modelländerungen sind explizit und überprüfbar, nicht in KI-generiertem Code vergraben.

Integrator-Perspektive

Developer / Integrator

Behandeln Du generierte Artefakte als Ausgangspunkte, nicht als endgültige Wahrheit. Behalte das Modell als Quelle der Absicht bei und lässt Du das Runtime-Verhalten die Qualität bestätigen. Wenn Du KI-unterstützte Workflows integrieren, verwendest Du das Mockomat-Modell als Vertrag, dem KI-generierte Konsumenten entsprechen müssen.

Enterprise-Perspektive

Enterprise User

Langfristiger Wert entsteht durch wiederholbare Architektur, nicht nur durch schnellen initialen Output. Domain-Kontinuität ist der Kontrollpunkt für teamübergreifende Evolution. Verwende Mockomat-Modelle als Governance-Artefakte, die einzelne Sprint-Zyklen überdauern.