What is 'API mocking' and how does it enable frontend and backend teams to develop in parallel?
- A.API mocking creates a simulated API server that returns predefined responses matching the agreed contract (OpenAPI spec). Frontend developers can build against the mock API before the backend is ready. Backend developers implement against the spec without waiting for frontend integration. Tools: Prism (OpenAPI-based mock server), Mirage.js (in-browser mocking), WireMock, MSW (Mock Service Worker)
- B.API mocking creates a recording proxy server that captures live production traffic (a HAR file or packet capture) for later replay. Frontend developers can test against real user data before the backend is ready; backend developers replay the captures against each build in a staging network to compare results. Tools: Charles Proxy (traffic recorder), Fiddler (HTTP debugger), mitmproxy (scripted interception), VCR (cassette replay)
- C.API mocking generates load against the real backend (a stress test with synthetic users) to measure capacity. Frontend developers can profile rendering speed before launch; backend developers tune the thread pool against the generated results. Tools: JMeter (load generator), Gatling (Scala simulations), k6 (scripted tests), Locust (Python swarm)