Development Models: Frontend‑Backend Half Separation and Full Separation

Development Model

Determine requirements (product manager/leader/customer);

UI design mockups;

Frontend and backend agree on API documentation;

Parallel development of frontend and backend;

Integration of frontend and backend;

Requirement delivery (testing/launch).

Frontend‑Backend Half Separation

As shown in the diagram, this represents a half‑separated architecture.

The distinction between separation and half‑separation lies in who holds the data‑assembly logic: if the frontend does it, the architecture is fully separated; otherwise it is half‑separated.

Frontend‑Backend Full Separation

As illustrated, this is a fully separated frontend‑backend architecture.

Advantages

Complete separation means that even if services are migrated later, the frontend code does not need to change;

Better frontend adaptation and business alignment, with interface assembly performed at the BFF layer;

Clearer service boundaries for the backend;

The frontend can mock data directly at the BFF layer.

Disadvantages

Increased development cost;

The middle‑layer forwarding adds request latency.

The BFF layer is usually owned by the frontend team and is commonly implemented with nodejs to handle request forwarding and data transformation.

Architecture diagram reference:

Reflection

If a system is layered but the responsibilities of people are not, it violates Conway's Law . When only a few developers are involved, the focus should be on service aggregation rather than service splitting.