DEV Community: ProRecruit

Stop Writing JSON Fixtures. Use a Mock Server Instead.

ProRecruit — Sun, 22 Feb 2026 20:29:43 +0000

Every codebase I've inherited has a /fixtures or /mocks folder. Inside: hundreds of JSON files, half of them stale, most of them lying about the shape your real API returns.

I've spent more time updating JSON fixtures than I care to admit. Three months ago I stopped entirely and switched to a mock server driven by our OpenAPI spec. I haven't touched a fixture file since.

Why fixtures fail you

When a backend engineer adds a field or renames a property, your fixtures don't know. Your tests still pass — against the old, wrong shape. The bug shows up when you integration-test against the real API, or worse, in production.

The core issue is that fixtures are a copy of your API's shape, maintained by hand, with no automatic synchronization.

The alternative: spec-driven mocking

If you have an OpenAPI spec (and you should — it's the foundation of any well-documented REST API), a mock server can read it and serve live HTTP responses that match your schemas exactly. No manual copying. No drift.

I use moqapi.dev for this. Import a spec URL or file, get a hosted mock endpoint back in under 10 seconds. Every route in the spec becomes callable immediately.

When the spec updates — which it does constantly at the start of a project — I re-import. The mock updates. Zero manual work.
The concrete workflow

# Your mock base URL after import
NEXT_PUBLIC_API_URL=https://moqapi.dev/api/invoke/mock/<your-id>

# In production:
NEXT_PUBLIC_API_URL=https://api.yourapp.com

Your API client code doesn't change. You swap one environment variable on launch day.

What you get for free

Beyond eliminating fixtures, a spec-driven mock server gives you:

Schema-accurate data — field types, formats, enum values all match your spec
Error responses — the mock can return your spec-defined 4xx/5xx schemas
Versioning — every spec version is stored and rollback-able
Chaos testing — inject random errors to build resilient error states
The spec is the source of truth. Let the tooling honor it.

Why Your Frontend Integration Tests Keep Failing Randomly (And What to Do About It)

ProRecruit — Sun, 22 Feb 2026 20:26:57 +0000

I've seen this in three different companies. The CI pipeline runs 40 times a day. Sometimes it's green. Sometimes it's red for no obvious reason. Re-run it — green. Same commit. Different result.

This is flaky test syndrome, and it almost always has the same root cause: your tests depend on infrastructure that isn't deterministic.

The usual culprits

Tests hitting a live staging API that has rate limits
Tests relying on test data that a previous run modified and didn't clean up
Auth tokens that expire during a long test run
External services that are occasionally just slow or unavailable
Every one of these introduces non-determinism. Your test suite is now a probabilistic system, not a deterministic one. A 10% failure rate means 10% of your engineers' CI time is wasted on re-runs.

The fix: mock your external HTTP dependencies

For any external HTTP service your code calls, replace it with a mock in the test environment. Not a hardcoded stub in your test code — a real HTTP server that returns spec-accurate responses.

If the external service has an OpenAPI spec (most major APIs do), you can have a mock running in under 5 minutes using moqapi.dev. Import the spec, get a hosted mock URL, override the service URL in your CI environment variables.

# GitHub Actions
env:
  PAYMENT_API_URL: ${{ secrets.MOCK_PAYMENT_API_URL }}
  CRM_API_URL: ${{ secrets.MOCK_CRM_API_URL }}

The mocks never rate-limit you. They're always available. They return exactly what you configure. Your tests become deterministic.

The database piece

For your own database, wrap each integration test in a transaction that rolls back after the test. This keeps test data isolated without requiring database resets between runs. Every major ORM supports this pattern.

What success looks like

A pipeline that fails for one reason: your code has a bug. Not infrastructure flakiness. Not expired tokens. Not rate limits. Just your code.

That's what deterministic tests feel like. Once you've had them, going back is painful.

Chaos Engineering for Teams That Don't Have an SRE

ProRecruit — Sun, 22 Feb 2026 20:22:55 +0000

Netflix open-sourced Chaos Monkey in 2012 and kicked off a whole discipline. The idea: inject failures deliberately to find weaknesses before real outages do.

Most developers interpreted this as "only for Netflix-scale infrastructure teams" and moved on. That's a mistake. The chaos engineering techniques that prevent the most real-world incidents are available to any team with a mock API and an afternoon.

The incident pattern

It goes like this: you ship a feature. It works in staging. In production, an upstream service has a bad day — maybe a 503 rate of 5–10%, maybe high latency rather than failures. Your frontend was never tested against these conditions. It shows a blank screen. Support tickets arrive.

The fix is usually trivial (add an error state, implement a retry). The damage is real: user trust, reputation, support time.

What practical chaos testing looks like

You don't need to randomly terminate servers. You need to inject HTTP errors into your mock API at a configurable rate and test your frontend against that mock.

In moqapi.dev, this is a slider in the mock API settings. Set error rate to 20%, pick error codes (500, 503, 429), and use your UI for 5 minutes.

You'll find unhandled error states in the first 3 minutes. Blank screens. Infinite spinners. Forms that submit silently and do nothing on failure.

Fix them. Ship them. Your feature is now resilient by construction, not by accident.

The Four States pattern

Every UI component that fetches data should have four states: loading, error, empty, content. Chaos testing enforces this. After one session, you'll write it by default for every new component. That's the cultural shift chaos engineering is supposed to produce — and it doesn't require a dedicated SRE team to get there.

The Developer's Guide to API Versioning (What Nobody Tells You Until It's Too Late)

ProRecruit — Sun, 22 Feb 2026 20:18:24 +0000

Breaking changes are inevitable. User schemas evolve. Response formats get rationalized. Fields get renamed for consistency. The question isn't whether your API will break clients — it's how gracefully you handle it when it does.

Most teams have this conversation too late: after an important client is already broken, two versions behind, submitting angry support tickets.

The three approaches

Path versioning (/v1/users, /v2/users) is the most common and usually the right choice for public APIs. Versions are explicit, easy to route, easy to deprecate. The downside: you end up maintaining multiple active versions simultaneously.

Header versioning (Accept: application/vnd.api+json;version=2) keeps URLs clean but makes versioning invisible in browser address bars and API documentation. Good for internal APIs where you control all consumers.

Query parameter versioning (/users?version=2) is easy to implement but easy to forget and easy to misuse. Generally the weakest choice.

What actually breaks clients

Removing or renaming fields breaks clients. Changing field types breaks clients. Changing the shape of nested objects breaks clients.

Adding new optional fields almost never breaks well-written clients. Clients should ignore fields they don't understand. If yours don't, that's a separate problem.

The spec versioning approach

Before changing a contract, version the spec. Tools like moqapi.dev store every version of your OpenAPI spec with a timestamp, let you diff between versions, and let consumers test against any version via a stable URL.

This gives you a clear record of every breaking change, when it was made, and what the shape was at any point in time. Invaluable when a client files a "you broke us" ticket three weeks after a deploy.

The practical rule

Never remove a field from a response without a deprecation period. Add new fields freely. Rename by adding the new name alongside the old one for one API version, then removing the old name in the next. Give clients at least 90 days after a deprecation notice.

Simple rules, consistently applied, prevent most versioning disasters.

How I Set Up a Complete API Testing Environment in 20 Minutes for Free

ProRecruit — Sun, 22 Feb 2026 20:15:10 +0000

There's a tax on API development that nobody warns you about: the time you spend setting up test infrastructure before you can actually test anything.

Database seeds. Docker compose files. Auth tokens. Postman collections. Environment variables. For a small project, this can take half a day. For a new team member onboarding, it can take a full day.

I found a faster path.

Step 1: OpenAPI spec as the foundation (5 minutes)

If you're building a REST API, write the spec first. Not the full spec — just the routes you're building this sprint. OpenAPI YAML is readable and writable without tooling:

paths:
  /users:
    get:
      summary: List users
      responses:
        '200':
          description: User list
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/User'

This spec is your contract. Everything else derives from it.

Step 2: Import to a mock server (2 minutes)

Import the spec into moqapi.dev. Every route in the spec is now a live endpoint. Call it from any HTTP client — curl, Postman, your frontend code, your test suite.

Step 3: AI-generate realistic test data (3 minutes)

The mock returns schema-accurate data by default. To make it more realistic, use the "Generate with AI" button. It fills each resource with contextually appropriate values — not user_1234 strings, but actual name/email/date patterns that match your field names.

Step 4: Connect your frontend (2 minutes)
NEXT_PUBLIC_API_URL=https://moqapi.dev/api/invoke/mock/<id>

Done. Your frontend is connected to a live API that returns realistic data.

Step 5: Set up chaos testing (3 minutes)

Enable 15% error injection. Use the UI. Fix blank screens. Fix missing loading states. Your feature is resilient before it ships.

Step 6: Share with the team (immediately)

The mock URL is public. Share it with frontend engineers, QA, designers, stakeholders doing UAT. Everyone works against the same mock. No local setup. No "it doesn't work on my machine."

Total time: 15–20 minutes. Total infrastructure

I Stopped Using Postman for Mock Servers. Here's What I Use Instead

ProRecruit — Sun, 22 Feb 2026 20:09:23 +0000

Postman is a great HTTP client. Its mock server feature is less great.

To use Postman mocks, you define example responses manually for every endpoint in a collection. When the real API shape changes, you update the examples by hand. There's no connection between your actual API spec and the mock — it's all manual maintenance.

On the free tier, you're limited to one mock server and a thousand requests per month. For any active development workflow, you'll hit this in a few days.

I tried three alternatives before landing on a setup I actually like.

What I tried

Prism by Stoplight is excellent for local CLI mocking. npx @stoplight/prism-cli mock api.yaml starts a local proxy in seconds, validates requests, returns spec-compliant responses. The downside: it's local only. You can't share the URL with teammates or use it in CI without running a server somewhere.

Mockoon is a desktop app with a nice GUI. Great for offline work. But it's also local-only, and the cloud sync feature is paid.

moqapi.dev hit the sweet spot for my needs: spec-import, hosted, free tier that doesn't cap requests. Import an OpenAPI file, get a public URL that anyone on the team can call.

The concrete difference from Postman

With Postman, you manually maintain example responses. If your User object adds a preferredLanguage field, you update every example that contains a user.

With moqapi.dev, you update the spec. The mock updates automatically on the next import. Your team gets the new field in the next request without touching anything else.

When I still use Postman

For exploring an unfamiliar API, building custom request sequences, or running a one-off load test. Postman is still the best HTTP client for interactive exploration. I just don't use its mock server anymore.

OpenAPI Spec First: Why the Most Productive Teams Write the Spec Before the Code

ProRecruit — Sun, 22 Feb 2026 20:07:16 +0000

There's a pattern I've noticed across teams that ship fast with low defect rates: they write the API spec before writing any implementation code.

It sounds like adding work. In practice, it removes work — specifically the expensive, late-stage work of discovering misalignments between what the backend built and what the frontend expected.

The spec-first workflow

Backend and frontend engineers agree on the API contract together. This takes a meeting, not a week.
The contract is written as an OpenAPI YAML file and committed to the repo.
Frontend engineers import the spec into a mock server and start building against live endpoints immediately.
Backend engineers implement against the same spec. Their implementation is done when it matches the contract, not when the frontend works.
Integration is mechanical — the frontend just needs to change the base URL.
The key insight: the hard conversation ("what fields does this response need?", "what's the error shape?") happens at the start, in a meeting, when it's cheap to change. Not three weeks later when both sides have built assumptions into their code.

Why mock servers make spec-first work

Without a mock server, spec-first breaks down because the frontend can't build until the backend is done. The spec is just documentation — not a runnable contract.

With a mock server like moqapi.dev, the spec becomes a live API the moment it's written. Frontend development starts in parallel with backend development. The spec is the synchronization point.

What the spec also gives you
Auto-generated documentation (Swagger UI, Redoc)
Contract tests that verify the implementation matches the spec
Client SDK generation (OpenAPI Generator)
Postman collection generation
Mock servers (as above)
One artifact. Many uses. Write it first.

Serverless Functions: Five Mistakes to Avoid When You're Starting Out

ProRecruit — Sun, 22 Feb 2026 20:04:36 +0000

Serverless functions have a surprisingly high ratio of "looked simple, turns out complex" scenarios. The execution model is clean in theory — write a function, deploy, it runs on request — but the operational reality has sharp edges that aren't obvious until you've hit them.

Here are five I've seen repeatedly.

Mistake 1: Putting secrets in environment variables without encryption

Environment variables are visible in deployment logs and dashboards. Use a secrets manager (AWS Secrets Manager, Doppler, HashiCorp Vault) for anything sensitive. Retrieve secrets at runtime, not at deploy time via plain env vars.

Mistake 2: Creating database connections inside the handler

// Bad: new connection on every invocation
export const handler = async () => {
  const db = new Pool({ connectionString: process.env.DB_URL })
  // ...
}

// Good: connection outside handler, reused across warm invocations
const db = new Pool({ connectionString: process.env.DB_URL })
export const handler = async () => {
  // ...
}

Cold start creates a new connection. Warm invocations reuse the existing one. Putting the connection inside the handler means a new connection per request — expensive and often hitting connection pool limits.

Mistake 3: Not handling idempotency

Functions are invoked at-least-once in most serverless platforms. Handle duplicate invocations by checking an idempotency key before doing work. A simple database row with the event ID is sufficient.

Mistake 4: Ignoring the cold start budget

Your function's deploy package size directly affects cold start time. Audit your dependencies. moment.js is famously large — replace it with date-fns or the native Intl API. Avoid importing entire AWS SDK when you only need one service client.

Mistake 5: No local development story

Running serverless functions locally shouldn't require deploying to a cloud environment to test. Set up a local development workflow — for moqapi.dev functions there's an in-browser editor; for AWS Lambda, SAM or LocalStack. Test locally before every deploy.

The Mock API Setup That My Whole Team Now Uses — And How We Got Buy-In

ProRecruit — Sun, 22 Feb 2026 19:58:19 +0000

Getting an individual engineer to change a workflow is easy. Getting a team to adopt a new tool is harder, mostly because of the transition cost: everyone has to learn something new at the same time productivity is expected to stay high.

Here's how our team adopted mock APIs as a standard part of the development workflow, and the specific things that made it stick.

The entry point: one painful demo

I demoed what happened when I updated an OpenAPI spec, re-imported it to our mock server, and the frontend immediately got the new field without anyone updating a fixture file. That took 20 seconds. The comparison: updating fixture files manually had taken me 40 minutes that morning.

Concrete comparisons work. Abstract arguments about "better tooling" don't.

The rule we established

Any new feature that involves an API contract gets a spec written first. The mock is created from the spec. Frontend development starts against the mock on the same day the spec is approved in code review.

No exceptions. No "we'll add the spec later." Later never comes.

The onboarding improvement

Our previous onboarding for new engineers included: install Docker, run docker-compose up for the backend, set up local database, seed it with test data, configure environment variables. Half a day minimum, often longer.

Now: copy two lines into .env.local. The mock URL is already running. The new engineer is making API calls in 5 minutes.

The tool we standardized on

moqapi.dev because the mock URL is shared — everyone on the team hits the same endpoint. There's nothing to install locally. New specs deploy instantly. The free tier has been sufficient.

What still requires attention

Mocks are not a replacement for end-to-end tests. At some point in the CI pipeline, you need to test against the real API with a real database. We run a nightly integration test suite against staging for this. The mock handles daily development; staging handles pre-release confidence.

How to Test API Error Handling Before It Fails in Production

ProRecruit — Sun, 22 Feb 2026 19:52:20 +0000

Here's a thought experiment: how confident are you that your application handles a 503 from your payment provider gracefully?

If you've never explicitly tested that scenario, the answer is "not confident at all" — even if you think you've handled it. Until you see the UI under that specific condition, you don't know.

Most applications ship with incomplete error handling because development environments are too reliable. Databases are always up. APIs always respond. Auth tokens never expire during a test run. By the time you reach "test error states," the sprint is ending and you ship anyway.
he solution is systematic, not heroic

You don't need to change your development discipline. You need to change your tooling so that error states are tested during the same workflow you already use.

Chaos testing — injecting HTTP errors at a configurable rate — makes error states a normal part of every development session.

In moqapi.dev, the chaos panel lets you configure which error codes to inject (500, 503, 429, 404, 422), at what percentage of requests, and with optional latency injection to simulate slow responses.

What to do with it
Set 20% error injection rate. Use the feature you just built for 5 minutes. Every interaction has a 1-in-5 chance of failing.

Write down every broken state you find:
Blank screens
Infinite loading spinners
Forms that silently fail
Error messages so generic they're useless
No retry option offered to the user
Fix each one. Re-enable chaos. Use it again. Repeat until you can use the feature for 5 minutes without hitting a broken state.

The list of error states every feature needs
For any UI that makes an API call: loading skeleton, error message with retry button, empty state for zero results, and the happy path content. Four states. Every component. Without chaos testing, most teams ship the happy path and discover the other three in production.

The deeper benefit
Engineers who regularly test with chaos injection start writing error states as a default, not an afterthought. After one sprint of chaos testing, the Four States pattern becomes reflexive. That culture change is worth more than any individual bug it fixes.