Mockomat
Architecture

A model you write once.
Surfaces that stay in sync.

Mockomat is built around four ideas. Together they make mock data feel like an extension of your codebase, not a side-project. Here's how the system thinks — and what it gives you back.

The pipeline

From entities to two live surfaces.

You describe entities and attributes; Mockomat compiles a typed GraphQL schema, binds attributes to the data pool, and serves both a JSON endpoint and a rendered preview from the same compiled artifact.

DESIGN COMPILE SERVE CONSUME Your model User · email · fullName · avatarUrl Order · orderNo · total · status Compiler schema · types · resolvers pool ↔ field mappings seed plan DETERMINISTIC Runtime stateless · seedable resolver per type renderer per type seed = sha(...) POST /graphql application/json For your code, your CI, your AI agents GET /preview text/html For PMs, designers, stakeholders mockomat.pool 37 columns · 2.4M rows · public + per-tenant
The four ideas

Principles, not patterns.

We didn't build Mockomat by accreting features. Each capability follows from one of these four commitments. If you understand them, you can predict how the rest of the system behaves.

01

Schema-first.

You design the model. Mockomat compiles it.

Everything starts from your entities and attributes. The mock data, the GraphQL schema, the documentation, the rendered preview — all derive from a single source of truth. Change the model, everything downstream regenerates.

seed
02

Deterministic replay.

Same seed in. Same data out. Every time.

The runtime is stateless and seed-driven. A request to /graphql at any moment replays from the same seed your team agreed on — so a snapshot today matches a snapshot in CI tomorrow. No flaky fixtures, no drift between environments.

03

Multi-tenant by default.

Workspaces, projects, roles, scoped keys.

Every account is a tenant boundary. Inside, projects scope schemas; roles scope edit rights; API keys scope external access. Configuration is isolated per tenant from the very first byte — never bolted on after the fact.

JSON UI
04

Two surfaces, one model.

Machine-readable for code. Human-readable for review.

The same model serves /graphql for your application and /preview for stakeholders. Engineers consume JSON; designers and PMs see a rendered table or list of the very same data. No second source of truth for product reviews.

Code generation

Export your model as a real project.

When prototyping ends and shipping begins, your Mockomat schema doesn't stay locked in our service. One click generates a fully-typed Angular client and a NestJS server scaffold — both wired to the same GraphQL contract you already validated.

FRONTEND Angular 17 · standalone components · Apollo client
BACKEND NestJS 10 · GraphQL code-first · resolver stubs
SCHEMA GraphQL SDL · re-generated on each export
See an exported project
codegen.pipeline · deterministic · idempotent
schema.graphql
your model · 38 types · 142 fields
compile
frontend/ — Angular
typed queries · components
backend/ — NestJS
resolvers · DTOs · modules
MY-PROJECT.ZIP
📁 my-project/
📁 frontend/
📄 src/app/users/users.component.ts
📄 src/app/users/users.queries.ts ← typed Apollo queries
📄 src/app/graphql.types.ts
📁 backend/
📄 src/users/users.resolver.ts
📄 src/users/user.dto.ts
📄 src/users/users.module.ts
📄 schema.graphql ← single source of truth
📄 package.json
📄 README.md
Why determinism matters

Same input.
Same output.
Always.

Mock data with random seeds breaks tests, breaks reviews, and erodes trust. Mockomat's runtime keys every response off the same seed your team chose. Re-fetch a record next month — same shape, same values, same edges.

# request the same user, twice, three months apart
$ curl mockomat.app/p/abc/graphql -d '{ user(id:42) { email } }'
{ "data": { "user": { "email": "ada@bessemer.com" } } }
# 90 days later, same query…
$ curl mockomat.app/p/abc/graphql -d '{ user(id:42) { email } }'
{ "data": { "user": { "email": "ada@bessemer.com" } } }