A Front-End API Layer That Decouples UI Work From Back-End Readiness
Blocked front-end teams burn schedule waiting for API contracts. A one-line baseURL switch between mock and live back-ends removes that bottleneck and enforces a clean separation of concerns that pays off long after the initial build.
Front-end teams routinely stall waiting for back-end APIs. A full-stack Todos demo lays out a three-layer front-end API engineering pattern that breaks that dependency: an Axios instance with a configurable baseURL, per-module API functions that hide request details from components, and a Vite-integrated Mock.js layer that intercepts calls and returns fake data with simulated latency. Components call the same `getTodos()` function regardless of whether data comes from mock interceptors or a live Koa server.
The architecture keeps components pure—they fetch data and render, never knowing its origin. Routing, lazy-loaded page components, and Zustand for shared state round out a front-end that can be developed, tested, and demonstrated independently. When the back-end is ready, flipping the baseURL from `/api` to `http://localhost:3000` redirects every request to the real server with zero component changes.
Koa 3 is introduced as the planned back-end, with MySQL for persistence, but the front-end's independence means that work can proceed in parallel. The project treats front-end API engineering not as a stopgap but as a permanent architectural layer that enforces a clean contract between UI and data fetching.
Many teams treat mock data as a temporary hack, but this pattern treats the mock layer as a permanent architectural fixture that enforces a contract between UI and data fetching.
The real decoupling in front-end/back-end separation is not React versus Node—it is whether the front-end can run its complete data flow without the back-end being alive.
Encapsulating Axios behind module-level functions means back-end API changes never cascade into component code, which is a stronger separation than most teams achieve.
Simulating network latency in mock responses is an underrated practice; without it, loading states and error boundaries go untested until integration, where they are costlier to fix.