Rethinking Front‑Back End Separation: A NodeJS Full‑Stack Approach

21CTO Community Introduction: In web development, the boundary between front‑end and back‑end has long been debated, evolving from no clear concept to a tangled one. This article explores core issues of front‑back end separation, sharing experiences and insights from real‑world Web development.

Preface

To address problems of traditional Web development, we experimented with many solutions, but the physical gap between front‑end and back‑end made them similar. We reconsidered the definition of “front‑back end” and introduced NodeJS, a familiar tool for front‑end developers, to explore a new separation model.

With the rise of diverse terminals (Pad, Mobile, PC), pure browser‑side responsive design no longer meets high user‑experience demands. Different terminals often require customized versions. To improve efficiency, the need for front‑back end separation grows: back‑end handles business/data APIs, front‑end handles presentation and interaction, allowing multiple front‑end versions for the same API.

This topic has been widely discussed, and some Alibaba business units are experimenting. After extensive discussion, our team decided to explore a NodeJS‑based front‑back end separation solution, documenting our evolving understanding and inviting peers to contribute.

1. What Is Front‑Back End Separation?

During early discussions, we realized each person had a different understanding, so we first aligned on a definition.

Everyone agreed that a typical example of separation is a SPA (Single‑Page Application), where the front‑end only renders data provided by the back‑end via asynchronous interfaces (Ajax/JSONP). While SPA achieves separation, it has two issues:

SPA accounts for a small portion of Web services; many scenarios still use mixed sync/async models, making SPA not a universal solution.

Current SPA development often tailors APIs to presentation logic, causing the back‑end to handle view concerns, which is not true separation.

SPA‑style separation distinguishes layers physically (client = front‑end, server = back‑end), which no longer satisfies our needs. We argue that separation should be based on responsibilities:

Front‑end: responsible for View and Controller layers.

Back‑end: responsible only for the Model layer, i.e., business logic and data.

Why adopt this responsibility split will be discussed later.

2. Why Separate Front‑Back End?

According to Mr. Yu Bo’s article on the evolution of Web development models, different development modes have distinct suitable scenarios; none can completely replace another.

2.1 Applicability of Existing Development Modes

Back‑end‑centric MVC works well for synchronous rendering but becomes cumbersome when mixing sync and async pages.

Ajax‑centric SPA suits app‑like scenarios but faces SEO challenges and is heavyweight for many systems.

2.2 Unclear Front‑Back End Responsibilities

In complex business systems, mixing front‑end and back‑end code leads to poor maintainability because each MVC layer may contain code from other layers.

Although separation cannot fully solve this, it greatly mitigates the issue by enforcing physical boundaries.

2.3 Development Efficiency

At Taobao, the Web is largely based on an MVC framework where the front‑end depends on the back‑end. Developers write static demos, then the back‑end translates them into VM templates, a painful and inefficient process. Even with tools like VMarket, the front‑end still writes VM and relies on back‑end data, limiting efficiency. Moreover, back‑end developers remain entangled with presentation concerns.

2.4 Limitations on Front‑End Optimization

Performance optimization solely on the front‑end has limited impact; backend collaboration is often needed for techniques like Comet or BigPipe, but backend frameworks restrict their use.

3. How to Achieve Front‑Back End Separation?

The answer was already hinted in the first section:

Front‑end: handles View and Controller.

Back‑end: handles Model, business logic, and data.

With the front‑end controlling the Controller, we can design URLs, choose between server‑side rendering or JSON responses, and easily implement BigPipe, Comet, Socket, etc., based on presentation needs.

3.1 Full‑Stack Development Based on NodeJS

To realize the layered architecture, we need a web service that bridges front‑end and back‑end tasks, leading to the “NodeJS‑based full‑stack development” concept.

Common questions arise:

Why add a NodeJS layer when SPA already provides data APIs?

What is the performance impact?

Does the front‑end workload increase?

How to mitigate the added risk?

If NodeJS can do everything, why keep Java?

3.2 Why Introduce a NodeJS Layer?

Our current MVC‑centric development hampers front‑end efficiency and forces back‑end developers to handle presentation. Allowing the front‑end to control the Controller solves this, but requiring front‑end developers to learn Java and set up backend environments is unrealistic. NodeJS provides a natural solution without learning a new language.

3.3 Performance Considerations

Layered communication introduces some overhead, but clear responsibilities and optimized protocols can offset the cost, often improving overall efficiency.

For example, Taobao product detail pages need multiple asynchronous requests for logistics, promotions, etc. With NodeJS, the front‑end can proxy these requests and apply BigPipe, dramatically reducing latency on mobile devices.

3.4 Does Front‑End Workload Increase?

Yes, slightly, but eliminating extensive integration and communication steps yields a net gain in development speed and reduces testing complexity.

3.5 Controlling Risks of the Node Layer

As NodeJS scales, operations and security teams will participate in its infrastructure, ensuring stability and reliability.

3.6 Why Keep Java Alongside NodeJS?

The goal is separation, not replacing Java. Java’s mature infrastructure remains valuable for core services, while NodeJS handles presentation‑oriented tasks.

4. Taobao’s NodeJS‑Based Front‑Back End Separation

The diagram illustrates Taobao’s layered architecture with NodeJS handling the middle tier:

The top layer is the server (back‑end) exposing a collection of APIs.

Below the server sits the Node application.

Node includes a Model Proxy that communicates with the server, abstracting various interfaces for the view layer.

Node can also implement existing services like vmcommon and tms.

Developers may choose frameworks; we recommend Express + xTemplate for shared front‑back end templates.

Node enables flexible output formats: JSON, JSONP, RESTful, HTML, BigPipe, Comet, Socket, synchronous or asynchronous, depending on the scenario.

The browser layer remains unchanged.

Introducing Node simply shifts front‑end‑controlled responsibilities to the front‑end team.

Two projects are already using this model, showing improvements in development efficiency and performance.

5. What Remains to Be Done?

Integrate Node development workflow into Taobao’s existing SCM process.

Build common infrastructure modules such as session management and logging.

Establish best development practices.

Document successful production cases.

Increase community understanding of Node‑based front‑back end separation.

Address security and performance considerations.

…

Technically, most solutions already exist; the challenge lies in process integration and accumulating reusable solutions.

Translator: Chang Yin Source: https://www.kancloud.cn/kancloud/midway/48192