Core Concepts

Mockomat is built around one central principle: domain intent should stay visible from model to runtime.

Every decision you make — naming an entity, defining a field type, establishing a relation — flows through a connected pipeline: from your domain model, through API definition, into live runtime behavior, and ultimately into a generated backend you own. This page explains the conceptual layers that make this possible.

1. Domain Layer: What the System Means

The domain layer is the semantic foundation of your project. It defines the structure and meaning of your data before any API or implementation detail is decided.

Entities and Tables

An entity (or table) represents a real business concept: Customer, Order, Invoice, Subscription. Each entity has a name, a set of attributes (columns), and optionally one or more relations to other entities.

Naming matters. Mockomat encourages you to use your team's actual business language rather than generic sample names. A model built with Customer and Subscription communicates intent far better than Table1 and Table2.

Attributes

Each attribute has:

• Name — a descriptive identifier (e.g., firstName, totalAmount, isActive)
• Type — the data type, e.g., String, Integer, Float, Boolean, Date, JSON, Enum
• Required flag — whether the field must always have a value
• Searchable flag — whether the field takes part in the searchTerm search of list operations
• Sortable and Filterable flags — stored with the model; Sortable also marks sortable list columns in code export

Of these flags, only Searchable changes the mock API. Sorting works on any attribute bound to a data column (sortField), and filtering uses the parameters you define on an operation (see API Design).

Relations

Relations connect entities and express business ownership or reference patterns:

• One-to-One (1:1) — e.g., User → Profile
• One-to-Many (1:n) — e.g., Customer → Order[]
• Many-to-Many (m:n) — e.g., Product ↔ Category

Each relation has a direction and a cardinality. The relation definition determines how the runtime resolves lookups: when you query an Order, the related Customer data is assembled from the underlying data source based on these definitions.

Why This Layer Matters

• Reduces naming drift — everyone on the team uses the same vocabulary.
• Improves cross-team alignment — frontend and backend developers share one model of truth.
• Makes architecture reviewable — domain intent is explicit, not buried in code.
• Enables automation — code generation, API exposure, and runtime behavior all derive from this layer.

cc-01-domain-layerMissing

Domain layer model with entities and relations.

2. API Definition Layer: How the System Is Exposed

The API layer translates domain intent into a query and operation surface. Mockomat uses a code-first GraphQL approach: your model definitions are automatically translated into a fully typed GraphQL schema.

Dynamic Schema Generation

When a project is activated, Mockomat generates a GraphQL schema on-the-fly:

1. Load model definitions — read all entities, attributes, relations, and configuration from the project.
2. Construct GraphQL types — each entity becomes a GraphQL object type; each attribute becomes a typed field.
3. Construct query entry points — list and detail queries are generated for each entity.
4. Register resolvers — field-level resolvers handle data retrieval, mapping, and relation lookups.
5. Accept requests — the schema is ready to serve queries immediately.

This means you never write schema files manually. The schema is always synchronized with your model.

Query Structure

Every entity automatically generates two query types:

• List query — returns a paginated collection with optional filtering and sorting.
• Detail query — returns a single item by its identifier.

For example, if you model a Product entity, the generated queries might look like:

query {
  products(page: 1, pageSize: 20, sortField: "price", sortDirection: ASC) {
    items {
      id
      name
      price
      category {
        id
        name
      }
    }
    total
  }
}

query {
  product(id: "abc-123") {
    id
    name
    price
    description
  }
}

Filtering

Filters are defined per operation in API design — fixed scope filters and caller parameters, each with an operator:

Operator	Description	Applicable Types
eq	Equals	All types
neq	Not equals	All types
gt / gte	Greater than / greater or equal	Numbers, Dates
lt / lte	Less than / less or equal	Numbers, Dates
in	One of a list of values	All types
like	Contains (case-insensitive)	Strings
notIn	None of a list of values (scope filters only)	All types
isNull / isNotNull	Is null / is not null (scope filters only)	All types

All filters of an operation combine with AND; there is no OR and no nesting at request time.

Sorting

Sort with sortField (an attribute name) and sortDirection — ascending (ASC) or descending (DESC).

Pagination

Mockomat uses page-based pagination:

• page — page number, starting at 1 (default: 1)
• pageSize — records per page, at most 100 (default: the operation's default page size, 25 unless changed)

The response wraps the records in items, next to total, page and pageSize.

cc-02-endpoint-configMissing

API definition and endpoint configuration view.

3. Runtime Layer: How Behavior Is Validated

The runtime layer is where your model and API decisions are tested against real query execution. It answers the question: does the system behave the way you intended?

How the Mock Runtime Works

The mock runtime engine is the core of Mockomat's value. It accepts GraphQL queries and translates them into MongoDB operations through a four-stage pipeline:

1. GraphQL Request Parser — parses the incoming query string into an abstract syntax tree (AST).
2. Query Planner — analyzes the AST alongside model metadata to create an execution plan.
3. MongoDB Query Builder — translates the execution plan into a MongoDB aggregation pipeline.
4. Result Assembler — reshapes MongoDB results to match the expected GraphQL response structure.

This pipeline runs on every query. Because MongoDB stores data in flat (denormalized) collections, the runtime simulates relational structure — joining related data, resolving nested fields, and assembling the final response as if it came from a fully relational backend.

Preview vs External Consumption

The same runtime endpoint serves two audiences:

• Preview — the in-app Runtime page where you test queries, inspect response shapes, and validate behavior during modeling.
• External consumers — your frontend application, test suite, or CI pipeline calling the same mock API endpoint.

Both use the same REST endpoint: POST /mock/{slug}/graphql. This means what you validate in preview is exactly what external consumers will receive.

What Validation Means in Practice

Runtime validation is not just "does the query return data." It confirms:

• Field shapes — are the returned types and structures what you expect?
• Relation lookups — do nested objects resolve correctly?
• Pagination behavior — do page and pageSize produce consistent slices?
• Sort stability — does sorting on a field produce a predictable order?
• Filter accuracy — do filter expressions match the correct subset of data?
• Null handling — are optional fields correctly represented as null when no data exists?

cc-03-runtime-flowMissing

Model-to-runtime flow with validation checkpoints.

4. Data Sources and Field Mapping

Every attribute in your model needs a data source. Mockomat supports three mapping types that determine where field values come from (the attribute editor offers Data Source and Constant, and shows Computed only on attributes that already have a Computed mapping):

SOURCE — Imported Dataset Columns

Binds an attribute to a column of the shared data pool — imported datasets: open data where a vetted source exists, generated sample data for the blueprints. The runtime serves the imported rows and never invents values.

Use this when you want:

• Realistic names, addresses, product data, categories, or measurements
• Large volumes of varied data
• Data that feels authentic in demos and testing

CONSTANT — Constant Values

Pins one fixed value on the attribute. The runtime returns it on every row, on rows of imported data and on rows composed from value pools alike.

Use this when you want:

• Default status values (e.g., "active")
• Fixed configuration values

COMPUTED — Derived Values (Not Evaluated)

Stores an expression over other fields of the same record (e.g., a full name from first and last name). The runtime does not evaluate expressions, so a computed field is not part of the response. The attribute editor no longer offers Computed; an attribute that already has a Computed mapping keeps it and is marked as not evaluated.

cc-04-data-sourcesMissing

Field mapping configuration with different data source types.

Data source availability

Free User

Every plan, guest sessions included, has the same mapping types and the same shared data pool.

5. Views: How Data Is Presented

Views define how a table's data is shaped for API consumers. While the domain model describes what exists and the API layer describes how to query it, views describe what the consumer sees.

Each view controls:

• Column visibility — which attributes appear in the response.
• Pagination defaults — page size when the consumer does not specify one.
• Sort defaults — initial ordering when no sort is requested.
• Detail relations — which related tables appear when viewing a single record.
• API binding — the query names consumers use (e.g., products, product).

Views bridge the gap between the raw domain model and the consumer-facing response shape. They are configured through the Modelling Runtime Preview panel or the dedicated Views management area.

For a detailed guide, see Workspace → Views. For how view configuration propagates through the system, see the Causality Reference.

cc-05-viewsMissing

View configuration controlling consumer-facing response shape.

6. Project Isolation and Multi-Tenancy

Every Mockomat project operates in its own isolated context:

• Shared, read-only data pool — mock data comes from one shared pool of imported datasets; a project reads only the tables it is bound to and never changes pool data.
• Independent schema — the GraphQL schema is generated per project based on its specific model.
• Slug-based endpoints — each project gets a unique URL path (/mock/{slug}/graphql).
• Tenant scoping — models, members, and API keys belong to one tenant, and every request is checked against it, ensuring strict isolation between organizations.

This means multiple teams can work on different projects simultaneously without any risk of data leakage or schema conflicts.

Enterprise limits

Enterprise User

Isolation is the same on every plan. Enterprise is arranged with our sales team: limits such as projects, requests and team size are adjusted per contract.

7. AI + Architecture Together

AI accelerates creation. Mockomat preserves structure quality and explainability while requirements evolve.

The platform is designed to work alongside AI tools, not replace them. While AI can generate code fragments quickly, Mockomat provides the structural context that AI-generated code often lacks:

• Schema consistency — your domain model is the single source of truth, whether you build it manually or with AI assistance.
• Runtime verification — every change can be validated through the preview pipeline before it reaches production.
• Traceable decisions — model changes are explicit and reviewable, not buried in AI-generated code.

Integrator perspective

Developer / Integrator

Treat generated artifacts as starting points, not final truth. Keep the model as the source of intent and let runtime behavior confirm quality. When integrating AI-assisted workflows, use the Mockomat model as the contract that AI-generated consumers must conform to.

Enterprise perspective

Enterprise User

Long-term value comes from repeatable architecture, not only fast initial output. Domain continuity is the control point for multi-team evolution. Use Mockomat models as governance artifacts that survive individual sprint cycles.