Modelling Board

The modelling board is the central visual canvas of the Mockomat workspace. It is the primary environment where you create domain entities, arrange them spatially, and define the relationships between them. Every structural decision you make on the board — tables, attributes, relations — propagates directly to GraphQL schema generation, runtime query resolution, and code export.

This page covers every aspect of the board: creating and configuring table cards, spatial layout, navigation controls, relation rendering, drag-to-connect interaction, and the causal chain from board to API.

ws-board-01-overviewMissing

The modelling board with multiple connected domain entities arranged spatially.

Creating Table Cards

A table card represents a single domain entity — a first-class concept in your data model such as Customer, Order, Product, or Invoice. To add a new entity, use the Add Table action in the board toolbar. A new card appears on the canvas at the current viewport center, ready for naming and configuration.

Table Card Anatomy

Each card is divided into distinct visual zones:

Zone	Contents	Purpose
Header	Entity name, icon, color indicator	Identifies the entity at a glance. The color is configurable and helps distinguish entity groups visually.
Attribute list	Field names and type badges	Shows the entity's attributes directly on the card. Types (string, number, boolean, date, json) are indicated by compact badges.
Relation indicators	Small connection markers at card edges	Show where relation lines attach. Hovering reveals the related entity name and cardinality.
Action buttons	Play button, edit, context menu	The play button opens the Modelling Runtime Preview for that table. Edit opens the full attribute configuration panel.

The header area supports a configurable icon and color. Use these to create visual groupings — for example, all financial entities in blue, all user-related entities in green. This is purely a visual aid and does not affect API behavior.

ws-board-02-card-anatomyMissing

Annotated table card showing header, attribute list, relation indicators, and action buttons.

Naming Conventions

Use PascalCase singular nouns for table names: Customer, OrderItem, ProductCategory. Avoid plurals, abbreviations, and underscores. The table name becomes the GraphQL type name, so clarity here pays off downstream.

Editing a Table

Click on a table card to select it. Double-click or use the edit button to open the attribute configuration panel. From there, you can add, remove, and reorder attributes, configure data mappings, and set field-level flags (sortable, searchable, filterable). For full details, see Tables & Attributes.

Deleting a Table

Delete a table card from its context menu. Deletion removes the entity and all its attributes from the model. Any relations that reference the deleted table are also removed. This action requires confirmation and cannot be undone.

Table limits

Free User

Free-tier users can create tables without restriction within a single project. The board imposes no artificial limit on the number of entities — complexity is bounded only by the number of projects your plan allows.

Spatial Layout and Organization

The board is an unbounded two-dimensional canvas. You position table cards by dragging them to the desired location. There are no lanes, grids, or predefined zones — you decide the spatial structure.

Why Spatial Layout Matters

Although the spatial arrangement of table cards has no effect on the generated API, it communicates domain structure to anyone reading the board. Treat the canvas as a living diagram:

• Group related entities together. Place Customer, Address, and ContactInfo near each other. Place Product, Category, and Inventory in a separate cluster.
• Use vertical or horizontal flow to indicate data direction. For example, place parent entities above their children, or source entities to the left of their dependents.
• Leave space between clusters for readability. Dense clusters with overlapping relation lines are harder to interpret than well-spaced arrangements.

Viewport Persistence

The board remembers your viewport state — pan position and zoom level — across sessions. When you return to the board, you see exactly the same view you left. This applies per project: each project stores its own viewport independently.

Drag and Drop

Click and hold a table card header to drag it to a new position. Release to place. While dragging, grid snap (if enabled) constrains the card position to the nearest grid intersection, keeping the layout aligned.

ws-board-03-spatial-layoutMissing

Spatially organized board with entity clusters and clear spacing between domain groups.

Zoom, Pan, and Navigation

Large domain models may contain dozens of entities spread across a wide canvas. The board provides several navigation mechanisms to keep you oriented.

Zoom

Use the mouse wheel to zoom in and out. The zoom centers on the cursor position, so you can zoom into a specific area without losing context. Alternatively, use the zoom controls in the board toolbar: dedicated buttons for zoom in, zoom out, and fit-to-screen.

The fit-to-screen action adjusts the zoom level and pan offset so that all table cards are visible within the current viewport. This is useful when you want to see the full domain model at a glance.

Pan

Click and drag on an empty area of the canvas to pan the viewport. This moves the visible area without affecting any table card positions. Pan works at any zoom level.

Minimap

The minimap is a small overview panel in the corner of the board that shows a scaled-down representation of the entire canvas. Each table card appears as a colored rectangle. The current viewport is shown as a highlighted rectangle.

• Click on the minimap to jump directly to that area of the board.
• The minimap updates in real time as you move or resize table cards.

The minimap is especially valuable for large boards where you need to navigate between distant entity clusters quickly.

Grid Snap

When grid snap is enabled, table cards align to the nearest grid intersection when placed or dragged. This produces a clean, evenly spaced layout without manual pixel adjustments. Grid visibility and snap behavior are configurable in the board settings.

ws-board-04-navigationMissing

Zoom controls, minimap, and grid snap in action on a large board.

Relation Line Rendering

Relations between entities are rendered as SVG lines connecting the related table cards. These lines are the visual representation of your domain's structural connections — they show how entities depend on and reference each other.

ERD Notation

Relation lines use standard Entity-Relationship Diagram (ERD) notation to communicate cardinality:

Cardinality	Notation	Example
One-to-One (1:1)	Single line, single endpoint markers	User — Profile
One-to-Many (1:n)	Single endpoint on parent side, crow's foot on child side	Customer — Order[]
Many-to-Many (m:n)	Crow's foot on both sides	Product — Category

Arrow direction indicates ownership: the arrow points from the owning entity to the referenced entity.

Line Routing

Lines automatically route between connected table cards. When you move a card, its relation lines update in real time to maintain a clear path. The routing algorithm avoids crossing through other cards where possible, though on dense boards some overlap may occur.

Hover Interaction

Hovering over a relation line highlights it and displays a tooltip with the relation metadata: source entity, target entity, cardinality, and linking columns. This provides quick inspection without opening the relation editor.

Hovering over a relation indicator on a card edge highlights all relations connected to that point, making it easy to trace connections visually.

ws-board-05-relation-linesMissing

Relation lines with ERD notation showing cardinality between connected entities.

Drag-to-Connect

Creating a new relation is a direct manipulation gesture: drag from one table card to another.

How It Works

1. Initiate the drag — click and hold on a relation connection point (the small marker at the card edge) or on the card header while holding the relation modifier.
2. Drag to the target — as you drag, a provisional line follows your cursor. The target card highlights when you hover over it, providing visual confirmation.
3. Release on the target card — dropping on a valid target opens the relation configuration dialog.
4. Configure the relation — in the dialog, select the cardinality (1:1, 1:n, m:n), direction, and the linking columns on each side.
5. Confirm — the relation line appears immediately on the board.

Visual Feedback

During the drag, the board provides continuous feedback:

• Provisional line follows the cursor from the source card.
• Valid targets highlight with a distinct border color when hovered.
• Invalid targets (e.g., the source card itself) do not highlight.
• On release, if the cursor is not over a valid target, the drag is cancelled with no side effects.

This interaction model makes relation creation fast and intuitive — no forms or menus required until the final configuration step.

ws-board-06-drag-to-connectMissing

Drag-to-connect interaction with provisional relation line and target highlight.

For full details on relation types, linking columns, and quality considerations, see Relations.

Board Controls and Toolbar

The board toolbar provides global actions that affect the entire canvas:

Control	Action	Description
Add Table	Create a new entity	Places a new table card at the viewport center
Auto-Layout	Automatic arrangement	Repositions all table cards using a force-directed layout algorithm for optimal readability
Fit to Screen	Adjust viewport	Zooms and pans to show all entities within the visible area
Zoom In / Out	Manual zoom	Step-wise zoom adjustment via toolbar buttons
Grid Toggle	Show/hide grid	Toggles grid line visibility on the canvas
Snap Toggle	Enable/disable snap	Controls whether card positions snap to the grid

Auto-Layout

Auto-layout rearranges all table cards on the board to minimize relation line crossings and maximize readability. It respects existing entity groupings where possible but will reposition cards as needed. After auto-layout runs, you can manually adjust individual positions.

Auto-layout is useful when you have added many entities and the board has become cluttered. It provides a clean starting point for further spatial refinement.

ws-board-07-toolbarMissing

Board toolbar with auto-layout, zoom controls, and grid settings.

Causality: Board to Schema to Runtime

The modelling board is the single source of truth for your domain model. Every change you make on the board propagates through a deterministic pipeline:

Board to GraphQL Schema

1. Each table card becomes a GraphQL type. The table name becomes the type name; each attribute becomes a field with the corresponding GraphQL scalar type.
2. Each relation line becomes a nested field on the parent type. A 1:n relation from Customer to Order produces an orders field on the Customer type that resolves to a list of Order objects.
3. Attribute flags (sortable, searchable, filterable) determine which query parameters are available for each field.

Schema to Runtime

The generated schema drives the mock runtime engine. When an API consumer sends a query to POST /mock/{slug}/graphql:

1. The query planner parses the incoming GraphQL query against the generated schema.
2. The MongoDB query builder translates the planned operations into database lookups based on your data mappings.
3. The result assembler collects results from all resolved fields and nested relations, returning the final JSON response.

What This Means in Practice

• Add a table on the board — it becomes queryable immediately via the mock API.
• Add a relation line — consumers can now write nested queries traversing that relation.
• Remove a table — queries referencing that type will fail, signaling consumers to update.
• Change attribute flags — sorting, filtering, and search capabilities adjust accordingly.

The spatial layout of cards on the board (positions, grouping, zoom level) is preserved for visual reference only. It has no effect on schema generation or runtime behavior. Two boards with identical tables and relations but different spatial layouts produce identical APIs.

ws-board-08-causalityMissing

Diagram showing the flow from board entities to GraphQL types to runtime query resolution.

Schema generation

Free User

Schema generation and runtime query resolution are available on all plans, including the free tier. The board-to-API pipeline works identically regardless of plan — there are no feature gates on the core modelling workflow.

Advanced board workflows

Paid User

Paid plans support multiple projects, enabling you to maintain separate boards for different API domains. Use this to isolate unrelated domain models — for example, one project for your e-commerce mock and another for your analytics mock — while keeping each board focused and navigable.

Related Pages

• Tables & Attributes — detailed attribute configuration, data mappings, and field flags
• Relations — relation types, linking columns, and quality considerations
• Views — configuring how data is presented and queried
• API Design — query naming, operation exposure, and pagination defaults
• Preview & Hints — live preview, readiness hints, and iteration workflow
• Data Sources — available datasets and data object selection
• Modelling Runtime Preview — the combined preview panel accessible from the play button