Optimizing Front‑End and Back‑End Collaboration with Data Direct Capability at Baidu Commercial Front‑End Team

Introduction

In typical projects front‑end and back‑end agree on data interfaces and develop in parallel, but large‑scale systems often require complex intermediate modules, forcing front‑end developers to maintain multiple environments, which degrades efficiency and developer experience.

Practice Plan

The team divided the effort into two stages: improving collaboration efficiency and ensuring quality and experience. They built a BFF layer that adapts upstream data for front‑end use, but the BFF also contains strategy and aggregation logic that made local testing difficult.

Data Direct Capability

To avoid maintaining offline environments, they isolated a side‑logic that periodically pulls offline material data and device identifiers from Redis. When a request matches a stored device ID, the back‑end replaces the request with offline data, allowing the front‑end to work against a constantly updated virtual environment without extra setup.

Upgrading Collaboration Mode

Initially only request‑level data replacement was supported, which still required serial development. By adding a special marker to stub data, the back‑end can skip normal processing and return the stub directly, enabling front‑end development before back‑end code is released and allowing true parallel work.

Data Tiering

Data usage is classified into three tiers: manually generated, offline back‑end generated, and online back‑end generated. Early development uses editable stub data, integration uses back‑end‑generated data with higher fidelity, and post‑release uses live data fetched from production, ensuring both speed and correctness.

Optimizing Platform Experience

The capabilities are packaged as a platform service; back‑end teams edit and deliver data per project, while front‑end teams consume it via device connections, instantly seeing results in the app.

Further Enhancements

For complex projects with hundreds of data items, a “fragment” concept was introduced to batch‑edit data. Fragments record edit positions and values and can be applied to multiple items, drastically reducing repetitive work. Versioned fragments allow front‑end teams to switch between different data variations for compatibility testing.

Conclusion

By applying these six steps, the team achieved over 50% reduction in average delivery time, completing thousands of business projects with the new workflow and continuing to explore extensions to product visual acceptance and sales verification scenarios.