Data Sources & Field Mapping

Every attribute in your data model requires a data source — the mechanism that determines what values the attribute returns when an API consumer executes a query. Without a configured data source, an attribute resolves to null and triggers an unmapped-attribute hint in the preview.

Mockomat provides three mapping types, each suited to different modelling needs: OFF_FIELD for real dataset fields, FAKE for Faker-generated synthetic data, and CONST for fixed constant values. A fourth type, COMPUTED, is planned for derived values.

This page explains each mapping type in detail, describes the selection workflow, and clarifies how mapping decisions propagate through the runtime.

Mapping Types at a Glance

Mapping Type	Data Origin	Best For	Volume Behaviour
OFF_FIELD	Real-world dataset field	Realistic product names, measurements, categories	Bounded by dataset size
FAKE	Faker library generator	Personal data, financial data, temporal values	Unbounded (generated on demand)
CONST	Fixed literal value	Default statuses, placeholders, configuration flags	Same value for every record
COMPUTED	Expression over other fields	Derived or concatenated values	Depends on source fields

ws-datasrc-01-mapping-overviewMissing

Attribute editor showing the three available mapping types in the mapping dropdown.

OFF_FIELD — Real Dataset Fields

The OFF_FIELD mapping connects an attribute to a field from a real-world dataset. These datasets originate from publicly licensed sources — such as Open Food Facts, geographic databases, or economic indicators — and are processed through the Mockomat data pipeline before they become available for mapping.

The pipeline follows a defined sequence: data acquisition from the source, normalization into a consistent structure, metadata generation (including field types, sample counts, and tags), and finally import into MongoDB. The result is a library of data objects, each representing a single field from a processed dataset.

When to Use OFF_FIELD

Use OFF_FIELD mapping when you need:

• Realistic diversity — product names, ingredient lists, geographic coordinates, or category hierarchies that behave like production data.
• Large volumes of varied data — datasets can contain thousands or millions of distinct values.
• Domain-specific accuracy — nutritional values that fall within plausible ranges, city names that correspond to real locations, or currency codes that follow ISO standards.

OFF_FIELD is the strongest choice when your mock API must convincingly simulate a production system for frontend development, integration testing, or stakeholder demonstrations.

Data Object Selection Workflow

When you select OFF_FIELD as the mapping type for an attribute, a side panel opens with the data object browser.

ws-datasrc-02-data-object-panelMissing

Data object selection panel with search bar, tag filters, and sample value preview.

The selection workflow proceeds as follows:

1. Search by name or tag — type a keyword (e.g., "nutrition", "city", "price") to filter the available data objects.
2. Apply tag filters — narrow results by category. Tags reflect the dataset domain (e.g., food, geography, commerce) and the field type (e.g., numeric, text, boolean).
3. Review sample values — each data object displays a set of sample values drawn from the actual dataset. This preview allows you to verify that the data matches your expectations before committing.
4. Confirm the mapping — select the data object to bind it to the attribute.

Data Object Metadata

Each data object exposes the following metadata:

Property	Description
Field name	The original field identifier from the source dataset
Type	The inferred data type (string, number, boolean, date)
Sample count	The number of distinct values available in the dataset
Tags	Categorical labels for discovery and filtering
Source	The originating dataset (e.g., Open Food Facts, GeoNames)

ws-datasrc-03-data-object-metadataMissing

Data object detail view showing field metadata and sample values.

Dataset access on the free plan

Free User

Free plan users have access to a curated subset of data objects. Upgrade to a paid plan to unlock the full data object library, including larger datasets and specialized domain sources.

FAKE — Faker Generated Data

The FAKE mapping uses the Faker library to generate realistic synthetic data at query time. Unlike OFF_FIELD, which draws from a fixed pool of real values, FAKE produces new values on every request using configurable generator functions.

When to Use FAKE

Use FAKE mapping when you need:

• Personal data — names, email addresses, phone numbers, or usernames that look realistic but are entirely fictional.
• Financial data — account numbers, transaction amounts, currency codes, or IBAN values.
• Temporal data — dates in the past, future, or within a specific range.
• Infrastructure data — IP addresses, URLs, user agents, or MAC addresses.
• Data types not covered by available datasets — when no OFF_FIELD data object matches your requirement.

FAKE is locale-aware: generated values follow regional patterns. A Faker-generated address in the de locale produces German street names and postal codes; the same generator in fr locale produces French equivalents.

Faker Categories and Generators

The following table lists the most commonly used Faker categories and their representative generators:

Category	Generators	Example Output
Person	firstName, lastName, fullName, prefix, suffix	Maria, Gonzalez, Dr. Maria Gonzalez
Internet	email, url, ip, ipv6, userAgent, userName	maria.g@example.com, 192.168.1.42
Address	street, city, country, zipCode, latitude, longitude	742 Evergreen Terrace, Springfield
Commerce	price, productName, department, productDescription	Handcrafted Steel Chair, 49.99
Date	past, future, recent, between, birthdate	2024-08-15T10:33:00Z
Finance	accountNumber, amount, currencyCode, iban, bic	DE89370400440532013000
Phone	phoneNumber, imei	+49 30 1234567
Lorem	sentence, paragraph, words, slug	Lorem ipsum dolor sit amet
Color	hex, rgb, hsl, humanReadable	#3a7bd5, Cerulean
Company	companyName, catchPhrase, bs, industry	Mockomat Industries
System	fileName, mimeType, fileExtension, semver	report.pdf, application/json
Datatype	uuid, boolean, number, float, bigInt	550e8400-e29b-41d4-a716-446655440000

ws-datasrc-04-faker-category-browserMissing

Faker generator browser showing categories, individual generators, and locale selection.

Locale Behaviour

When you configure a FAKE mapping, the runtime respects the locale context of the project. This means:

• A firstName generator in locale tr produces Turkish names.
• An address generator in locale en produces English-format addresses.
• Locale consistency is maintained across all FAKE-mapped attributes within a single query response.

Extended Faker configuration

Paid User

Paid plan users can configure generator parameters such as date ranges, numeric bounds, and string length constraints. This allows precise control over the distribution and shape of generated values.

CONST — Constant Values

The CONST mapping returns a fixed literal value for every record. The configured value is stored as part of the attribute definition and is returned unchanged at query time.

When to Use CONST

Use CONST mapping when you need:

• Default status values — e.g., "active", "pending", "draft" for a status field during early prototyping.
• Fixed configuration flags — e.g., true for an isPublished boolean, or "USD" for a currency field.
• Placeholder data — when you intend to replace the mapping later but need the attribute to return a non-null value now.
• Controlled test scenarios — when a downstream consumer expects a specific value to trigger a particular code path.

CONST is the simplest mapping type. It requires no external data source and no generator configuration — only the literal value to return.

ws-datasrc-05-const-configurationMissing

Constant value configuration for a status attribute set to 'active'.

CONST availability

Free User

The CONST mapping type is available on all plans, including free and guest sessions. It is the fastest way to get a non-null value from any attribute.

COMPUTED — Derived Values (Planned)

The COMPUTED mapping type is a planned feature that will allow you to define attribute values through expressions evaluated over other fields in the same record.

Planned Capabilities

• Concatenation — combine two or more string fields (e.g., fullName = firstName + " " + lastName).
• Arithmetic — compute numeric values from other numeric fields (e.g., totalPrice = unitPrice * quantity).
• Conditional logic — return different values based on the state of other fields.

COMPUTED mappings will resolve after all source fields have been resolved, ensuring that the input values are available before the expression is evaluated.

COMPUTED mapping availability

Enterprise User

The COMPUTED mapping type will be available to enterprise plan users upon release. It is not yet available in the current version of Mockomat.

Causality: Mapping Type to Runtime Resolution

Understanding how each mapping type resolves at runtime clarifies the relationship between your modelling decisions and the API responses your consumers receive.

Resolution Pipeline

Mapping Type	Runtime Behaviour
OFF_FIELD	The query engine reads from the MongoDB collection where the imported dataset resides. Values are drawn from the stored pool and associated by record index.
FAKE	The query engine invokes the configured Faker generator at query time. Each request produces fresh values unless seeded.
CONST	The query engine returns the stored constant for every record in the result set.
COMPUTED	(Planned) The query engine evaluates the expression after resolving all dependency fields.

Transparency to API Consumers

The mapping type is invisible to API consumers. A GraphQL query returns field values without any indication of whether those values originated from a real dataset, a Faker generator, or a constant definition. From the consumer's perspective, the response is a coherent data object — the data source is an internal modelling concern.

This transparency means you can change a field's mapping type at any time without altering the API contract. Switching an attribute from CONST to OFF_FIELD, or from OFF_FIELD to FAKE, does not affect the query structure, field names, or response shape.

Unmapped Attributes

An attribute with no configured mapping returns null for every record. The Preview & Hints system flags unmapped attributes with a dedicated hint, making them easy to identify and resolve.

ws-datasrc-06-unmapped-hintMissing

Preview panel showing an unmapped-attribute hint for a field without a data source.

Choosing the Right Mapping Type

The following decision guide helps you select the appropriate mapping type for a given attribute:

Question	If Yes	If No
Does a real-world dataset exist for this field?	Use OFF_FIELD	Continue below
Does the field represent personal, financial, or temporal data?	Use FAKE	Continue below
Should every record have the same value?	Use CONST	Revisit your data requirements
Is the value derived from other fields?	Wait for COMPUTED or use CONST as a placeholder	—

When in doubt, start with CONST to unblock your modelling workflow, then revisit the mapping once your schema stabilises. The Tables & Attributes page covers attribute configuration in full, and the Modelling Board page explains how to navigate between tables and their mappings visually.

Mapping strategy for integration testing

Developer / Integrator

When building mock APIs for integration test suites, prefer OFF_FIELD for fields that drive business logic (product categories, status codes) and FAKE for fields that must be unique per test run (email addresses, UUIDs). Use CONST sparingly — only for fields where the test explicitly asserts a fixed value.

Summary

Data source mapping is the bridge between your structural data model and the values that flow through your mock API at runtime. Each mapping type serves a distinct purpose: OFF_FIELD provides grounded realism from curated datasets, FAKE generates diverse synthetic data on demand, and CONST delivers predictable fixed values. Selecting the right mapping for each attribute is a modelling decision that directly shapes how convincing and useful your mock API becomes for its consumers.