Workspace

Der Workspace ist der Ort, an dem Domain-, API- und Runtime-Entscheidungen in einem operativen Fluss verbunden bleiben. Er ist die zentrale Umgebung, in der Du Dein Mock-API-Projekt erstellen, konfigurieren, validieren und iterieren.

Diese Seite führt durch jeden wichtigen Bereich des Workspace und erklärt, was jeder Bereich tut, wie Du ihn effektiv nutzt und worauf Du achten solltest.

Workspace-Bereiche

Der Workspace ist in verschiedene Bereiche gegliedert, die jeweils auf einen bestimmten Teil des Modellierungs- und API-Design-Workflows fokussiert sind. Du kannst jederzeit zwischen diesen Bereichen wechseln — Änderungen in einem Bereich werden sofort in den anderen reflektiert.

1. Projektkontext und Navigation

Der übergeordnete Workspace-Kontext steuert, an welchem Projekt Du arbeitest und wie Du zwischen verschiedenen Ansichten navigierst.

Was Du tun kannst

• Aktive Projekte wechseln — wenn Du mehrere Projekte hast, kannst Du mit dem Projektwahlschalter den Kontext wechseln, ohne Deinen Platz zu verlieren.
• Modellierungskontext stabil halten — der Workspace merkt sich, welche Tabelle, Ansicht oder welches Konfigurationspanel Du geöffnet hattest.
• Zwischen Ansichten wechseln — navigiere zwischen Modellierungsboard, Tabelleneditor, API-Design und Runtime-Vorschau.

Projekteinstellungen

Jedes Projekt hat einen eindeutigen Slug, der die API-Endpunkt-URL bestimmt; Aufrufe aus Deinem eigenen Code tragen einen API-Schlüssel des Projekts (siehe Integratoren):

POST /mock/{slug}/graphql
Authorization: Bearer mck_your_api_key

Der Slug wird automatisch aus Deinem Projektnamen generiert, kann aber angepasst werden. Halte Slugs kurz, kleingeschrieben und mit Bindestrichen versehen (z. B. customer-portal, ecommerce-demo).

ws-01-project-switcherMissing

Projektkontextleiste und Ansichtswechsel.

2. Modellierungsboard

Das Modellierungsboard ist der strukturelle Designbereich — eine visuelle Leinwand, auf der Du Deine Domain-Entitäten und deren Verbindungen erstellen und anordnen.

Arbeiten mit Tabellen

Das Board zeigt jede Entität als Tabellenkarte an. Du kannst:

• Neue Tabellen erstellen — Entitäten hinzufügen, die Geschäftskonzepte repräsentieren (z. B. Product, Customer, Order).
• Tabellen positionieren — Tabellenkarten per Drag-and-Drop anordnen. Verwandte Entitäten für visuelle Klarheit gruppieren.
• Tabelleneigenschaften bearbeiten — Tabellen umbenennen, Anzeige-Optionen konfigurieren und Metadaten verwalten.
• Tabellen löschen — nicht mehr benötigte Entitäten entfernen.

Visuelle Beziehungslinien

Relationen zwischen Tabellen werden als visuelle Linien dargestellt, die die verwandten Entitäten verbinden. Die Linien zeigen:

• Richtung — welche Entität die Relation besitzt (Pfeilrichtung).
• Kardinalität — den Relationstyp (1:1, 1:n, m:n) durch Linienannotationen dargestellt.
• Verbindungspunkte — welche Spalten an der Relation beteiligt sind.

Diese visuelle Darstellung erleichtert die Überprüfung Deiner Domain-Struktur auf einen Blick und das Erkennen fehlender oder falscher Relationen.

Board-Steuerung

• Zoom und Schwenken — große Boards mit Mausrad-Zoom und Ziehen-zum-Schwenken navigieren.
• Rastereinrastung — optionale Rasterausrichtung hält Tabellen ordentlich positioniert.
• Auto-Layout — Tabellen automatisch für optimale Lesbarkeit anordnen.

ws-02-modelling-boardMissing

Modellierungsboard mit verbundenen Domain-Entitäten.

Board-Einschränkungen

Free User

Jeder Tarif, Gast-Sitzungen eingeschlossen, hat vollen Zugang zum Modellierungsboard. Wie viele Tabellen pro Projekt und Attribute pro Tabelle möglich sind, hängt von Deinem Tarif ab — siehe [Konto und Tarife](/de/account/).

3. Tabellen- und Attributkonfiguration

Wenn Du eine Tabelle auf dem Modellierungsboard auswählst, öffnet sich das Tabelleneditor-Panel mit detaillierten Konfigurationsoptionen für die Entität und ihre Attribute.

Tabelleneigenschaften

Jede Tabelle sollte haben:

• Einen klaren Namen — verwende Singularnomen, die zu Deiner Geschäftssprache passen (Invoice, nicht invoices_table).
• Eine Beschreibung — optional, aber hilfreich für Teamkommunikation und Dokumentation.

Attributkonfiguration

Für jedes Attribut (Spalte) konfigurierst Du:

Eigenschaft	Beschreibung	Auswirkung
Name	Der Feldbezeichner	Wird zum GraphQL-Feldnamen
Typ	z. B. String, Integer, Float, Boolean, Date, JSON, Enum	Typ in den Exporten; wähle den Typ der gebundenen Daten
Pflichtfeld	Ob das Feld einen Wert haben muss	Im OpenAPI-Export als erforderlich markiert
Sortierbar	Mit dem Modell gespeichert	Markiert im Code-Export sortierbare Listenspalten; die Mock-API sortiert nach jedem zugeordneten Attribut (sortField)
Durchsuchbar	Ob das Feld an der Suche teilnimmt	In der searchTerm-Suche von Listenoperationen enthalten
Filterbar	Mit dem Modell gespeichert	Keine Wirkung auf die Mock-API — gefiltert wird über Operationsparameter
Zuordnung	Datenquelle: SOURCE oder CONSTANT; COMPUTED nur bei Attributen, die es bereits haben (wird nicht ausgewertet)	Bestimmt, welche Daten das Feld zurückgibt

Namenskonventionen

Konsistente Benennung macht Dein Modell lesbar und Deinen generierten Code vorhersagbar:

• Attribute — verwendest Du camelCase (z. B. firstName, totalAmount, isActive)
• Tabellen — verwendest Du PascalCase Singular (z. B. Customer, OrderItem)
• Abkürzungen vermeiden — description ist besser als desc, quantity ist besser als qty

Daten zuordnen

Im Zuordnungsbereich (Mappings) des Boards bindest Du zuerst die Tabelle an eine Tabelle des Datenpools (Kanonische Tabelle) — Vorschlagen schlägt eine passende vor, oder Du durchsuchst alle Tabellen selbst. Danach bindest Du ihre Attribute an deren Spalten (SOURCE); sichere übernehmen übernimmt alle sicheren Vorschläge auf einmal. Attribute, die leer bleiben sollen, markierst Du mit Keine Zuordnung nötig. Details: Data Sources & Field Mapping (Englisch).

ws-03-table-editorMissing

Tabelleneditor mit Attributkonfigurationspanel.

ws-03b-data-object-selectorMissing

Datenobjekt-Auswahlpanel mit Suche und Vorschau.

4. Relationsdefinition

Relationen verbinden Deine Entitäten und definieren, wie Daten zwischen ihnen fließen. Relationen richtig zu setzen ist entscheidend — sie bestimmen, wie verschachtelte Abfragen zur Runtime aufgelöst werden.

Relationstypen

Typ	Beispiel	Bedeutung
Eins-zu-Eins (1:1)	User → Profile	Jeder Benutzer hat genau ein Profil
Eins-zu-Viele (1:n)	Customer → Order[]	Jeder Kunde hat mehrere Bestellungen
Viele-zu-Viele (m:n)	Product ↔ Category	Produkte gehören zu mehreren Kategorien und umgekehrt

Qualitäts-Checkliste

Bevor Du eine Relation finalisierst, stelle Dir diese Fragen:

• Besitz oder Referenz? — Stellt diese Relation echten Besitz dar (ein Kunde besitzt seine Bestellungen) oder eine Referenz (eine Bestellung referenziert eine Zahlungsmethode)?
• Richtungsklarheit — Ist offensichtlich, welche Entität Eltern und welche Kind ist?
• Auflösungsverhalten — Sollen bei Abfrage des Elternteils Kinddaten standardmäßig einbezogen werden? Was ist mit der umgekehrten Richtung?
• Kardinalitätskorrektheit — Ist dies wirklich 1:n, oder könnte es in Zukunft m:n sein?

Wie Relationen die Runtime beeinflussen

Zur Runtime bestimmen Relationen, wie die Abfrage-Engine verschachtelte Daten zusammenstellt. Wenn Du fragst ab:

query {
  customers(pageSize: 5) {
    items {
      id
      name
      orders {
        id
        totalAmount
      }
    }
  }
}

Die Runtime verwendet die Relationsdefinition, um die zugehörigen Order-Datensätze für jeden Customer nachzuschlagen. Wenn die Relation falsch konfiguriert ist (falsche Richtung, fehlende Fremdschlüsselreferenz), werden die verschachtelten Daten leer oder falsch sein.

ws-04-relation-editorMissing

Relationseinrichtung und Kardinalitätskonfiguration.

5. API-Design-Integration

Der API-Design-Bereich ermöglicht es Dir zu steuern, wie Dein Domain-Modell als GraphQL-API exponiert wird. Nicht jede Entität oder Operation muss öffentlich sein — die API-Design-Ansicht hilft Dir, nur das zu exponieren, was für die aktuelle Phase sinnvoll ist.

Abfragebenennung

Mockomat generiert Abfragenamen automatisch aus Deinen Entitätsnamen, aber Du kannst sie anpassen:

• Listenabfrage — standardmäßig die Pluralform (z. B. products, customers)
• Detailabfrage — standardmäßig die Singularform (z. B. product, customer)

Wähle Namen, die dazu passen, wie Dein Frontend-Team über die Daten denkt. Der Abfragename wird zum Einstiegspunkt in jeder GraphQL-Anfrage.

Operations-Exposition

Du steuerst, welche Operationen verfügbar sind:

• Listenabfragen aktivieren/deaktivieren — entscheiden, ob Konsumenten Sammlungen abrufen können.
• Detailabfragen aktivieren/deaktivieren — entscheiden, ob Konsumenten einzelne Datensätze abrufen können.
• Standards konfigurieren — Standard-Seitengröße (höchstens 100 Datensätze pro Seite) und Standard-Sortierung festlegen.

Design-Prinzipien

• Schmal anfangen — zuerst weniger Operationen exponieren, dann erweitern, wenn das Modell stabilisiert ist.
• Bewusst benennen — Abfragenamen sind Teil Deines API-Vertrags. Du später zu ändern betrifft alle Konsumenten.
• Vor der Exposition validieren — verwende die Vorschau, um Verhalten zu bestätigen, bevor Du den Endpunkt mit Deinem Team teilst.

ws-05-api-designMissing

API-Design-Ansicht ausgerichtet an Modelltabellen.

6. Vorschau- und Hinweis-Workflow

Die Vorschau sollte Teil jeder Modellierungsiteration sein, nicht ein letzter Schritt. Sie ist die Feedback-Schleife, die Dein Modell ehrlich hält.

Wie die Vorschau funktioniert

Wenn Du die Vorschau öffnest, führt Mockomat folgende Schritte aus:

1. Nutzt den aktuellen Stand Deines Modells, Deiner Zuordnungen und Operationen.
2. Führt die Listenoperation der Tabelle gegen die importierten Daten aus.
3. Zeigt die Daten zusammen mit einem Hinweis, falls etwas fehlt.

Die Vorschau zeigt sowohl die Datenantwort als auch alle Probleme, die Aufmerksamkeit erfordern.

Hinweistypen

Hinweise sind umsetzbare Signale, die Dir helfen, Modellprobleme zu identifizieren und zu beheben:

Hinweis	Bedeutung	Aktion
Keinen importierten Daten zugeordnet	Die Tabelle ist nicht an importierte Daten gebunden; die API liefert keine Zeilen für sie	Tabelle und Attribute im Zuordnungsbereich (Mappings) binden
Keine API-Bindung	Die Ansicht ist an keine Listenoperation gebunden; es werden keine Daten geladen	In den Ansichtseinstellungen eine Listenoperation binden
Kein Identifikationsfeld	Die Ansicht hat kein Identifikationsfeld; ein Zeilenklick öffnet keine Detailansicht	Das Identifikationsfeld in den Ansichtseinstellungen setzen

Iterations-Workflow

Der produktivste Workflow folgt einer engen Schleife:

1. Eine Modelländerung vornehmen — eine Tabelle hinzufügen, ein Attribut ändern, eine Relation erstellen.
2. Vorschau öffnen — eine Abfrage ausführen und die Ergebnisse inspizieren.
3. Hinweise prüfen — alle Warnungen oder Fehler beheben.
4. API-Design aktualisieren — Abfragenamen oder Operations-Exposition bei Bedarf anpassen.
5. Wiederholen — fortfahren, bis das Modell stabil und die Vorschau sauber ist.

Dieser Zyklus sollte Sekunden dauern, nicht Minuten. Je schneller Du iterierst, desto höher die Qualität Deines endgültigen Modells.

ws-06-preview-hintsMissing

Vorschauansicht mit umsetzbaren Bereitschaftshinweisen.

7. Ansichten und Querlink-Navigation

Ansichten bieten verschiedene Perspektiven auf dasselbe zugrunde liegende Modell. Anstatt durch Menüs zu navigieren, kannst Du über Querlinks zwischen verwandten Kontexten wechseln.

Verfügbare Ansichten

• Board-Ansicht — die visuelle Modellierungsleinwand mit Tabellen und Relationen.
• Tabellendetail-Ansicht — fokussierte Ansicht auf eine einzelne Entität mit vollständiger Attributkonfiguration.
• API-Design-Ansicht — Abfrage- und Operationskonfiguration für die ausgewählte Entität.
• Runtime-Vorschau — Live-Abfrageausführung und Antwortinspektion.

Querlink-Navigation

Wenn Du in einer Ansicht arbeitest, sind Links zu verwandten Kontexten inline verfügbar. Zum Beispiel:

• Von einer Tabellendetail-Ansicht kannst Du direkt zur Runtime-Vorschau springen, um die Abfragen dieser Tabelle zu testen.
• Von der Runtime-Vorschau kannst Du zum Tabelleneditor zurückspringen, wenn Du ein Feldproblem bemerkst.
• Von der API-Design-Ansicht kannst Du zum Modellierungsboard springen, um die vollständige Domain-Struktur zu überprüfen.

Dieses Navigationsmodell hält Du im Fluss — Du musst nie „zurück zum Dashboard" gehen, um den Kontext zu wechseln.

ws-07-views-navigationMissing

Querlink-Navigation zwischen Workspace-Ansichten.

Workflow-Tipp für registrierte Nutzer

Registered User

Erstelle kurze Iterationszyklen: Modellaktualisierung → Vorschauprüfung → API-Aktualisierung. Das hält den Fortschritt messbar und vermeidet verzögerte Abweichungsentdeckung. Nutze die Ansichtennavigation, um schnell zwischen verwandten Kontexten zu wechseln.

Workflow-Tipp für Paid-Nutzer

Paid User

Definiere Team-weite Konventionen für Benennung und Relationsmuster. Verwende diese Konventionen projektübergreifend für schnelleres Onboarding und Reviews. Dokumentiere Deine Konventionen in der Projektbeschreibung, damit neue Teammitglieder ihnen sofort folgen können.