Launched this week
Mockphine
Mock blocked APIs, passthrough ready routes, see live source
50 followers
Mock blocked APIs, passthrough ready routes, see live source
50 followers
Mockphine keeps frontend and QA moving when backends are unstable. It lets teams mock blocked endpoints, pass through ready ones, and prove exactly what served each response; control unmatched routes with strict 404 or fallback passthrough; and inspect served-by source, status, duration, headers, and bodies in Live View. Deterministic matching plus delay/failure simulation helps catch integration bugs before release.
Hi Cuong, really smart design on the route-level mock/passthrough modes — I've hit exactly this problem before. I'm a full-stack engineer (Next.js, TypeScript, Node.js) and would love to help build Mockphine further. Is there a way to reach you?
Mockphine
@shoaibhassan Thank you, I really appreciate it.
Right now I'm focused on building Mockphine solo, but I'll definitely keep you in mind and reach out if I need help later on.
Mockphine
How does Mockphine implement deterministic route matching when multiple mock rules overlap, and how is precedence resolved between mocked endpoints and passthrough routes?
Mockphine
@davitausberlin Mockphine doesn't use list order or "first match wins."
It resolves overlapping routes by specificity first: exact paths beat params, params beat wildcards, then body/header/query matchers break any remaining ties. After the single best endpoint is chosen, its mode decides behavior: `Mock` serves locally, `Passthrough` forwards upstream.
If nothing matches, the server fallback decides between strict `404 Not Mocked` and passthrough.
So precedence is: best deterministic match first, then mode, then server fallback.
Congratulations! The “fully mocked vs. fully staging” dilemma is one of those chronic engineering tax problems that never quite makes it onto the roadmap because it feels like infrastructure debt rather than a feature. Does Mockphine support response templating? E.g., can I define dynamic mock responses based on request parameters, or is it static fixture-based for now?
Mockphine
@jacklyn_i That's exactly the kind of engineering tax I built Mockphine for.
Right now, mock responses themselves are static fixture-based. So you can define status, headers, and body, but not yet generate response bodies dynamically from request params inside the mock response template.
The current way to model dynamic behavior is at the matching layer instead:
you can create overlapping endpoints and let Mockphine pick the most specific match based on method, path, query, headers, and body matchers. In practice, that lets you return different static responses for different request shapes in a deterministic way.
So today:
- dynamic branching: yes, via deterministic route selection
- inline response templating: not yet
The one place we do support templating today is passthrough path rewriting for wildcard routes, not mock response bodies.
Delay and failure simulation for edge-case testing is genuinely underrated. Most teams only discover timeout handling and degradation bugs in production. Question: can delay/failure rules be saved as reusable test scenarios, or do you configure them fresh each session?
Mockphine
@jerrybyday Completely agree. A lot of retry, timeout, and degraded-state bugs only show up once real latency and failure enter the picture.
On your question: you do not need to configure those fresh each session.
Delay, failure rate, and custom failure responses are saved as part of the endpoint configuration in the workspace, so they persist. If you want to reuse or share them more intentionally, you can also export those endpoints as a scenario pack and import them elsewhere.
So today the workflow is:
- persist them in the workspace for repeat local testing
- export/import them as scenario packs for reuse and sharing
- optionally run the pack’s checklist against Live View logs
The main caveat is that this is persisted scenario behavior, not yet a separate one-click "preset switcher" layer on top of the same endpoints.
I love the idea and execution. is there a cloud or a docker image option?
Mockphine
@salah_oukrim Thank you. Right now Mockphine is a local desktop app, so no cloud or Docker option yet.
The product is focused on making local API workflows deterministic on a developer/QA machine first. You can share workspaces and packs, but the server runtime is local today.
Would be useful to know whether your use case is CI, self-hosting, or a shared team environment.
@cuongnt_hn It would be great having mocked APIs shared across a team