Separating the front and back ends allows each end to become more focused. Today’s topic, in light of my previous project scenarios, reconsiders the definition of “front and back end” and discusses “Front and back End Separation, Best Practices”. Best practices for separating the front and back ends Blog post: blog.720uprise

What is the front end separation

To review the traditional MVC pattern, the client sends an AJAX request, the server receives the request and returns JSON data back to the client, which parses the JSON for page rendering.

Nowadays, in order to improve the development efficiency and refine the responsibility, the need to separate the front end and the back end is more and more important, with the server side responsible for the business/data interface and the front end responsible for the presentation/interaction logic. If we treat the browser side as the front-end and the server side as the server side, we can transform the ABOVE MVC pattern into the front and back end separation pattern.

Why is it necessary to separate the front and back ends

With the separation mode of front and back ends, front-end personnel pay more attention to interface presentation/interaction logic, while server personnel pay more attention to business/data interface, with clear division of labor and clear responsibilities.

  • Front-end responsibilities: page UI, page display, interaction, rendering, user experience, etc.
  • Back-end responsibilities: data storage, business logic, RESTful interfaces, performance, availability, scalability, extensibility, security, etc.

Also, what a great design when we have multi-end scenarios, for example, a server RESTful API, in which the Web/iOS/Android/PC/U3D front end makes no difference to the back end.

Front and rear end separation, best practice

Simple separation mode

The solution we adopt is REST service, a lightweight Web service. The client sends AJAX call RESTFul API request to the server, and the server sends the response result in JSON format to the client after receiving the request, thus completing an interaction.

Server-side rendering mode

This model can basically meet the needs of our general products. However, for products that need to do SEO, this approach is a bit inadequate. Because important content is assembled asynchronously at the front end and cannot be indexed by search engines, server-side rendering must be considered for SEO.

Server rendering mode, combined with my previous project scenarios, to list two ways.

Method one, JSP rendering

Render via JSP. This approach, in effect, involves adding Java code to the front-end project and rendering it using JSP as a template.

Method two, static page rendering

Static pages are generated by FreeMarker for rendering. In this way, scenarios such as static and static separation and CDN distribution need to be considered.

Node.js rendering mode

One important problem with the above scenario is that the front end personnel need to be involved in Java technology and can’t achieve the decoupling of the front and back ends. With the spread of Node.js technology, we’ve taken rendering out of the server side and moved it to the front end with a clear division of responsibilities between the front and back ends.

conclusion

Moving from the traditional MVC pattern to the front – and back-end separation allows each side to become more focused. Today’s topic, the main brief introduction of simple separation mode, JSP rendering mode, static page rendering mode, Node.js rendering mode.

(after)

More wonderful articles, all in the “server-side thinking” wechat public account!