Views

Views define how a table's data is presented to API consumers. While the domain model describes the structure of your data — tables, attributes, relations — a view determines the shape, ordering, and accessibility of that data at runtime. Each view configures column visibility, label overrides, pagination defaults, sorting behavior, filtering capabilities, and detail relations for a single table.

A view is the decisive layer between your raw domain model and the consumer-facing API response. Without a view, a table has no runtime representation. With a view, the table becomes a queryable GraphQL endpoint whose behavior you control precisely.

ws-views-01-overviewMissing

Views management area showing configured views for multiple tables.

What a View Controls

A view governs six distinct aspects of runtime behavior:

Aspect	What It Determines
Column configuration	Which fields appear, their labels, width, alignment, and order
Sort/search/filter toggles	Which columns support sorting, full-text search, and filter expressions
Pagination defaults	Default page size, default sort field, and sort direction
Detail relations	Which related tables appear when viewing a single record
API binding	The GraphQL list query name and detail query name
Column order	The sequence of fields in the API response

Every aspect is independently configurable. Changes to one do not implicitly alter the others.

Creating a View

There are two entry points for creating a view:

From the Modelling Runtime Preview

Click the play button on any table card header on the Modelling Board. If no view exists for the table, the Modelling Runtime Preview opens with default settings and a Create button. Configure the view settings in the left column, observe the live data preview in the center, and save when satisfied.

This is the recommended approach — it provides an immediate feedback loop between configuration and output.

ws-views-02-create-from-previewMissing

Creating a new view from the runtime preview panel with defaults loaded.

From the Views Management Area

Navigate to the Views section in the workspace sidebar. Click Create View, select the target table, and configure all settings in the dedicated form. This approach is useful when you want to configure a view without the live preview context.

View limits

Free User

Free-plan users can create views for all tables within their project. There are no restrictions on the number of views or the number of configured columns.

Editing a View

If a view already exists for a table, opening the Modelling Runtime Preview via the play button loads the view in edit mode with all settings pre-filled. Changes update the data preview in real time — you see the effect of every adjustment before saving.

You can also edit views directly from the Views management area by selecting an existing view from the list.

Column Configuration

Column configuration determines which attributes of the underlying table appear in the API response and how they are presented.

Visibility

Not every attribute needs to be exposed. Toggle column visibility to include or exclude specific fields from the API response. Hidden columns are omitted from query results entirely — they do not appear as null values; they are absent from the response schema.

Label Overrides

The display label of a column can differ from the underlying attribute name. This is useful when your domain model uses technical names (e.g., unitPriceNet) but consumers expect friendlier labels (e.g., Unit Price (Net)). The label override affects the column header in the runtime preview but does not alter the GraphQL field name.

Width and Alignment

Set column width and text alignment for the runtime preview display. These settings affect the visual presentation in the preview panel and the generated data table layout.

Sort, Search, and Filter Toggles

Each column can independently support:

• Sortable — enables the sort parameter for this field in queries
• Searchable — includes this field in full-text search resolution
• Filterable — enables the filter parameter with type-appropriate operators

These toggles must be consistent with the attribute's data type. A boolean field, for example, supports filtering but not full-text search. The Preview & Hints system will flag configuration mismatches.

Column Order

The order of columns in the view configuration determines the field order in the API response. Drag columns to reorder them. This order is preserved across saves and reflected in both the preview and the live API.

ws-views-03-column-configMissing

Column configuration panel with visibility toggles, label overrides, and sort/search/filter flags.

Pagination and Sorting Defaults

Views define the default pagination and sorting behavior that applies when a consumer issues a query without explicit parameters.

Setting	Purpose	Example
Default page size	Number of records returned per page	20
Default sort field	The column used for initial ordering	createdAt
Default sort direction	Ascending or descending	DESC

These defaults are a starting point — consumers can always override them with explicit limit, offset, sort, and sortDirection parameters in their queries. When no override is provided, the view defaults govern the response shape.

Choose defaults that reflect the most common access pattern. For time-series data, sorting by date descending is typically appropriate. For catalog data, sorting by name ascending may be more useful.

Pagination best practice

Registered User

Set conservative default page sizes (10-25 records). Large default pages increase response time and bandwidth consumption for consumers who do not paginate explicitly.

Detail Relations

Detail relations control which related tables appear when a consumer queries a single record via the detail query.

Display Modes

There are two display modes, determined by the relation cardinality:

Mode	Applies To	Presentation
Record preview	n:1 relations (parent lookup)	Compact preview card showing the related parent record
Sub-table	1:n relations (child collection)	Paginated table showing related child records

Configuration

For each relation you wish to include in the detail view:

1. Select the related table from the available relations defined in Tables & Attributes.
2. The display mode is determined automatically by the relation cardinality.
3. Optionally configure which columns of the related table are visible in the detail context.

Detail relations appear in the right column of the Modelling Runtime Preview when a row is selected. If no detail relations are configured, the preview uses a two-column layout.

ws-views-04-detail-relationsMissing

Detail relations configuration with record preview and sub-table modes.

Nested detail depth

Paid User

Paid-plan users benefit from deeper nesting in detail relations. Configure multi-level relations to give consumers richer context when querying individual records.

API Binding

API binding defines the GraphQL entry points that consumers use to access the table's data.

Binding	Purpose	Example
Query name	The list query name (plural)	products
Single query name	The detail query name (singular)	product

These names form the API contract that consumers depend on. Once shared with a consumer, renaming a query is a breaking change. Choose names carefully and follow consistent conventions across your project.

Mockomat generates default query names from the table name, but you can override them. See API Design for broader guidance on query naming strategy.

ws-views-05-api-bindingMissing

API binding configuration with query name and single query name fields.

API naming governance

Enterprise User

Enterprise teams should establish naming conventions for query bindings and enforce them across all project views. Consistent naming reduces integration friction and simplifies documentation for external consumers.

Causality: View Config to Consumer Response

Every view setting has a direct, traceable effect on the API output. Understanding this causality helps you predict how changes propagate.

View Setting	Runtime Effect
Column visibility	Determines which fields appear in API responses
Column order	Determines field sequence in the response object
Label overrides	Affects preview display (GraphQL field names remain unchanged)
Sort defaults	Determines initial ordering when no sort parameter is specified
Pagination defaults	Determines page size when no limit parameter is specified
Sort/search/filter toggles	Determines which query parameters are accepted per field
Detail relations	Determines nested data availability in detail queries
API binding names	Determines the GraphQL query entry points consumers use

Changes to view configuration are reflected in the Modelling Runtime Preview immediately. There is no deployment step between configuration and preview — the feedback loop is instantaneous.

ws-views-06-causalityMissing

Side-by-side comparison of view configuration and resulting API response shape.

Working with the Modelling Board

Views are tightly integrated with the Modelling Board. The play button on each table card is the fastest path to creating or editing a view. The board's visual layout gives you spatial context — you can see which tables have views configured and how they relate to each other before opening the preview.

When you spot an issue in the runtime preview, use the Go to Board link to navigate back to the modelling board with the viewport centered on the relevant table. This cross-navigation pattern keeps your workflow fluid.

Programmatic view management

Developer / Integrator

Integrators working with the Mockomat API can create and update views programmatically via the management GraphQL API. This is useful for automated project setup and CI/CD pipelines that provision mock environments. See the API reference for view mutation schemas.

Summary

Views are the configuration layer that transforms a domain model into a consumer-ready API. They control column presentation, query defaults, detail relations, and API binding — everything that determines the shape and behavior of the runtime response. Use the Modelling Runtime Preview for an immediate feedback loop, and consult Preview & Hints to catch configuration issues early.