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:
string,number,boolean,date,json - Pflichtfeld-Flag — ob das Feld immer einen Wert haben muss
- Sortierbar-Flag — ob das Feld zur Sortierung von Ergebnissen verwendet werden kann
- Durchsuchbar-Flag — ob das Feld an Suchabfragen teilnimmt
- Filterbar-Flag — ob das Feld Filteroperationen unterstützt
Diese Flags beeinflussen direkt, wie die API-Ebene Deine Daten exponiert. Ein als sortable: true markiertes Feld wird für Sortieroperationen in GraphQL-Abfragen verfügbar. Ein als filterable: true markiertes Feld unterstützt Filterausdrücke.
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.
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:
- Modelldefinitionen laden — alle Entitäten, Attribute, Relationen und Konfigurationen aus dem Projekt lesen.
- GraphQL-Typen konstruieren — jede Entität wird zu einem GraphQL-Objekttyp; jedes Attribut wird zu einem typisierten Feld.
- Abfrage-Einstiegspunkte konstruieren — Listen- und Detailabfragen werden für jede Entität generiert.
- Resolver registrieren — Feld-Level-Resolver handhaben Datenabruf, Zuordnung und Relationsauflösung.
- 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(offset: 0, limit: 20, filter: { ... }, sort: { ... }) {
id
name
price
category {
id
name
}
}
}
query {
product(id: "abc-123") {
id
name
price
description
}
}Filterung
Das Filtersystem unterstützt typsichere, kombinierbare Ausdrücke:
| Operator | Beschreibung | Anwendbare Typen |
|---|---|---|
equals | Exakte Übereinstimmung | Alle Typen |
notEquals | Negation | Alle Typen |
contains | Teilstring-Übereinstimmung | Strings |
greaterThan / greaterThanOrEqual | Bereich (obere Grenze) | Zahlen, Datumsangaben |
lessThan / lessThanOrEqual | Bereich (untere Grenze) | Zahlen, Datumsangaben |
in | Wert in Menge | IDs, Enums |
isNull / isNotNull | Null-Prüfung | Alle Typen |
Filter können mit logischen AND- und OR-Operatoren kombiniert und für komplexe Ausdrücke verschachtelt werden.
Sortierung
Felder, die im Domain-Modell als sortable: true markiert sind, können in Sortieroperationen verwendet werden. Die Sortierrichtung ist entweder aufsteigend (ASC) oder absteigend (DESC).
Paginierung
Mockomat verwendet Offset-basierte Paginierung:
offset— Anzahl der zu überspringenden Elemente (Standard: 0)limit— Anzahl der zurückzugebenden Elemente (Standard: 20)
Dieses Modell ist einfach und funktioniert gut für die meisten Anwendungsfälle. Die Antwort enthält das Datenarray zusammen mit Paginierungs-Metadaten.
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:
- GraphQL-Request-Parser — parst den eingehenden Abfragestring in einen abstrakten Syntaxbaum (AST).
- Query-Planner — analysiert den AST zusammen mit Modell-Metadaten, um einen Ausführungsplan zu erstellen.
- MongoDB-Query-Builder — übersetzt den Ausführungsplan in eine MongoDB-Aggregationspipeline.
- 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 Offset und Limit 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?
Modell-zu-Runtime-Fluss mit Validierungsprüfpunkten.
4. Datenquellen und Feldzuordnung
Jedes Attribut in Deinem Modell benötigt eine Datenquelle. Mockomat unterstützt verschiedene Zuordnungstypen, die bestimmen, woher Feldwerte stammen:
OFF_FIELD — Echte Datensatzfelder
Ordnet ein Attribut einem Feld aus einem realen Datensatz zu (z. B. Open Food Facts). Dies verleiht Deiner Mock-API realistische, vielfältige Daten, die sich wie Produktionsdaten verhalten.
Verwende dies, wenn Du möchtest:
- Realistische Produktnamen, Kategorien oder Messwerte
- Große Mengen vielfältiger Daten
- Daten, die in Demos und beim Testen authentisch wirken
FAKE — Generierte Daten (Faker)
Ordnet ein Attribut einem Faker-Generator zu, der realistische synthetische Daten erzeugt: Namen, E-Mail-Adressen, Adressen, Datumsangaben, Preise und mehr.
Verwende dies, wenn Du möchtest:
- Personenbezogene Daten (Namen, E-Mail-Adressen, Telefonnummern)
- Finanzdaten (Preise, Kontonummern)
- Zeitliche Daten (Datumsangaben, Zeitstempel)
- Jeden Datentyp, der nicht durch echte Datensätze abgedeckt wird
CONST — Konstante Werte
Ordnet ein Attribut einem festen Wert zu, der für jeden Datensatz gleich ist.
Verwende dies, wenn Du möchtest:
- Standard-Statuswerte (z. B.
"active") - Feste Konfigurationswerte
- Platzhalterdaten während der frühen Modellierung
COMPUTED — Abgeleitete Werte (Zukunft)
Wird es ermöglichen, Feldwerte durch Ausdrücke basierend auf anderen Feldern zu definieren. Dies ist für ein zukünftiges Release geplant.
Feldzuordnungskonfiguration mit verschiedenen Datenquellentypen.
5. Projektisolierung und Multi-Tenancy
Jedes Mockomat-Projekt arbeitet in seinem eigenen isolierten Kontext:
- Separater Datenraum — jedes Projekt hat seine eigenen MongoDB-Sammlungen für Mock-Daten.
- 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 — jeder Datenzugriff wird nach Mandant gefiltert, 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.
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.