preface
Front and back end separation has always been a concept that everyone has heard about, but not quite understood. What is front end separation? Why do we separate the front end from the back end? What are the benefits of anterior-posterior separation? What are the problems with front and rear end separation? These questions may be more or less unknown to everyone. Today, let me take you to understand the front and rear end separation of some small knowledge.
What is front end separation
Front and rear end separation, as the name implies, is the separation of the front end from the back end. Separate what? Develop separately, deploy separately.
Here take Java Web development as an example: When we learn Web development, we will come into contact with the Spring MVC framework. In spring MVC development, JSP is generally used as the display page in the front end, and servlet is used to process requests in the back end. Moving to the Springboot framework, the front end uses Thymeleaf or Freemarker as a template engine for presentation, and the back end uses controllers to handle requests.
JSP and Thymeleaf and Freemarker all have one thing in common: pages can be embedded with Java code. The embedded Java (Back-end Programming Language) code in the pages leads to a very high coupling between the pages and the back-end services – they are stuck together during development.
If we were to deploy a Spring MVC/SpringBoot project, the front and back end code would be packaged in a WAR/JAR package and deployed together, resulting in the front end being repackaged/back end being changed — the front and back end being stuck together.
What does it mean to develop separately? That of course is the front-end page only write HTML + JS + CSS, back-end do not write JSP, do not use thymeleaf template engine to do HTML rendering.
What does it mean to deploy separately? Split the front-end and back-end projects into two parts and deploy them to the server.
Therefore, front-end projects and back-end projects are developed separately, and those deployed separately are considered front-end and back-end separated.
Why do we separate the front end from the back end
It is difficult to update and maintain large projects
As we all know, once a project is developed, it is always updated and maintained. Every time the project is updated, new features will be added, the amount of code will increase, and the project will get bigger and bigger. If adopt the mode of the development of the front and back side are not isolated, before and after the update iteration for the front-end and back-end engineers or full stack engineer is also great pressure: when a page need to front-end and back-end engineers to do well together, for them, communication may be more headache than code; When a project development team is full of full-stack engineers, the first headache should be how to recruit qualified full-stack engineers as the project gets bigger — after all, full-stack engineers are more demanding on programmers. And when the front-end page or back-end interface fails, we have to repackage and compile the entire project to update and maintain the project, and the larger the project, the longer the packaging and compilation takes.
Project coupling is too severe to reuse
As mentioned above, if you use a template engine or a special page like JSP, you will be writing Java code on the page. Reusing code can be extremely difficult: every time you reuse a back-end interface, you have to modify the front page and add Java code to it.
Project loading is more resource and time consuming
To load a page that uses Thymeleaf, we first need to call the Thymeleaf engine to parse the Java code on the page, and then render the page, whereas static pages simply render directly. If our project needs to carry more concurrency, we can only deploy multiple packages with the combination of front and back end to expand the system performance, but this also wastes some resources.
What are the benefits of anterior-posterior separation
Improve front-end and back-end development efficiency
The front end and the back end can be separated, each doing its own thing, each doing what they’re good at: the front end only handles HTML, CSS and JS, and the back end only handles Java. As long as the interface documents are discussed and determined, even the development schedule can be different: js is used for mock data test in the front-end, and interface testing tools such as Postman are used for interface testing in the back-end.
Project updates and maintenance become easier
When we need to update and maintain the front end page, we just need to fix the bugs of the front end project, and then package and deploy the front end project, and the back end is the same. And when the team needs to expand, people who excel in a single role (front/back) are easier to find.
Improve interface reuse rate
If we need to develop a similar project, or reuse back-end modules from previous projects, we just take the modules out and make minor changes. Instead of having to go through the hassle of porting Java code from the interface’s old page to the new page (and even causing incompatibilities).
Make pages load faster
We deploy the front end as a static page that the user only needs to access. A normal HTML page is definitely faster than a template engine like Thymeleaf, which takes an extra step to parse the interactive code, and sometimes it’s more than that. We could even introduce NodeJS as an intermediate island, and put the front-end page rendering on NodeJS for processing, rendering the results directly back to the browser.
Improves server resource utilization
If we need to expand the concurrency of the system, we just need to subcontract the front-end pages within the QPS of the back-end interface and do a good job in load balancing. There is no need to subcontract the entire project to deploy, especially to deploy multiple back-end services, which are particularly demanding on server resources. If the QPS of the backend interface is exceeded, the backend will of course have to be subcontracted.
Problems with front and rear end separation
Cross-domain Problems (CORS)
Cross-domain problems should be the most common problem. Cross-domain problems arise when we use Ajax for data requests. The solution to this problem is also extremely simple, and can be solved by adding access-Control-Allow-Origin to the returned request header. There are different Settings for different application scenarios, and baidu can answer this question faster than anything else.
Single sign-on problem
This problem was also encountered recently when I was engaged in project docking. Specifically, when the single point authentication of CAS was connected, the single sign-on interface requesting service was directly connected to the portal website, and this interface was connected to the back end instead of the front end. When we access the single sign-on link of the access application from the portal, the request is sent directly to the back end. Since nodeJS is not connected to the front end, there is no way to send requests directly to the front end for login authentication. If the whole authentication process is carried out in the back end, the front page cannot get the JWT after login normally. Therefore, the token and JsessionID generated should be written into the authentication processing page of the front end at the time of the first step request for page hopping and further login authentication.
conclusion
There’s only so much a blogger can say about front and back end separation. If there are any points that haven’t been covered, please add them. For the time being, that’s all I can think about when it comes to the problems of front and back end separation. If other problems are encountered in the future, they will be supplemented.
Finally, I hope this article can bring you some help.