Why static mock APIs break modern frontend workflows — and how stateful session mocks fix them

# The problem in practice Most frontend developers start UI work before the backend is ready and rely on static mock APIs or local db.json files. These mocks usually implement a stateless echo. A POST returns 201 and a fake id, but the server discards the payload immediately. The UI sees a successful response, but a later GET for the same resource returns the original seed data or 404 — the created item has vanished.

# Why that matters now Modern frontend stacks use query caching, optimistic updates, and reactive stores. Those patterns assume the server's state reflects mutations. When it doesn't, three concrete developer workflows break:

• Cache invalidation fails: Libraries such as TanStack Query expect invalidate/refetch to surface the new state. With static mocks, invalidation issues a GET that returns the seed list, causing flicker and disappearing items and forcing developers to add brittle client-only workarounds.

# The alternative: stateful, session-scoped mocks You don't need a full database per prototype. The pragmatic option is stateful API mocking that keeps mutations only for the calling session. Key components of this approach:

• Shared read-only seed data: A common baseline collection (users, posts, comments) is available to every client as immutable seed records.

• Session identification: Each client gets a session cookie or header that identifies its sandbox.

• Overlay interception: When a request mutates data (POST/PUT/PATCH/DELETE), the change is recorded in a temporary per-session overlay table rather than a global DB.

• Dynamic merge on read: On GET, the engine merges the seed dataset with the session overlay to produce a response that includes created records, applies patches, and excludes deleted IDs.

From the frontend's point of view, the API behaves like a regular backend. You can POST to create, then GET the created resource by id, and the item persists for your session.

# How this changes development

# Example workflow (conceptual)

1. 1Client A posts a new item. The overlay records the created record under that client's session.

1. 1Client B, without that session, sees only seed data.

This keeps local experiments deterministic and prevents cross-developer interference.

# Practical takeaway If your team relies on query caches, optimistic updates, or needs to validate edit/delete flows, replace simple static mocks with stateful, session-based mocks or overlay-based tools. They require no production database, but they produce the server-side behavior your frontend expects, reducing brittle client workarounds and making development and testing more reliable.