Mocks in API Development: Pain Points, Solutions, and Best Practices with EchoAPI

If you’ve ever built an API-driven product, you know this already: mocking is inevitable.
Early on, when the backend isn’t ready yet (or a third-party service is blocking you), mocks keep the frontend moving. They let you build, test, and iterate—even without real backend data.

Let’s dig into the common headaches, the usual workarounds, and how EchoAPI makes mocking a lot more indie hacker–friendly.

1. Real-World Pain Points

Picture this:
You’re hacking on a front-end for an e-commerce app. The user hits "Pay Now," which should call your /pay endpoint and return something like:

{
    "data": {
        "code": 0,
        "message": "success",
        "pay_dtime":"2025-08-10 10:00:00",
        "order_id":"sn12345678"
    }
}

But…

The backend team hasn’t built /pay yet.
The payment flow depends on an external gateway (not set up in your dev env).
Some endpoints need gnarly auth or data prep, which slows you down.

Result? Frontend progress blocked.
This is where mocking saves the day.

2. Common Mocking Approaches & Their Limits

2.1 Local JSON Files

The DIY starter kit:
Drop a file in mock/data.json and fetch it.

fetch('/mock/pay.json')

Why it sucks long-term:

Always static, no randomness.
Can’t fake pagination, conditions, or anything with logic.

2.2 Front-End Request Interception

(axios-mock-adapter, Mock.js)

Catch requests right in the browser:

mock.onPost('/api/pay/confirm').reply(200, {
  "data": {
    "code": 0,
    "message": "success",
    "pay_dtime":"2025-08-10 10:00:00",
    "order_id":"sn12345678"
  }
});

Downsides:

Stuck inside the frontend project.
Data is hardcoded in JS → painful to update or share.

2.3 Self-Hosted Mock Server

(json-server, Easy Mock)

Spin up a dedicated mock service.

The catch:

More infra, more maintenance.
Complex scenarios = lots of custom scripts.

All these work okay in the early days. But once the app grows, you’ll crave flexibility and dynamic responses.

3. EchoAPI Mocking in Action

EchoAPI is designed to fix exactly these pain points—lightweight to start, but powerful enough to scale with you. Let’s go back to the /pay example.

3.1 Fixed-Value Mock

Spin up a fixed response in seconds:

{
  "data": {
    "code": 0,
    "message": "success"
  }
}

In EchoAPI, you just define the endpoint visually:

Switch to the Mock tab, grab the URL:

And boom, calling it gives back your defined JSON:

3.2 Randomized Values

Static mocks get boring fast. EchoAPI lets you drop in built-in variables—for example, random timestamps:

{
  "data": {
    "code": 0,
    "message": "success",
    "pay_dtime":"2025-08-10 10:00:00"
  }
}

Just insert a dynamic date variable:

Now each request feels fresh:

3.3 Custom Functions

Need something fancier, like an order ID that looks real?
Say: "sn" + 8 digits.

{
  "data": {
    "code": 0,
    "message": "success",
    "pay_dtime":"2025-08-10 10:00:00",
    "order_id":"sn12345678"
  }
}

EchoAPI lets you write (or AI-generate) a custom function:

Example with fn_orderno:

$Create fn\_orderno using AI or manual logic in echoapi.png$

And the result looks way closer to production:

3.4 Conditional Responses

Real APIs don’t always succeed. Sometimes you’re broke, sometimes the account is locked.
With EchoAPI you can mock those states too.

Example: insufficient balance:

And here’s what comes back:

Much closer to real-world testing than hardcoding JSON.

4. Wrap-Up

Mocking isn’t just a nice-to-have—it’s a productivity multiplier:

Frontend devs don’t need to wait on backend.
QA can test flows way earlier.

Why EchoAPI works well for indie hackers:

Built-in variables = instant variety in your responses.
Custom functions = real business logic, no heavy lifting.
Easy sharing = your team (or just future you) can reuse mocks without hacks.

If you’re building fast, iterating solo, or trying to simulate production early—EchoAPI keeps you shipping without waiting.

Happy building 🚀