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: string, number, boolean, date, json
• Required flag — whether the field must always have a value
• Sortable flag — whether the field can be used for ordering results
• Searchable flag — whether the field participates in search queries
• Filterable flag — whether the field supports filter operations

These flags directly influence how the API layer exposes your data. A field marked sortable: true becomes available for sort operations in GraphQL queries. A field marked filterable: true supports filter expressions.

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(offset: 0, limit: 20, filter: { ... }, sort: { ... }) {
    id
    name
    price
    category {
      id
      name
    }
  }
}

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

Filtering

The filter system supports type-safe, composable expressions:

Operator	Description	Applicable Types
equals	Exact match	All types
notEquals	Negation	All types
contains	Substring match	Strings
greaterThan / greaterThanOrEqual	Range (upper)	Numbers, Dates
lessThan / lessThanOrEqual	Range (lower)	Numbers, Dates
in	Value in set	IDs, Enums
isNull / isNotNull	Null check	All types

Filters can be combined using AND and OR logical operators, and can be nested for complex expressions.

Sorting

Fields marked as sortable: true in the domain model can be used in sort operations. Sort direction is either ascending (ASC) or descending (DESC).

Pagination

Mockomat uses offset-based pagination:

• offset — number of items to skip (default: 0)
• limit — number of items to return (default: 20)

This model is simple and works well for most use cases. The response includes the data array along with pagination metadata.

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 offset and limit 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 several mapping types that determine where field values come from:

OFF_FIELD — Real Dataset Fields

Maps an attribute to a field from a real-world dataset (e.g., Open Food Facts). This gives your mock API realistic, diverse data that behaves like production data.

Use this when you want:

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

FAKE — Generated Data (Faker)

Maps an attribute to a Faker generator that produces realistic synthetic data: names, emails, addresses, dates, prices, and more.

Use this when you want:

• Personal data (names, emails, phone numbers)
• Financial data (prices, account numbers)
• Temporal data (dates, timestamps)
• Any data type not covered by real datasets

CONST — Constant Values

Maps an attribute to a fixed value that is the same for every record.

Use this when you want:

• Default status values (e.g., "active")
• Fixed configuration values
• Placeholder data during early modeling

COMPUTED — Derived Values (Future)

Will allow defining field values through expressions based on other fields. This is planned for a future release.

cc-04-data-sourcesMissing

Field mapping configuration with different data source types.

Data source availability

Free User

Free users have access to all mapping types (OFF_FIELD, FAKE, CONST) and public datasets. Custom dataset uploads are available on Enterprise plans.

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:

• Separate data space — each project has its own MongoDB collections for mock 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 — all data access is filtered by tenant, 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 isolation

Enterprise User

Enterprise tenants get additional isolation guarantees: dedicated data collections, configurable session limits, custom rate limiting, and optional on-premise deployment for complete data sovereignty.

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.