TestphaseDiese Umgebung befindet sich im Pre-Launch-Test — alle Daten werden zum Start zurückgesetzt.
Skip to content

Glossar ​

Eine umfassende Referenz der Begriffe, Konzepte und technischen Fachbegriffe, die in der gesamten Mockomat-Dokumentation verwendet werden. Begriffe sind nach Kategorie gruppiert und innerhalb jeder Gruppe alphabetisch sortiert.


Plattform & Produkt ​

Blueprint Ein fertiges Mockomat-Projekt für eine gängige Domain (Benutzer & Profile, E-Commerce & Online-Shop, Autos & Fahrzeuge, Immobilien, Möbel & Einrichtung, Essen & Restaurants). Blueprints können in einen Workspace geklont und angepasst werden. Siehe Blueprints.

Domain-Modell Das semantische Fundament eines Projekts. Definiert Entitäten, Attribute und Relationen, die Struktur und Bedeutung Deiner Daten beschreiben, bevor API- oder Implementierungsdetails festgelegt werden.

Domain-Ausschnitt Eine kleine, zusammenhängende Teilmenge Deines Geschäftsmodells — typischerweise ein oder zwei verwandte Entitäten, die als Ausgangspunkt für die Modellierung dienen.

Mockomat Eine mandantenfähige SaaS-Plattform für Domain-Modellierung, Mock-API-Simulation und Backend-Code-Generierung. Nutzer definieren Schemas visuell, ordnen Daten zu und erhalten sofort live GraphQL-APIs.

Projekt Eine Mock-API-Definition: ein Domain-Modell, seine Datenzuordnungen und seine API-Konfiguration. Jedes Projekt hat einen eindeutigen Slug und einen eigenen Mock-API-Endpunkt.

Workspace Eine Gruppe von Projekten in Deinem Konto. Jedes Konto hat einen Workspace; ab Professional kannst Du weitere anlegen. Der Abschnitt Workspace dieser Dokumentation behandelt Modellierungsboard, Tabelleneditor, API-Design-Ansicht und Runtime-Vorschau.


Modellierung ​

Attribut Ein Feld einer Tabelle. Jedes Attribut hat einen Namen, einen Typ (z. B. String, Integer, Float, Boolean, Date, JSON, Enum), eine Datenzuordnung und Flags wie Pflichtfeld und Durchsuchbar.

Kardinalität Die quantitative Beziehung zwischen Entitäten: Eins-zu-Eins (1:1), Eins-zu-Viele (1:n) oder Viele-zu-Viele (m:n).

Entität / Tabelle Ein zentrales Geschäftskonzept, das im Modell repräsentiert wird (z. B. Customer, Order, Invoice). Visualisiert als Tabellenkarte auf dem Modellierungsboard.

Filterbar Ein Attribut-Flag, das mit dem Modell gespeichert wird. Die Mock-Runtime liest es nicht: Gefiltert wird über die Parameter einer Operation (siehe API Design (Englisch)).

Hinweis Eine Meldung in der Runtime-Vorschau, die erklärt, warum eine Tabelle keine Daten zeigt oder was als Nächstes zu konfigurieren ist — zum Beispiel, dass eine Tabelle keinen importierten Daten zugeordnet ist.

Modellierungsboard Die visuelle Leinwand im Workspace, auf der Entitäten erstellt, positioniert und über Drag-and-Drop-Interaktion verbunden werden.

Namenskonvention Standardisierte Muster: PascalCase Singular für Entitäten (z. B. Customer), camelCase für Attribute (z. B. firstName).

Relation Eine Verbindung zwischen zwei Entitäten, die definiert, wie Daten zwischen ihnen fließen. Hat eine Richtung (Quelle → Ziel) und Kardinalität (1:1, 1:n, m:n).

Pflichtfeld Ein Attribut-Flag, das angibt, dass das Feld einen Wert haben muss. Der OpenAPI-Export führt es als erforderliche Eigenschaft.

Durchsuchbar Ein Attribut-Flag, das das Feld in die von Groß- und Kleinschreibung unabhängige searchTerm-Suche von Listenoperationen einbezieht.

Sortierbar Ein Attribut-Flag, das mit dem Modell gespeichert und für die Listenspalten des Code-Exports verwendet wird. Die Mock-Runtime liest es nicht: sortField akzeptiert jedes Attribut, das an eine Datenspalte gebunden ist.

Tabellenkarte Die visuelle Darstellung einer Entität auf dem Modellierungsboard, die den Tabellennamen, Spalten, Relationsindikatoren und Aktionsschaltflächen zeigt.

Tabelleneditor Das Konfigurationspanel, das sich beim Auswählen einer Tabelle auf dem Modellierungsboard öffnet und detaillierte Attribut- und Relationseinrichtung bietet.


Datenquellen & Zuordnung ​

COMPUTED Ein Zuordnungstyp, der einen Ausdruck über andere Felder desselben Datensatzes speichert. 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.

CONSTANT Ein Zuordnungstyp, der einen festen Wert an einem Attribut festlegt (z. B. "active" für ein Statusfeld); die Runtime liefert ihn in jeder Zeile, in Zeilen importierter Daten ebenso wie in Zeilen, die aus Wertepools zusammengesetzt werden.

Datenzuordnung Die Konfiguration, die ein Entitätsattribut mit einer Datenquelle verknüpft und bestimmt, welche Werte das Feld zur Runtime zurückgibt.

Datenobjekt Eine Spalte einer Tabelle im Datenpool von Mockomat, die der Zuordnungsbereich anbietet, wenn Du ein Attribut mit einer SOURCE-Zuordnung bindest.

Datensatz Ein Datenbestand, den Mockomat in seinen Datenpool importiert — offene Daten, wo es eine geprüfte Quelle gibt, generierte Beispieldaten für die Blueprints; Attribute lesen seine Spalten über SOURCE-Zuordnungen.

SOURCE (Datenquelle) Ein Zuordnungstyp, der ein Attribut an eine Spalte der importierten Datensätze im Datenpool von Mockomat bindet; die Runtime liefert die importierten Zeilen und erfindet nie Werte.

Wertepool Eine Tabelle kontextfreier Werte (Vornamen, Straßen), aus denen andere Tabellen ihre Zeilen zusammensetzen — stimmige Kombinationen, nie erfundene Werte.


API & GraphQL ​

API-Vertrag Die formale Spezifikation von Abfragenamen, Feldstrukturen und Operationsverfügbarkeit, auf die sich externe Konsumenten verlassen.

API-Design-Ansicht Ein Workspace-Bereich, in dem Nutzer steuern, welche GraphQL-Operationen exponiert werden und wie Abfragen benannt sind.

Code-First GraphQL Der von Mockomat verwendete Ansatz, bei dem GraphQL-Schemas aus Modelldefinitionen und Dekoratoren generiert werden, anstatt sie manuell als SDL-Dateien zu schreiben.

Detailabfrage Eine GraphQL-Abfrage, die einen einzelnen Datensatz anhand seines Bezeichners zurückgibt (z. B. product(id: "abc-123")).

Dynamische Schemagenerierung Der Prozess, bei dem Mockomat ein vollständig typisiertes GraphQL-Schema im laufenden Betrieb aus den Modelldefinitionen eines Projekts generiert.

Endpunkt Der URL-Pfad, unter dem Konsumenten eine Mock-API abfragen: POST /mock/{slug}/graphql.

Filterausdruck Ein Scope-Filter oder Operationsparameter, der Abfrageergebnisse eingrenzt. Alle Bedingungen einer Operation werden mit AND verknüpft.

Filteroperator Ein Vergleich, den Parameter und Scope-Filter verwenden: eq, neq, gt, gte, lt, lte, in, like; Scope-Filter zusätzlich notIn, isNull, isNotNull.

GraphQL Die Abfragesprache und das API-Design-Muster, das von Mockomat sowohl für die Management-API als auch für Mock-Runtime-Endpunkte verwendet wird.

Listenabfrage Eine GraphQL-Abfrage, die eine paginierte Sammlung von Datensätzen mit optionaler Filterung und Sortierung zurückgibt (z. B. products(page: 1, pageSize: 20) { items { … } total }).

Seitenbasierte Paginierung Die von Mockomat verwendete Paginierungsmethode: page (Seitennummer, ab 1) + pageSize (Datensätze pro Seite, höchstens 100).

Operations-Exposition Die Konfiguration, welche GraphQL-Operationen (Liste, Detail) für jede Entität verfügbar sind.

Abfragebenennung Die benutzerdefinierte Benennung von GraphQL-Einstiegspunkten — Listenabfragen standardmäßig im Plural (z. B. products), Detailabfragen im Singular (z. B. product).

Slug / Projekt-Slug Ein URL-sicherer Bezeichner für ein Projekt, der im API-Endpunktpfad verwendet wird (z. B. customer-portal → /mock/customer-portal/graphql).


Runtime ​

Aggregationspipeline MongoDBs mehrstufiges Datenverarbeitungs-Framework, das vom Runtime-Query-Builder verwendet wird, um Abfragen, Filter, Sortierungen und Relations-Lookups auszuführen.

Mock-Runtime / Runtime-Engine Die Kern-Engine, die GraphQL-Abfragen akzeptiert und sie über eine vierstufige Pipeline in MongoDB-Operationen übersetzt: Parse → Plan → Build → Assemble.

MongoDB-Query-Builder Die dritte Stufe der Runtime-Pipeline, die einen Ausführungsplan in eine MongoDB-Aggregationspipeline übersetzt.

Vorschau Die In-App-Runtime-Oberfläche, in der Nutzer ihr Modell mit Live-Abfragen testen und Antwortdaten neben Bereitschaftshinweisen inspizieren.

Query-Planner Die zweite Stufe der Runtime-Pipeline, die eine geparste Abfrage zusammen mit Modell-Metadaten analysiert, um einen Ausführungsplan zu erstellen.

Relationsdurchquerung Die Fähigkeit der Runtime, relationale Daten aus flachen MongoDB-Sammlungen zu simulieren, indem Lookup-Stufen in der Aggregationspipeline erstellt werden.

Request-Parser / GraphQL-Request-Parser Die erste Stufe der Runtime-Pipeline, die einen eingehenden Abfragestring in einen abstrakten Syntaxbaum (AST) parst.

Result-Assembler Die vierte Stufe der Runtime-Pipeline, die MongoDB-Ergebnisse in die erwartete GraphQL-Antwortstruktur umformt.

Runtime-Validierung Der Prozess der Bestätigung, dass Domain- und API-Entscheidungen eines Modells sich unter echter Abfrageausführung korrekt verhalten.

Ansichten Verschiedene Perspektiven auf dasselbe Modell — Board-Ansicht, Tabellendetail-Ansicht, API-Design-Ansicht, Runtime-Vorschau — navigierbar über Querlinks.


Export & Code-Generierung ​

Code-Generierung / Codegen Der automatisierte Prozess der Erstellung eines funktionierenden Backend-Projekts aus einem Mockomat-Domain-Modell.

DTO (Data Transfer Object) Die Eingabeklassen für Anlegen und Aktualisieren eines generierten Backends, ein Paar pro Tabelle, mit class-validator-Dekoratoren.

Export Das Feature, das ein Projekt als OpenAPI-Spezifikation oder, ab Professional, als generiertes NestJS-Code-Paket ausgibt. Der generierte Code gehört dem Nutzer. Siehe Export.

Generiertes Backend Das NestJS-Projekt in einem Code-Paket — ein Modul pro Tabelle mit Entität, Resolver, Service und Eingabetypen, dazu Authentifizierung und Konfiguration.

NestJS Das Node.js-Framework generierter Backends. Generierter Code folgt Standard-NestJS-Konventionen.

Resolver Die GraphQL-API-Schicht im generierten NestJS-Code: die Abfragen und Mutationen einer Tabelle.

TypeORM Die ORM-Bibliothek (Object-Relational Mapping) generierter Backends; generierte Entitäten zielen auf MySQL / MariaDB.


Authentifizierung & Sicherheit ​

Actor-Token Ein optionales, zeitlich begrenztes Token, das die Konsumenten eines API-Schlüssels für das Parallelitäts-Tracking unterscheidet. Wird im X-Actor-Token-Header gesendet.

API-Schlüssel Ein pro Projekt ausgestellter Berechtigungsnachweis, mit dem sich externe Konsumenten gegenüber der Mock-API dieses Projekts authentifizieren — Pflicht für jedes Projekt eines Kontos. Wird im Authorization: Bearer-Header (oder X-API-Key) gesendet; API-Schlüssel gibt es ab dem Professional-Tarif.

Gleichzeitige Sitzung Die gleichzeitige Anmeldung auf mehr als einem Gerät oder Browser. Bei Starter kann ein Konto nur an einer Stelle gleichzeitig angemeldet sein: Eine Anmeldung an anderer Stelle beendet die frühere Sitzung. Bei Professional, Business und Enterprise kann der Eigentümer des Kontos auf mehreren Geräten gleichzeitig angemeldet bleiben. Eingeladene Mitglieder erhalten das nicht über das Konto, dem sie beitreten: Sie können nur an einer Stelle gleichzeitig angemeldet sein, es sei denn, sie besitzen selbst ein Konto, dessen Tarif mehr erlaubt.

JWT (JSON Web Token) Ein Token-Format für zustandslose Authentifizierung in der Mockomat-Management-API.

Privater Endpunkt Ein Mock-API-Endpunkt, der API-Schlüssel-Authentifizierung erfordert — der Endpunkt jedes Projekts eines Kontos.

Öffentlicher Endpunkt Ein Mock-API-Endpunkt, der ohne API-Schlüssel erreichbar ist. Nur Gastprojekte haben einen: Er öffnet sich mit dem Freigabe-Token des Projekts und ist pro IP ratenbegrenzt.

Ratenbegrenzung Die Grenzen für Mock-API-Anfragen: eine Ratenbegrenzung pro IP und das Anfragekontingent Deines Tarifs (pro Tag oder pro Kalendermonat). Beide antworten bei Überschreitung mit HTTP 429 (Too Many Requests); die IP-Begrenzung sendet zusätzlich einen Retry-After-Header.

Sitzung Eine Anmeldung auf einem Gerät oder Browser. Eine Sitzung endet, wenn Du Dich abmeldest, nach einer Zeit ohne Aktivität oder wenn sich Dein Passwort ändert.


Tarife & Zugang ​

Business (Tarif) Ein bezahlter, monatlich abgerechneter Tarif, der Professional um größere Teams, mehr Verwalter und Endpunkt-Analytik erweitert.

Enterprise (Tarif) Ein mit unserem Vertrieb vereinbarter Tarif (Preis auf Anfrage, kein Self-Service-Checkout); seine Limits — Projekte, Anfragen, Teamgröße — werden pro Vertrag angepasst.

Guest (Tarif) Der sofortige, loginfreie Tarif mit einem temporären sitzungsbasierten Projekt, dessen Endpunkt sich mit seinem Freigabe-Token öffnet. Die Arbeit bleibt eine begrenzte Zeit im Browser; bei der Registrierung bietet die App an, sie in Dein Konto zu übernehmen.

Professional (Tarif) Ein bezahlter, monatlich abgerechneter Tarif mit privaten Endpunkten, API-Schlüsseln, rollenbasiertem Teamzugriff und einem monatlichen Anfragekontingent.

Starter (Tarif) Der kostenlose Tarif mit Kontoregistrierung, mit dauerhaften Projekten und einem täglichen Anfragekontingent in der App; Aufrufe der Mock-API aus eigenem Code brauchen API-Schlüssel (ab Professional).

Die aktuellen Limits je Tarif stehen auf der Preisseite und unter Konto und Tarife.


Team & Governance ​

Bearbeiter (editor) Eine Workspace-Rolle, die das Modell baut, Projekte anlegt, API-Schlüssel verwaltet und den Code-Export ausführt. Umfasst alles, was ein Reporter kann.

Domain-Ownership Zugewiesene Verantwortung für einen bestimmten Geschäftsdomänenbereich und dessen Modelldefinitionen innerhalb des Teams.

Eigentümer Die Person, die das Konto angelegt hat. Der Eigentümer hat eine Verwalter-Mitgliedschaft, verwaltet die Abrechnung und kann nicht aus dem Konto entfernt werden.

Governance Richtlinien und Kontrollen zur Sicherstellung von Konsistenz und Qualität bei teamübergreifenden Modellierungsbemühungen — Namenskonventionen, Review-Gates und Validierungskriterien.

Mandant Eine isolierte organisatorische Grenze mit eigenen Mitgliedern, Projekten, API-Schlüsseln, eigener Konfiguration und eigenen Tarif-Limits. Mock-Daten stammen aus dem gemeinsamen, schreibgeschützten Pool.

Mandantenfähigkeit Die Architektur, die Projekte, Modelle, Mitglieder und Konfiguration jedes Kontos durch kontobezogenen Zugriff voneinander trennt. Mock-Daten stammen aus dem gemeinsamen, schreibgeschützten Pool.

Mandanten-Team Die Mitglieder Deines Kontos und ihre Workspace-Rollen, verwaltet unter Konto → Mandant → Mandanten-Team. Siehe Team & Roles (Englisch).

Nur Lesen (readonly) Eine Workspace-Rolle, die Projekte, das Modell und die Datenvorschau sieht und Board-Notizen liest.

Reporter (reporter) Eine Workspace-Rolle, die zu allem, was Nur Lesen kann, Board-Notizen und Kommentare hinzufügt.

Review-Gate Ein Checkpoint, an dem Modell-, API- oder Export-Änderungen validiert werden, bevor Konsumenten sich darauf verlassen — z. B. Runtime-Validierung vor einem Export.

Verwalter (maintainer) Eine Workspace-Rolle, die zu allem, was ein Bearbeiter kann, das Löschen von Projekten, die Verwaltung von Mitgliedern und ihrem Projektzugriff sowie die Verwaltung von Workspaces hinzufügt. Verwalter sehen jedes Projekt des Kontos.


Infrastruktur & Deployment ​

Docker Containerisierungstechnologie. Ein Code-Paket enthält eine Docker-Compose-Datei, die MySQL und Redis für das generierte Backend startet, aber kein Dockerfile für das Backend selbst; füge eines für Deine Zielplattform hinzu, um es in einem Container zu betreiben (siehe Export).