Reprinted from: https://www.cnblogs.com/shanrengo/p/6397734.html
Table of contents
Misunderstanding about separation of front-end and back-end?
How to separate front-end and back-end?
Preface: Detached Mode
I have been researching the front-end and back-end separation for a while. It happened that the company had a big project and decided to try to use the front-end and front-end separation model, so I got involved. The project has been going smoothly since its establishment in early 2016, but more and more problems have emerged. It is definitely not that the front-end and back-end separation model is not good, but that many companies have not done enough when trying to separate the front-end and front-end. Have to prepare.
Articles introducing the separation of front-end and back-end are common on the Internet. Next, I will talk about this in a few superficial words, which is embarrassing.
Why separate?
If you just ask "Is the separation of front-end and back-end significant?" this is nonsense, because from the perspective of software architecture, the front-end and back-end of the Web have always been separated from the beginning, and browser and server may always be separated.
In order to understand this problem, we need to first understand the evolution of the Web's R&D model. Regarding this topic, the following blog post talks about it well, so I won't do the porter here.
https://github.com/lifesinger/blog/issues/184
We cannot "separate for the sake of separation", but should "separate in order to truly understand web development and to better complete the requirements."
Misunderstanding about separation of front-end and back-end?
1. Is the front-end staffing sufficient?
Because the company's previous projects adopted a traditional development style, that is, a back-end MVC-based development model, the front-end staff only provided static HTML pages, and the rest of the work was completed by the back-end developers. Adopting the front-end and back-end separation model can reduce the back-end burden and speed up research and development efficiency. Of course, the premise is that the front-end can be done well. In the past, front-end personnel who only needed to provide static pages were responsible for the view+controller part of the project in the front-end and back-end separation mode. That is, in addition to the static pages, they also needed to be responsible for all the interactive code of the page, as well as the interaction between nodejs, the view layer, and the back-end API. Work undoubtedly increases the learning costs of front-end personnel. Without sufficient knowledge and talent reserves, front-end personnel can only be made to work overtime. As a result, a large number of front-end staff resigned (PS: After doing so many things, your salary must be increased!)
2. Distribution of front-end and back-end responsibilities?
Many companies believe that after separating the front and back ends, the front and back ends only need to interact through designated APIs. The front end is responsible for page rendering, Nodejs is responsible for routing distribution, and the back end provides APIs. A large number of key tasks have been ignored. There is no corresponding documentation on responsibilities distribution and detail processing. There is no corresponding information on caching mechanism, image upload and download, data verification, language internationalization, etc. In addition, a large number of people ignore the role of the nodejs layer and only regard nodejs as a routing relay. This aspect is also caused by the unfamiliarity with nodejs technology. In fact, nodejs can be responsible for many things. In addition to complex business logic processing and data operations, Java is responsible for it. A lot of work can be handled entirely at the nodejs layer. (PS: It’s still caused by insufficient foundation!)
3. Is the backend API Restful style?
After many companies adopt the front-end and back-end separation model, the back-end API still uses the traditional style, which is unreasonable. Restful-style API should be the best practice for front-end and back-end separation. ResultFul recommends that each URL can operate a specific resource, and can accurately describe the server's processing actions on the resource. Usually the server supports get/post/put/delete/, etc. for resources, which is used to add, delete, modify, and check resources. If the front-end and back-end are separated, these api-urls are the bridge for docking. Only by using the resultFul interface can the meaning of the address be clearer and more understandable. (PS: After using Spring 4.x, I still don’t use rest style, which is unreasonable)
4. Front-end and back-end collaboration model?
After the front-end and back-end are separated, whether it is the docking of the API interface or the testing work, it involves communication between the front-end and the front-end personnel. After many companies adopt the separation of the front-end and the front-end, the cooperation model of the front-end and the back-end is weak, waiting for each other, and the development efficiency is low, but it is not as good as the traditional one. development model. For example: when the back-end API has not been written, the front-end cannot be debugged, which results in the front-end being blocked by the back-end. In fact, this mutual waiting model needs to be improved, and Mock Server may be able to solve some problems.
How to separate front-end and back-end?
How to separate front-end and back-end? The general direction is
The backend focuses on: backend control layer (Restful API) & service layer & data access layer;
The front-end focuses on: front-end control layer (Nodejs) & view layer
I think the front-end and back-end separation model should be like this, but of course this is not necessarily correct:
1. During the project design phase, the person in charge of the front-end and back-end architecture will analyze the overall project, discuss and determine the API style, responsibility allocation, development assistance model, and determine staffing; after the design is determined, the front-end and back-end personnel will jointly formulate the development interface.
2. In the project development stage, the front-end and back-end are separated by their own division of labor and collaborative agile development. The back-end provides Restful API and provides detailed documentation. The front-end staff performs page rendering and the front-end task is to send API requests (GET, PUT, POST, DELETE etc.) get the data (json, xml) and then render the page.
3. In the project testing phase, before the API is completed, the front-end staff will use mock server to conduct simulation testing, and the back-end staff will use junit to conduct API unit testing without waiting for each other; after the API is completed, the front-end and back-end will be tested together. Of course, it will not Not all interfaces can be defined in advance, and some are adjusted during the development process.
4. In the project deployment phase, nginx is used as a reverse proxy, that is, Java + nodejs + nginx.
Editorial
From the classic MVC era of JSP+Servlet+JavaBean, to the Java framework era of SSM (Spring + SpringMVC + Mybatis) and SSH (Spring + Struts + Hibernate), to the main front-end frameworks (KnockoutJS, AngularJS, vueJS, ReactJS) In the MV* era, and then the full-stack era led by Nodejs, technology and architecture have been advancing. Although the "full-stack development based on NodeJS" model is very exciting, there is still a long way to go to turn full-stack development based on Node into something stable and acceptable to everyone. The road of innovation will not stop. Whether it is the front-end and back-end separation model or other models, they are all to solve the needs more conveniently, but they are just a "transit station".
You may pass through more and more "transit stations", but don't drift away.