Some water friends left a message in the comments and asked me:
Mr. Shen, I am in a startup company with a R&D team of about 20 people. The team is pushing forward the separation of front and back ends. I think the architecture has become more complicated and the project development cycle has become longer, but the team leader said that Internet companies are all engaged in separation of front and back ends, so we have to do it. I still don’t understand why we need to separate the front and back ends?
Today, briefly, the Internet layered architecture in the
front and rear ends of the splitter
.
Voiceover: "Others are doing xxoo technology" must not be a reason for a company to promote "xxoo technology".
The figure above is a typical Internet layered architecture:
(1)
Business site layer
: web-server;
(2)
Business service layer
: biz-service;
(3)
Basic data service layer
: data-service;
(4)
Data storage layer
: db+cache;
With the passage of time, the business has become more and more complex, and more and more revisions have been made. At this time, although the web-server layer of the business site layer uses the MVC architecture,
are the following pain points familiar?
(1) The product pursues beautiful effects and requires high device compatibility. These requirements continue to torture Java engineers who use MVC;
Voiceover: This article uses the Java backend as an example.
(2) Regardless of whether it is a PC, a mobile phone H5, or an APP, the change frequency of the front-end application is far greater than the change frequency of the back-end logic. Changing the velocity template is not a job that Java engineers like and are good at;
Voiceover: Thanks to those product managers who like to make revisions.
At this time, in order to alleviate these problems, usually set up
separate front-end FE sector
, responsible for interacting with the show's development, its functions and back-end Java engineers separated,
but the pain point is really solved?
(1) A little display of changes requires Java engineers to recompile, package, go online, and restart tomcat, which is extremely inefficient;
(2) The original Java engineer was responsible for all MVC R&D work. Now it is divided into two parts: Java and FE. It is necessary to wait for the front-end and back-end to complete the R&D before debugging the overall effect together. This not only increases the communication cost, but any problem occurs May cause project delay;
Voiceover: Have you ever been tortured?
To be more specific, look at an example of this. At the beginning, the product only had a PC version. At this time, the system layered architecture is as follows:
The client, web-server, and service are very clear.
With the development of the business,
products need to add a Mobile version
. Most of the business logic of the Mobile version and the PC version are the same.
What is the difference?
(1) The number of pieces of information displayed will be relatively small, that is, when the service service is called, the parameters passed in will be different;
(2) There will be fewer product functions, most services are called the same, and a few services do not need to be called;
(3) Display and interaction will be different;
Due to the tight schedule, how does the Mobile version of web-server generally come from?
That's right,
make a copy of the PC version of the project
, and then make a small amount of modification:
(1) Some changes in the parameters of the service call;
(2) Most service calls are the same, but a few service calls are removed;
(3) Modify the display and interaction related code;
Voiceover: Have you copied the code?
The business continues to develop, and the
product needs to add an APP version
. The business logic of the APP version and the Mobile version are exactly the same.
What is the difference?
(1) The Mobile version returns data in html format, and the APP version returns data in json format, and then performs local rendering;
Due to the tight schedule, how does the APP version of the web-server generally come from?
Yes,
make a copy of the Mobile version of the project
, and then make a small amount of modification:
(1) Modify the code for assembling html data to assembling json data;
With such an iterative evolution, what will the architecture evolve into?
(1)
Terminal
: PC, Mobile, APP;
(2)
Station application layer
: PC station, M station, APP station;
(3)
Service layer
: general business services and basic data services;
Do the dependencies in this architecture diagram look awkward?
(1) The connection relationship between the end and the web-server is very clear;
(2) The connection relationship between web-server and service becomes a spider web;
What are the possible problems with the above-mentioned layered architecture?
Most of the business of the web-server layer of PC/H5/APP is the same, only a few logic/presentation/interaction are different:
(1) Once a service RPC interface changes slightly, all web-server systems need to be upgraded and modified;
(2) There are a lot of code copies between web-server;
(3) Once the code is copied, a bug appears, and multiple subsystems need to be upgraded and modified;
How to make data acquisition more efficient and fast, and how to decouple and separate data production and data presentation?
Hierarchical abstraction with separation of front and back ends is imperative.
Hierarchical abstraction through separation of front and back ends:
(1)
Site display layer
: node.js, responsible for data display and interaction, maintained by FE;
(2)
Site data layer
: web-server, responsible for providing business logic and json data interface, maintained by Java engineers;
What are the benefits of doing this?
(1) Complex business logic and data generation, only written once at the site data layer, no code copy;
(2) The underlying service interface has changed, and only one part of the site data layer needs to be upgraded and modified;
(3) If there is a bug in the underlying service, only the site data layer needs to be upgraded and modified;
(4) The site presentation layer can pass in different parameters according to different forms of products, and call different site data layer interfaces;
In addition, there are many other advantages:
(1) The product pursues brilliant effects and has high requirements for device compatibility. It no longer troubles Java engineers and is connected by a more professional FE;
(2) A little bit of display changes, no longer need Java engineers to recompile, package, go online, restart tomcat;
(3) After agreeing on the json interface, Java and FE are developed separately, and FE can use the mock interface for self-test, no longer waiting for joint debugging;
Ever since, as shown in the figure above, the
architecture has evolved and the front and back ends are separated.
When the business more complex, more and more products on the end of the presentation layer changes faster and faster, more and more there is a lot of code to copy the site level, data acquisition complexity become common pain points when it should be carried out
before and after Separation and hierarchical abstraction of the end
, simplifying the data acquisition process, improving the efficiency of data acquisition, and shielding the complexity of the bottom layer upstream.
In addition, it should be emphasized that whether the front-end and back-end separation is required is related to the complexity of the business, the stage of business development, and the personnel quality model. It must not be generalized.
To implement front-end separation, the following four points must be considered. The first point is SEO considerations.
If it is a PC-side site, you need to consider whether you need to strongly support SEO, and the front-end and back-end separation architecture is likely to be unfriendly to search engine spiders, which may affect the site's inclusion.
Of course, if it is a native APP, the backend node.js only returns json data, or a single-page application SPA (a page for Baidu), you do not need to consider this issue.
The second point is the consideration of product characteristics.
Many products pursue cool front-end effects, and have high requirements for front-end compatibility. The frequency of front-end product revisions is very high, so separation of front-end and back-end is necessary.
Otherwise, the separation of front and back ends will only bring more complexity to the system architecture.
The third point is the company's development stage.
In the initial stage of the company's development, there are fewer people and higher requirements for product iteration speed. At this time, more full-stack engineers are needed, and one person develops from front to back. If the front-end and back-end separation is implemented at this time, the term "joint debugging" will be introduced, and the communication cost ratio will be increased, which may result in a reduction in the speed of product iteration.
Fourth, consideration of personnel skills.
The traditional way of cooperation between FE and back-end Java/PHP engineers, FE engineers do not need to have deep back-end skills. Once the separation of front-end and back-end is introduced, the front-end students of the node.js layer need to know more about the back-end knowledge system. Some FE students' rejection of back-end skills caused personnel instability.
In short, the separation of front-end and back-end is not just a hierarchical technical decision, it is related to SEO, product characteristics, company development stage, and personnel knowledge system. It must not be generalized.
Any architecture design that is out of business is a rogue.
I hope you all gain.