Why Front‑End/Back‑End Separation Fails and How to Do It Right

Preface: Separation Mode

After studying front‑end/back‑end separation for a while, I joined a large project that adopted this model in early 2016. The project has progressed steadily, but many issues have emerged, showing that poor preparation, not the separation model itself, causes most difficulties.

Why Separate?

From an architectural perspective, the web has always been split between browser and server. However, understanding the evolution of web development practices is essential before deciding to separate.

Common Misconceptions of Front‑End/Back‑End Separation

1. Sufficient Front‑End Staffing? Companies that previously used a backend‑centric MVC approach often had front‑end developers only deliver static HTML. In a separation model, front‑end engineers must handle view, controller, interaction code, and communication with Node.js and backend APIs, dramatically increasing their learning curve and workload.

2. Clear Division of Responsibilities? Some teams assume that after separation the front‑end only renders pages while Node.js handles routing and the backend provides APIs. Critical tasks such as caching, file upload, data validation, and internationalization are often overlooked, and Node.js is reduced to a simple proxy instead of leveraging its full capabilities.

3. RESTful Backend APIs? Many projects keep traditional, non‑RESTful APIs even after separating, which defeats the purpose. RESTful APIs clearly map HTTP verbs to resource actions, making the contract between front‑end and back‑end explicit and easier to maintain.

4. Collaboration Model? Separation can introduce communication bottlenecks; for example, front‑end developers may be blocked waiting for backend APIs. Introducing mock servers can alleviate this issue.

How to Implement Front‑End/Back‑End Separation

Overall Approach

Back‑end focuses on control layer (RESTful API), service layer, and data access layer. Front‑end focuses on control layer (Node.js) and view layer.

Project Phases

Design stage: Architecture leads analyze the whole project, decide API style, responsibility division, collaboration model, and staffing; then both sides define the interfaces together.

Development stage: Back‑end provides detailed RESTful API documentation; front‑end renders pages by consuming APIs (GET, POST, PUT, DELETE) and handling JSON/XML data.

Testing stage: Front‑end uses mock servers before APIs are ready; back‑end runs unit tests (e.g., JUnit) for APIs, avoiding mutual blocking. After APIs are completed, integration testing proceeds.

Deployment stage: Use Nginx as a reverse proxy to combine Java, Node.js, and Nginx.

Afterword

From the classic JSP+Servlet+JavaBean MVC era, through SSM/SSH Java frameworks, to modern MV* frameworks (KnockoutJS, AngularJS, VueJS, ReactJS), and now the Node.js‑driven full‑stack era, technology and architecture continuously evolve. While Node.js‑based full‑stack development is exciting, it still has many hurdles before becoming a stable, widely accepted practice. Innovation never stops; whether using separation or other models, the goal is to solve requirements more efficiently, and each model is merely a transitional station.