MockBase

Hey! Maker here. I built MockBase because I kept hitting the same wall on every project: the frontend is ready to go, but the backend isn't — and "just wait" or "hardcode some JSON" both get old fast, especially once you need to test what happens when the real API times out, rate-limits you, or your app is expected to survive a request in a weird order. So instead of another static mock tool, I wanted something that behaves like a real API would: different responses depending on what you send it, state that actually persists between calls, and the ability to break it on purpose — a slow timeout, a truncated response, a dropped connection — since those are the paths that never get tested until they happen in production. It's still very much a living project, so if you hit something that doesn't work the way you'd expect, or there's a use case I haven't thought of, I'd genuinely like to hear about it here.

The live request inspector paired with stateful CRUD is a smart combination. Being able to see every call stream in as it happens, and then copy it straight to cURL or fetch, would save a lot of debugging time when frontend and backend are out of sync. Chaos injection for truncated bodies and dropped connections is also a useful addition that most mock tools skip.

The chaos injection is the part I'd use most. Timeouts and truncated bodies are exactly the paths that never get tested until production. Can a chaos rule fire only on every Nth request, or only after a certain stateful CRUD call? That would make it easy to reproduce "works the first time, fails on retry" bugs in CI.

The chaos injection plus live inspector combo is exactly what frontend testing usually lacks — being able to see the request stream while simulating timeouts and truncated bodies makes flaky-scenario testing way less painful. Rate limit simulation with deterministic 429s is another gap most mock servers ignore. Curious whether conditional matching supports GraphQL operation names out of the box.

Chaos injection plus stateful CRUD is the combination most mock servers skip: everyone handles the happy path, then you end up hand-rolling timeouts and 429s just to test retry logic. Two things I would want to pin down before pointing CI at this. Does a versioned save fork the stored state, so rolling back a bad edit cannot leave orphaned records behind? And can you seed a fixture set so each pipeline run starts from a deterministic state? Also curious whether the rate-limit simulation counts per endpoint or globally per API key.

The chaos injection options (truncated bodies, dropped connections, deterministic 429s after N requests) are exactly what's missing from most mock servers, which only ever return the happy path. Being able to test retry and backoff logic against a stable HTTPS URL, with every request streaming into the live inspector, looks really handy. Does the stateful CRUD reset between sessions, or can you snapshot it?

The chaos injection options like truncated bodies and dropped connections are a great touch, since those failure modes are usually painful to reproduce against a real backend. Do you plan to let teams share a mock with role-based access, so QA and frontend can work off the same versioned endpoint?

OpenAPI import paired with sandboxed Jinja2 is the part I would actually use when scaffolding a mock from a spec that already exists. If the spec uses oneOf with a discriminator, does import keep those as separate conditional routes, or does it flatten them to a single example body? And can a template read other Redis-backed CRUD records, or is the sandbox limited to the current request so it cannot leak another resource's state?

OpenAPI import paired with sandboxed Jinja2 is the part I would use when scaffolding a mock from an existing spec. If the spec uses oneOf with a discriminator, does import keep those as separate conditional routes, or flatten them to one example body? Can a template read other Redis-backed CRUD records, or is the sandbox limited to the current request?

For the live inspector, a useful safeguard would be automatic masking of Authorization headers, cookies, and common secret fields before requests are copied as cURL or shared with teammates. Synthetic fixtures can still accidentally include a real token. Does the inspector offer configurable redaction, and does that also apply to saved request history?

The chaos injection is what stands out for me. Testing a truncated body or a dropped connection is usually the part teams skip until it breaks in production. Can a single route mix chaos with conditional matching, e.g. fail only when a specific header is present?