Runtime

Runtime-Validierung bestätigt, ob Domain- und API-Entscheidungen sich unter realer Abfragenutzung wie erwartet verhalten. Sie ist die Ebene, auf der Dein Modell von Design zu Ausführung geht — und auf der Du Probleme erkennen kannst, bevor Deine Konsumenten es tun.

Runtime-Zweck

Die Runtime beantwortet praktische Fragen früh in Deinem Entwicklungsprozess:

• Sind Feldstrukturen vorhersagbar und konsistent?
• Sind Relationsauflösungen kohärent und korrekt verschachtelt?
• Halten Paginierungs- und Sortierungsannahmen unter echten Daten stand?
• Stimmen Filterausdrücke mit der korrekten Teilmenge von Datensätzen überein?
• Werden Null-Werte so behandelt, wie Deine Konsumenten es erwarten?

Indem Du diese Verhaltensweisen während der Modellierung validierst — nicht nach der Implementierung — eliminierst Du eine ganze Kategorie von Integrationsfehlern.

rt-01-query-playgroundMissing

Runtime-Abfragepanel für Live-Verhaltenstests.

Wie die Mock-Runtime funktioniert

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

1. GraphQL-Request-Parser

Der eingehende Abfragestring wird in einen abstrakten Syntaxbaum (AST) geparst. Diese Stufe validiert die Abfragesyntax und extrahiert die angeforderten Felder, Argumente und verschachtelten Auswahlen.

2. Query-Planner

Der AST wird zusammen mit Deinen Modell-Metadaten (Entitätsdefinitionen, Attribut-Flags, Relationskonfigurationen) analysiert, um einen Ausführungsplan zu erstellen. Der Planner bestimmt:

• Welche MongoDB-Sammlungen abgefragt werden
• Welche Felder projiziert werden
• Welche Filter- und Sortieroperationen angewendet werden
• Welche Relationen aufgelöst werden müssen

3. MongoDB-Query-Builder

Der Ausführungsplan wird in eine MongoDB-Aggregationspipeline übersetzt. Da MongoDB Daten in flachen (denormalisierten) Sammlungen speichert, simuliert der Query-Builder relationale Strukturen:

• Lookup-Stufen stellen verwandte Daten über Sammlungen hinweg zusammen
• Match-Stufen wenden Filterausdrücke an
• Sort-Stufen ordnen Ergebnisse nach den angeforderten Feldern
• Skip- und Limit-Stufen handhaben die Paginierung

4. Result-Assembler

Die rohen MongoDB-Ergebnisse werden umgeformt, um der erwarteten GraphQL-Antwortstruktur zu entsprechen. Verschachtelte Relationen werden in die korrekte Eltern-Kind-Hierarchie zusammengestellt, und Feldnamen werden ihren GraphQL-Entsprechungen zugeordnet.

Diese Pipeline läuft bei jeder Abfrage. Was Du in der Vorschau siehst, ist genau das, was externe Konsumenten vom selben Endpunkt erhalten.

rt-01b-runtime-pipelineMissing

Vierstufige Runtime-Pipeline: Parse → Plan → Build → Assemble.

Abfragebeispiele

Alle Abfragen gehen an denselben Endpunkt:

POST /mock/{slug}/graphql

Listenabfrage

Eine paginierte Sammlung von Datensätzen abrufen:

query {
  products(offset: 0, limit: 20) {
    id
    name
    price
    category {
      id
      name
    }
  }
}

Detailabfrage

Einen einzelnen Datensatz anhand seines Bezeichners abrufen:

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

Abfrage mit Filterung

Filterausdrücke anwenden, um Ergebnisse einzugrenzen:

query {
  products(
    filter: {
      filterGroup: {
        operator: AND
        items: [
          { attribute: "price", operator: GE, value: "10" }
          { attribute: "price", operator: LE, value: "50" }
        ]
      }
    }
    limit: 10
  ) {
    id
    name
    price
  }
}

Abfrage mit Sortierung

Ergebnisse nach einem sortierbaren Feld ordnen:

query {
  products(
    sort: { field: "price", direction: DESC }
    limit: 10
  ) {
    id
    name
    price
  }
}

Abfrage mit verschachtelten Relationen

Relationen durchlaufen, um verwandte Daten einzubeziehen:

query {
  customers(limit: 5) {
    id
    firstName
    lastName
    orders {
      id
      totalAmount
      createdAt
      items {
        id
        productName
        quantity
      }
    }
  }
}

Filterung im Detail

Das Filtersystem unterstützt typsichere, kombinierbare Ausdrücke, die mit boolescher Logik kombiniert werden können.

Verfügbare Operatoren

Operator	Beschreibung	Funktioniert mit
EQ	Gleich	Alle Typen
NE	Ungleich	Alle Typen
LT	Kleiner als	Zahlen, Datumsangaben
GT	Größer als	Zahlen, Datumsangaben
LE	Kleiner oder gleich	Zahlen, Datumsangaben
GE	Größer oder gleich	Zahlen, Datumsangaben
LIKE	Enthält Teilstring	Strings
IS_NULL	Feld ist null	Alle Typen
IS_NOT_NULL	Feld ist nicht null	Alle Typen

Filter kombinieren

Filter verwenden boolesche Algebra mit AND- und OR-Operatoren. Filtergruppen können für komplexe Ausdrücke verschachtelt werden:

filter: {
  filterGroup: {
    operator: OR
    groups: [
      {
        operator: AND
        items: [
          { attribute: "status", operator: EQ, value: "active" }
          { attribute: "price", operator: GT, value: "100" }
        ]
      }
      {
        operator: AND
        items: [
          { attribute: "status", operator: EQ, value: "featured" }
        ]
      }
    ]
  }
}

Dieses Beispiel gibt Produkte zurück, die entweder (aktiv UND teuer) ODER hervorgehoben sind.

Filterbare Felder

Nur Attribute, die im Modell als filterable: true markiert sind, können in Filterausdrücken verwendet werden. Der Versuch, nach einem nicht filterbaren Feld zu filtern, hat keine Wirkung. Konfiguriere Filterbar-Flags im Workspace-Tabelleneditor.

Paginierung

Mockomat verwendet Offset-basierte Paginierung:

Parameter	Beschreibung	Standard
offset	Anzahl der zu überspringenden Elemente	0
limit	Anzahl der zurückzugebenden Elemente	20

Eine typische paginierte Anfrage:

query {
  products(offset: 40, limit: 20) {
    id
    name
    price
  }
}

Dies gibt die Elemente 41–60 zurück. Um die nächste Seite abzurufen, erhöhe den Offset um den Limit-Wert.

Sortierung

Felder, die im Modell als sortable: true markiert sind, können zur Sortierung von Ergebnissen verwendet werden.

Richtung	Bedeutung
ASC	Aufsteigend (A→Z, 0→9, älteste→neueste)
DESC	Absteigend (Z→A, 9→0, neueste→älteste)

Pro Abfrage kann nur ein Sortierfeld angewendet werden. Wenn keine Sortierung angegeben ist, werden Ergebnisse in ihrer natürlichen Speicherreihenfolge zurückgegeben.

Relationsdurchquerung

Eine der leistungsstärksten Funktionen der Runtime ist ihre Fähigkeit, relationale Daten aus flachen MongoDB-Sammlungen zu simulieren.

Wie es funktioniert

MongoDB speichert Daten in denormalisierten Sammlungen — jeder Datensatz ist ein flaches Dokument ohne Foreign-Key-Joins. Die Runtime simuliert relationale Strukturen durch:

1. Lesen der Relationsdefinition aus Deinem Modell (Quellentität, Zielentität, Kardinalität).
2. Erstellen von Lookup-Stufen in der MongoDB-Aggregationspipeline, die verwandte Sammlungen verknüpfen.
3. Zusammenstellen verschachtelter Ergebnisse, die der GraphQL-Antwortstruktur entsprechen.

Das bedeutet, Deine GraphQL-Abfragen verhalten sich, als würden sie gegen eine vollständig relationale Datenbank laufen, obwohl der zugrunde liegende Speicher dokumentbasiert ist.

Was zu validieren ist

Bei der Prüfung der Relationsdurchquerung:

• 1:1-Relationen sollten ein einzelnes verschachteltes Objekt (oder null, wenn keine Übereinstimmung) zurückgeben.
• 1:n-Relationen sollten ein Array verschachtelter Objekte zurückgeben.
• Leere Relationen sollten ein leeres Array [] zurückgeben, nicht null.
• Tief verschachtelte Relationen (z. B. Customer → Order → OrderItem) sollten auf jeder Ebene korrekt aufgelöst werden.

Abfrageverhalten-Checkliste

Validiere für jede Schlüsselentität in Deinem Modell:

• Listenabfrage-Stabilität — gibt dieselbe Abfrage bei wiederholten Aufrufen eine konsistente Struktur zurück?
• Einzelelement-Konsistenz — gibt eine Detailabfrage alle erwarteten Felder zurück?
• Null- und fehlendes-Feld-Verhalten — werden optionale Felder korrekt als null dargestellt?
• Relationsdurchquerung — werden verschachtelte Objekte mit der korrekten Kardinalität aufgelöst?
• Filtergenauigkeit — stimmen Filterausdrücke mit der erwarteten Teilmenge überein?
• Sortierkorrektheit — erzeugt die Sortierung eine vorhersagbare, stabile Reihenfolge?
• Paginierungsgrenzen — erzeugen Offset und Limit saubere Seitenausschnitte ohne Duplikate?

rt-02-filter-sort-paginationMissing

Filter-, Sortier- und Paginierungsverhalten-Validierung.

Runtime-Inspektion und Debugging

Wenn das Verhalten falsch aussieht, inspiziere in dieser Reihenfolge:

1. Tabellen- und Attributdefinitionen prüfen

Die häufigste Ursache für unerwartetes Verhalten ist ein falsch konfiguriertes Attribut:

• Ist der Feldtyp korrekt? (Ein als string gespeicherter Preis wird nicht numerisch sortiert.)
• Ist das Feld als sortierbar/filterbar/durchsuchbar markiert?
• Hat das Feld eine konfigurierte Zuordnung?

2. Endpunkt- und Abfrage-Metadaten prüfen

Überprüfe, dass die Abfrage in der API-Design-Ansicht korrekt konfiguriert ist:

• Ist die Abfrage aktiviert?
• Sind Abfragename und Parameter korrekt?
• Ist die Paginierungskonfiguration angemessen?

3. Quellzuordnungsstatus prüfen

Wenn Felder null oder unerwartete Werte zurückgeben:

• Ist der Zuordnungstyp korrekt (OFF_FIELD, FAKE, CONST)?
• Enthält bei OFF_FIELD-Zuordnungen der Quelldatensatz die erwarteten Daten?
• Ist bei FAKE-Zuordnungen der Faker-Generator für den richtigen Datentyp konfiguriert?

4. Relationsrichtlinien prüfen

Wenn verschachtelte Daten fehlen oder falsch sind:

• Ist die Relationsrichtung korrekt (Quelle → Ziel)?
• Stimmt die Kardinalität (1:1 vs 1:n)?
• Existiert die Zielentität und hat zugeordnete Daten?
• Sind die Verknüpfungsspalten korrekt angegeben?

Häufige Probleme und Lösungen

Symptom	Wahrscheinliche Ursache	Lösung
Leere Antwort	Keine Daten für diese Sammlung importiert	Prüfen, ob der Datenimport abgeschlossen ist
Felder geben null zurück	Keine Zuordnung konfiguriert	OFF_FIELD-, FAKE- oder CONST-Zuordnung hinzufügen
Verschachtelte Relation leer	Relation falsch konfiguriert	Richtung, Zielentität und Verknüpfungsspalten überprüfen
Sortierung funktioniert nicht	Feld nicht als sortierbar markiert	Sortierbar-Flag im Tabelleneditor aktivieren
Filter gibt alles zurück	Feld nicht als filterbar markiert	Filterbar-Flag im Tabelleneditor aktivieren
Falsche Datentypen	Zuordnungstyp-Abweichung	Prüfen, ob die Zuordnung den erwarteten Typ erzeugt
Paginierung überspringt Elemente	Offset-Berechnungsfehler	Prüfen, ob Offset-Inkremente dem Limit-Wert entsprechen

rt-03-runtime-inspectionMissing

Runtime-Inspektionsfluss und Debug-Prüfpunkte.

Validierung vor dem Export

Die Runtime sollte die Bereitschaft bestätigen, bevor Du zur Backend-Code-Generierung übergehst. Ein Modell, das die Runtime-Validierung besteht, erzeugt mit deutlich höherer Wahrscheinlichkeit ein sauberes, funktionales generiertes Backend.

Bereitschaftskriterien

Bestätige vor dem Export, dass:

• Pflichtfelder stabil sind — alle Pflichtattribute konsistente, nicht-null Werte haben.
• Die Operations-Oberfläche beabsichtigt ist — nur die Abfragen, die Du exponieren möchtest, aktiviert sind.
• Relationsverhalten erklärbar ist — jede verschachtelte Abfrage korrekt aufgelöst wird und die Kardinalität Deinen Geschäftsregeln entspricht.
• Filter- und Sortierverhalten vorhersagbar ist — Konsumenten sich darauf verlassen können, dass diese Operationen wie dokumentiert funktionieren.
• Keine ungelösten Hinweise — die Vorschau keine Warnungen über nicht zugeordnete Attribute oder fehlende Konfiguration zeigt.

Vor-Export-Validierungs-Workflow

1. Listenabfragen für jede Entität ausführen — Struktur und Datenqualität prüfen.
2. Detailabfragen für Schlüsselentitäten ausführen — Feldvollständigkeit prüfen.
3. Alle konfigurierten Filter testen — korrekte Teilmengenbildung verifizieren.
4. Sortierung auf jedem sortierbaren Feld testen — Reihenfolge verifizieren.
5. Paginierungsgrenzen testen — saubere Seitenübergänge verifizieren.
6. Verschachtelte Relationsabfragen testen — korrekte Zusammenstellung auf jeder Ebene verifizieren.

rt-04-runtime-validationMissing

Vor-Export Runtime-Validierungsübersicht.

Integrator-Tipp

Developer / Integrator

Verwende die Runtime-Validierung als Vertragsprüfung, bevor Du Frontend- oder nachgelagerte Konsumenten integrierst. Der Runtime-Endpunkt liefert dieselben Daten an Vorschau und externe Konsumenten, sodass das, was Du im Workspace validierst, genau das ist, was Deine Anwendung empfängt. Dies reduziert den Integrations-Aufwand erheblich.

Enterprise-Runtime-Erwartungen

Enterprise User

Enterprise-Teams sollten die Runtime-Validierung als formales Quality Gate behandeln. Definiere Validierungskriterien pro Entität (Pflichtfelder, Relationstiefe, Filterabdeckung) und integriere Runtime-Prüfungen in Deinen Review-Prozess, bevor Modelle für den Produktionseinsatz freigegeben werden.