Evolution of Front‑End/Back‑End Separation Architecture and Its Technical Support

1. Pre‑Separation Architecture (MVC)

In the early era, page logic and rendering were handled entirely by the back‑end using the classic three‑layer MVC framework, where the controller calls the model and renders the view before returning the page to the client.

Because both view and model reside on the server, front‑end code cannot run independently, leading to low development efficiency and high maintenance cost.

2. Partially Separated Architecture (RESTful)

Back‑end services expose RESTful JSON APIs while the front‑end consumes them via AJAX, binding data and rendering pages in the browser. Although this appears decoupled, the back‑end still tailors APIs to front‑end UI needs, resulting in tight data and business coupling.

3. Fully Separated Architecture

A Node.js layer acts as a service bridge built by front‑end engineers, allowing server‑side JavaScript execution for pre‑rendering and heavy front‑end logic, improving performance.

Clients include PC browsers and mobile apps (native or WebView). Mobile apps can store data locally using SQLite for offline access.

Back‑end servers are divided into web servers (e.g., Nginx, Apache, CDN) for static assets and application servers (e.g., Tomcat, IIS) for business logic, typically isolated behind internal networks for security.

Back‑end technology stack comprises Java, C#, MySQL, MongoDB, Tomcat, IIS, and middleware such as JSF and JMQ.

4. Performance Issues

The article discusses high‑performance challenges of front‑end/back‑end separation and presents solutions to improve interaction speed.

5. Stability Issues

By storing critical data (e.g., assets, earnings) in the app’s local database, the front‑end can continue displaying information even when back‑end services fail, enhancing overall system stability.