Optimizing Front‑Back End Collaboration with Interface Platform and Data Direct Access at Baidu

In most development scenarios, front‑end and back‑end teams pre‑define data interfaces and can work in parallel. However, large‑scale systems often have back‑end modules that are not directly connected to the front‑end, involving additional processing layers. This indirect coupling forces front‑end developers to maintain multiple environments for debugging and rendering, which degrades efficiency and developer experience.

The Baidu commercial front‑end team combined an interface platform with a data‑direct capability to improve front‑back end collaboration efficiency. The solution significantly boosted team productivity.

Practice Scheme The practice is divided into two major stages: (1) Collaboration efficiency improvement, which includes building basic capabilities and upgrading the collaboration model; (2) Quality assurance & experience optimization, which builds on the first stage to address business quality and extreme‑scenario issues.

Data Direct Capability The team’s back‑end maintains a BFF (Backend‑For‑Frontend) layer that adapts upstream data for the front‑end. To avoid the need for multiple test environments, a side‑logic periodically pulls offline material data and device identifiers (e.g., phone or browser IDs) from Redis. When a request arrives with a matching device ID, the back‑end substitutes the request with the offline data and proceeds with normal processing. The front‑end only needs to write data and device info to Redis, allowing it to see offline data while connected to the online environment, effectively providing a constantly up‑to‑date “resident” environment.

Upgrading the Collaboration Mode Using the data‑direct capability, the team introduced stub services. By marking certain data with a special flag, the back‑end can recognize the request, skip further processing, and return the stub result directly. This enables the front‑end to start development before the back‑end code is released, allowing true parallel development.

Data Grading Data usage is classified into three types: manually generated data, offline back‑end generated data, and online back‑end generated data. Early development uses editable stub data for rapid front‑end testing. During integration, data generated by back‑end code replaces stubs to ensure realism. After back‑end deployment, the front‑end retrieves real production data via the online system, guaranteeing both functional correctness and data authenticity.

Platform Experience Optimization All the above capabilities are packaged into an internal platform. Back‑end engineers edit and deliver data per project, while front‑end developers consume the data by linking devices and refreshing the app, eliminating the need for separate environment management.

Fragment‑Based Batch Editing To address the bottleneck of editing large data sets, the team introduced a “fragment” concept. Each fragment records an edit position and value, which can be applied to multiple data items, turning repetitive edits into a single operation. Fragments also support versioning, allowing the front‑end to switch between different data variants (e.g., for compatibility testing) without additional editing effort.

Conclusion The upgraded front‑back end collaboration model reduced average project delivery time by more than 50% and has been applied to thousands of business projects. Ongoing work explores extending the approach to areas such as visual acceptance and sales‑related verification, aiming to further improve collaborative efficiency across diverse scenarios.