Building Software Is Like Building an Ecosystem
Every software project is like building a small, living ecosystem. You don’t just write code — you define relationships, behaviors, structures, flows, constraints. Everything affects everything else: a database model informs the API, which feeds the frontend, which influences UX decisions, which loops back into validation rules and error states.
In the middle of that web is one quiet but critical requirement: data. Every part of the stack needs it — not just eventually, but right from the start.
The moment you start prototyping, testing, or designing flows, you need something to move through the system. You need mock data. Not just for one field or one example — but full sets of realistic, structured, rule-compliant objects that look and behave like real-world inputs.
It shows up in every stage:
- Designing UI with real-looking content
- Testing logic that depends on field constraints
- Simulating API responses during integration
- Seeding local environments before backend logic exists
- Demonstrating flows with actual variety, not placeholder values
But generating that data is usually annoying. Most of us either fake it manually, duplicate a handful of examples, or lean on tools that don’t understand schema structure or field-level constraints. The process works — until it breaks. And then it breaks often.
Mock Data Is Easy — Until It Isn’t
Developers, QA engineers, and data-heavy product teams all hit the same wall at some point: the need for structured, realistic mock data — fast. It’s not hard to mock a single user object. What gets frustrating is mocking multiple records of users with valid emails, localized names, structured metadata, and constraints like length, range, pattern, or nested field relationships.
MockingJar
“is a tool built from that pain.”
Not a startup pitch. Not another playground for random fake data. Just a solid web app designed to generate test data that fits your schema, follows rules, and respects structure.
It combines a visual schema builder, a powerful validation engine, and an AI-driven generation backend using the Claude API. You define the shape. You guide the content. MockingJar fills in the rest — intelligently, repeatably, and without requiring manual fixes.
Why This Exists
This project came out of repetition. Over and over, you start with:
“Let’s build a quick mock for this.”And a few hours later you’re still writing nested JSON by hand, patching fake values, or tweaking IDs and arrays that don’t quite match the real structure.
MockingJar exists to eliminate that friction — especially in the early stages of building software. These days, engineers spend more time prototyping, validating ideas, and building POCs than ever before. With that pace, needing structured, schema-valid mock data isn’t an edge case — it’s daily life.
This tool gives you back that time — by doing one thing well: generating structured data from a schema you define.
What It Actually Does
MockingJar is split into two major components:
1. Web Interface
A full-featured web app built with:
- Next.js 15 (App Router)
- Material UI v7
- React Hook Form + Zod for validation
- Next Auth + Google OAuth for secure login
- CSRF + Session + Protected routes for multiple layers of security
- PostgreSQL via Prisma for data persistence
- Zustand + React Query for frontend state & data sync
This interface includes:
- A visual schema builder with tree view
- A natural language prompt interface for AI-driven data generation
- A personal schema library with save/edit/delete support
- Authentication and session management
- JSON preview and export tools
2. mockingjar-lib Core Engine
A standalone TypeScript package with:
- A schema builder & manipulation engine
- A field-level JSON validator
- An Anthropic Claude integration layer
- Support for nested objects, arrays, references, and complex constraints
- Surgical regeneration of only invalid fields
- Full test coverage
This is the same engine used in the web app — also usable in backend scripts, or test runners.
Building the Schema
MockingJar revolves around user-defined schemas. You can define field types, logic constraints, and structure down to each level.
Supported types include:
text,number,boolean,date,email,urlobject(with nested fields)array(with item constraints and nested structures)schema(reference to another saved schema)
Each field supports logic like:
- Required/optional
- Min/max values or lengths
- Pattern matching (e.g.
^ORD-d{6}$) - Enum choices
- Size constraints for arrays
Schema Composition
You can embed existing schemas within others. This “schema” type allows you to modularize shared models — like embedding an Address schema into multiple forms (shippingAddress, billingAddress, etc.) without redefining it every time.
Schema Builder Highlights
- Auto-save system
- Tree view for deep nesting
- JSON-to-schema converter (paste in a JSON sample and convert to schema)
- Schema selection dialog (for embedding existing schemas)
- Templates for common models
Generating Data
Once the schema is ready, you can generate data with a prompt like:
“Generate order data for a customer based in London, purchasing a product related to home utilities (e.g., kitchen appliances, cleaning equipment, or home maintenance tools)”
The prompt doesn’t replace your schema — it simply guides the tone and realism of the values generated. MockingJar uses Claude Sonnet 4 behind the scenes to fill each field while respecting:
- Type
- Constraints
- Nesting
- Array lengths
- Regex and enum rules
And you can configure how many records you want.
You’ll get a result preview and formatted output. If any fields fail validation, they’re retried individually — not thrown out with the rest. That recovery process is key to keeping data generation fast and consistent.
The mockingjar-lib Core Engine
This is where all the real magic lives — and you can use it directly in your Node.js projects with any Frontend preference.
Example:
import { Generator } from 'mockingjar-lib';
const result = await Generator.generate(
'your-anthropic-api-key',
yourSchema,
'Generate Indonesian customer records with valid emails',
{
count: 10,
enableFallback: true,
timeout: 60000
}
);
if (result.success) {
console.log(result.data);
} else {
console.error(result.errors);
}
You can also:
- Validate JSON against a schema (
Validation.validate) - Convert JSON into a schema (
Schema.convert.jsonToSchema) - Add/update/remove deeply nested fields
- Get structured metadata about generation performance
Developer-Focused Architecture
- Full TypeScript codebase
- ESLint + strict mode enforced
- Modular codebase with
generator,schema,validation, andanthropiclayers - Easily extensible to add custom generators or field types
🧪 Still Evolving — Open to Collaboration
MockingJar isn’t a polished product. It’s a functional, real-world tool that solves a specific problem — and it does that well — but there’s plenty of room to grow.
Some areas still need refinement:
- UI usability and form ergonomics
- Schema versioning and import/export
- More intuitive handling of deeply nested structures
- Improved AI prompt interpretation and feedback
- Community schema/template sharing
- Better error visibility and debugging flows
The core generation engine (mockingjar-lib) is solid and tested, but the experience around it — especially in the web app — is still being shaped.
This project isn’t trying to be everything from day one. It’s being built piece by piece with real usage in mind, and if you’re the kind of developer who sees opportunities in that kind of foundation, your help would be welcome.
MockingJar is fully open-source. Contributions, testing, feedback, bug reports, and PRs are all appreciated — whether it’s fixing a bug, improving a prompt flow, or just pointing out where something feels off.
If this tool has solved even a small annoyance for you, and you want to help push it further, jump in.
Let’s build something useful — together.
Final Thought
MockingJar wasn’t made to impress. It was made to stop wasting time — especially on a task that no one wants to do more than once.
If you regularly write schemas, mock APIs, or build test setups, this might be a tool worth adding to your stack. And if not, steal the parts you like — that’s what open source is for.
