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:

POST /mock/{slug}/graphql

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

Free- und Gastnutzer haben vollen Zugang zum Modellierungsboard. Die Board-Komplexität ist nur durch die Anzahl der Projekte begrenzt, die Dein Tarif erlaubt, nicht durch die Anzahl der Tabellen innerhalb eines Projekts.

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	string, number, boolean, date, json	Bestimmt Filteroperatoren und Validierung
Pflichtfeld	Ob das Feld einen Wert haben muss	Beeinflusst GraphQL-Nullabilität
Sortierbar	Ob das Feld Sortieroperationen unterstützt	Aktiviert sort-Parameter in Abfragen
Durchsuchbar	Ob das Feld an der Suche teilnimmt	In Suchabfrageauflösung einbezogen
Filterbar	Ob das Feld Filterausdrücke unterstützt	Aktiviert filter-Parameter in Abfragen
Zuordnung	Datenquelle: OFF_FIELD, FAKE oder CONST	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

Datenobjekt-Auswahl

Bei der Zuordnung eines Attributs zu einem echten Datensatzfeld (OFF_FIELD) öffnet sich ein Seitenpanel mit:

• Suche — Datenobjekte nach Name oder Tag finden
• Tag-Filter — Ergebnisse nach Kategorie eingrenzen
• Beispielvorschau — Beispielwerte vor der Zuordnung ansehen

Dies stellt sicher, dass Du die richtige Datenquelle für jedes Attribut wählst.

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(limit: 5) {
    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.
• Paginierungs-Standards konfigurieren — Standard-Seitengröße und maximale Limits 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. Generiert ein GraphQL-Schema aus Deinem aktuellen Modell.
2. Führt eine Beispielabfrage gegen Deine zugeordneten Daten aus.
3. Gibt die Ergebnisse zusammen mit Bereitschaftshinweisen zurück.

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
Nicht zugeordnetes Attribut	Ein Feld hat keine konfigurierte Datenquelle	OFF_FIELD-, FAKE- oder CONST-Zuordnung zuweisen
Fehlende Endpunkt-Metadaten	Einer Abfrage oder Operation fehlt erforderliche Konfiguration	API-Design-Ansicht öffnen und Setup abschließen
Konfigurationsabweichung	Ein Feld ist als sortierbar markiert, hat aber keinen kompatiblen Datentyp	Attributtyp und Flag-Kombination überprüfen
Relationswarnung	Eine Relationszielentität oder -spalte fehlt	Relationsdefinition im Tabelleneditor prüfen

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.