Frontend

A Front-End API Layer That Decouples UI Work From Back-End Readiness

By 东风破_ · Aug 12, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

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.

Summary

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.

Takeaways

— An Axios instance with a centralized baseURL lets every API call switch between mock and live back-ends by changing a single line of config.

— API modules expose business functions like `getTodos()` instead of raw Axios calls, so components never know request URLs or parameter shapes.

— Mock.js interceptors in Vite return fake data with configurable latency, letting developers test loading states and full data flows without a back-end.

— React Router handles all navigation client-side; lazy-loaded page components with Suspense keep initial bundle sizes small.

— Zustand provides shared state without Redux-style boilerplate, keeping global state management lightweight and opt-in.

— The back-end uses Koa 3 with async/await middleware and MySQL, but the front-end architecture treats it as a pluggable data source.

Conclusions

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.

Concepts & terms

Front-end API engineering

A structured approach where the front-end maintains its own API layer—Axios instances, per-module request functions, and mock interceptors—so UI development and data fetching are decoupled from back-end availability.

Mock.js + Vite plugin interception

A Vite plugin that intercepts HTTP requests matching configured URL patterns during development and returns predefined fake data, optionally with simulated network latency, so the front-end runs without a live server.

Zustand

A lightweight React state management library that creates global stores with a single `create` call, avoiding the action/reducer/dispatch ceremony required by Redux.

Koa 3 onion model

Koa's middleware architecture where each async function wraps the next, allowing code to run both before and after downstream middleware—useful for logging, error handling, and response modification.

From the discussion

Mocking is treated as a disposable crutch that wastes time when back-end structures inevitably shift, while a mapping layer that decouples front-end calls from real endpoints is acknowledged as workable but criticized for adding its own complexity. The core tension is whether the upfront cost of mock data and abstraction layers pays off against simply waiting for back-end readiness.

— Mock data is static and cannot support dynamic, interactive UI behavior.

— Interface fields and structures almost always change during development, making mock data a one-time throwaway.

— Building mock data for complex interfaces consumes significant time that could be spent on other tasks.

— Front-end work should start only after back-end development reaches roughly 50% completion.

— Without interface documentation, the front end cannot know the number of endpoints or the shape of request/response parameters.

— A mapping layer between front-end calls and real back-end interfaces is feasible but introduces additional complexity.

See top comments, translated →

Source: juejin.cn ↗ Google Translate ↗ Backup ↗