Why Frontend‑Backend Separation Matters: From JSP to Modern Node.js
This article walks through the evolution of front‑end architecture—from tightly coupled JSP/Servlet setups, through semi‑separated Ajax‑driven pages, to fully separated front‑end/back‑end designs with Node.js—highlighting their advantages, drawbacks, and practical lessons for developers.
The author, recently tasked with maintaining a front‑end project, shares a step‑by‑step exploration of why front‑end/back‑end separation is essential, acknowledging that many existing articles cover the topic and inviting feedback on any misunderstandings.
Unseparated Era
In the early days, MVC was implemented with JSP and Servlets, where every request was handled by a controller Servlet that dispatched to JSP views. Templates like Velocity or Freemarker could be used to clarify responsibilities and boost efficiency.
Two main approaches existed:
Approach 2 gradually fell out of favor because the front‑end depended heavily on the back‑end and fewer developers knew JSP, Velocity, or Freemarker. Approach 1 remains in use at some small traditional firms, but both share common drawbacks.
I. Front‑end cannot debug independently
When a style issue appears, the front‑end often lacks a proper development environment, leading to frustrating back‑and‑forth conversations:
前端: "我这里没问题啊。后端，你那里正常么？"
后端: "我这里不正常啊。要不你过来看一下吧?"
前端: "一时我也看不出问题，我也没环境，怎么办？"
后端: "你没环境，坐我这边调吧。"This dependence reduces development efficiency and can cause internal conflicts.
II. Front‑end inevitably encounters back‑end code
Embedding Java code in JSP pages tightly couples the layers, forcing front‑end developers to learn template‑engine syntax and increasing learning costs:
<body>
<%
request.setCharacterEncoding("utf-8");
String name = request.getParameter("username");
out.print(name);
%>
</body>Even with Freemarker or Velocity, writing Java inside templates is undesirable.
III. JSP‑specific issues
JSP pages load slowly on first run due to servlet translation, and heavy pages suffer from synchronous loading, degrading response times.
Semi‑separated Era
In this stage, the front‑end renders pages using Ajax to fetch data and DOM manipulation to bind it, essentially combining Ajax with SPA concepts.
Typical workflow:
(1) Browser requests HTML from CDN.
(2) JavaScript in the page calls back‑end RESTful APIs via Ajax.
(3) API returns JSON; the page parses it and renders via DOM.
Advantages include front‑end isolation from back‑end code, easier debugging, and independent mock data. However, drawbacks are evident:
Redundant JavaScript grows complex with business logic.
Large JSON payloads cause slow rendering and page lag.
SEO suffers because crawlers cannot index asynchronously rendered content.
Resource consumption spikes, especially on mobile where each HTTP request is costly.
These limitations motivated the emergence of fully separated architectures.
Separated Era
Here the front‑end takes responsibility for both View and Controller layers, while the back‑end focuses solely on Model (business logic and data). Node.js often serves as a middle layer, enabling front‑end developers to handle controller logic without learning a new back‑end language.
Benefits of adding Node.js as a middle layer
(1) Improved adaptability
Different front‑ends (PC, mobile, app) share most business logic; only presentation differs. A Node.js layer centralizes controller code, reducing coordination overhead between front‑end and back‑end.
(2) Faster response
Node.js can perform lightweight data transformations before sending results to the front‑end, offloading simple logic from the back‑end and improving latency, especially with large data sets.
(3) Better performance
By aggregating multiple back‑end calls within the internal network, Node.js reduces the number of external HTTP requests, which is critical for mobile performance.
Drawbacks of Full Separation
For small‑to‑medium companies, adopting a fully separated architecture can be risky.
(1) Personnel issues
These architectures assume abundant front‑end resources; forcing back‑end engineers to learn Vue.js or Node.js increases workload and may lead to turnover.
(2) Slower product iteration
Additional API design and front‑back‑end coordination steps lengthen the development cycle.
(3) Front‑end must learn business logic
When the controller layer moves to the front‑end, developers need deep domain knowledge, which can be burdensome but also opens a path toward front‑end architecture expertise.
Conclusion
The article reviewed the three stages of front‑end/back‑end architecture—unseparated, semi‑separated, and fully separated—explaining their evolution, pros, and cons. The author cautions small teams to use separation judiciously and invites readers to point out any inaccuracies.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java Backend Technology
Focus on Java-related technologies: SSM, Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading. Occasionally cover DevOps tools like Jenkins, Nexus, Docker, and ELK. Also share technical insights from time to time, committed to Java full-stack development!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.