Front and rear end of the separation is essentially a refinement of job duties. This separation of the rear end two years ago, more and more voices rising, the most important reason is that the back-end engineers can not simply complete front-end aspects of the job. Since the front end of this time the new technologies emerging, in which case the back end can not grasp simple front-end technology, even if there is a certain burden on the front. Increasing the threshold of the front end, a person can not be all things are done, but also the one hand, the separation factor of the front and rear end.
A typical business scenarios
before and after the end of the separation in fact it is not a panacea, corresponding to different business scenarios the situation will be different. The same scenario is also different, with a front end of a conventional PC-side application scenario, a mobile terminal, also App hybrid, applets. Technology will be different for different application scenarios used, many application scenarios architecture allows higher complexity of the change.
Before and after the end of the separation benefits
can achieve true before and after the end of the decoupling front-end server using nginx. Front-end / WEB server put the css, js, images, and so on a series of static resources (You can even css, js, images and other resources into a specific file server, such as Ali cloud oss, and use the cdn acceleration), the front end server responsible for controlling page references & Jump & routing, call the back end of the front page of asynchronous interfaces, backend / server application using the tomcat (tomcat to imagine a data provider) to speed up the overall response rate. (It should use some of the front-end engineering framework such as nodejs, react, router, react, redux, webpack)
found bug, who can quickly locate the problem will not pass the buck to each other phenomenon. Page logic, jump error, browser compatibility issues, script errors, page styles and so on, all to be responsible for the front-end engineers. Interface data error, the data is not submitted successfully, the response timeout problems all solved by the backend engineer. The two sides without disturbing each other, love each other front and back of the family.
In large concurrent case, I can scale horizontally while the front and rear end servers, such as Taobao will need a Home 2000 + front-end server clusters to do withstood daily how many billions of daily + pv.
Concurrent reduction in back-end server / load pressure. In addition to all the other interfaces http requests all transferred to the front nginx, request interface calls tomcat, reference nginx reverse proxy tomcat. And in addition to the first request for a page, the browser will call a large number of local cache.
Even if the back-end service is temporarily out or goes down, the front page will be a normal visit, but the data do not brush it out.
Maybe you also need a micro-channel light-related applications, so you can share the interface, if there are app-related services, as long as through some code refactoring, you can also reuse a lot of interfaces, enhance efficiency. (Multiport applications)
something more page displayed is not afraid, because it is loaded asynchronously.
nginx supports hot deployment page, without restarting the server, front-end upgrades and more seamless.
Increased maintenance & legibility (Code read front and rear ends are coupled together rather strenuous).
Enhance the development efficiency, since the front and rear end can be developed in parallel, rather than the previous strong dependence.
Nginx deployed in the certificate, extranet access using https, and only open ports 80 and 443, all other ports closed (to prevent hackers from port scanning), intranet use http, performance and security are guaranteed.
The front end of a large number of code components to reuse, component, improve development efficiency, to out!
Technical challenges
we encountered many technical challenges in terms of front-end, the most important thing in the large flow requirements of high availability. The number of perception will be significantly increased under high flow, all aspects of the problems encountered will also increase, such as network, slow interface problems. For high-volume front-end can be used CDN withstood way, when the pressure of the back-end will be relatively large. When the back end could not carry when you need to share the front part of the pressure, so that the user can not perceive the problems resulting page, high-availability requirements of this case will be very high. The second point is that all front-end engineers are very annoying problem, high browser compatibility requirements. There is a more troublesome technical support SEO for SEO are not a lot of technical support, such vue, react this MVVM framework can not be used.
Front and rear ends of common technical pros and cons of
technology solutions
technology solutions we mainly use four types: front-end template (Ajax + String template), MVVM (Vue, React) , Node template (Express + ejs), SSR ( Node + Vue SSR). This program is one of the oldest Ajax + string template, which essentially is the string concatenation.
Browser compatible
either the server or render the usual rendering support IE6 +, using SSR or Node do render in the browser will be compatible aspects of relatively weak. MVVM framework based on modern technical solutions, and also at a disadvantage, compatible with the requirements of the occasion in the browser can not be used.
SEO support
for web SEO have requested, the use of web templates and Vue program is not suitable. Relatively speaking web templates a little better, you can add some introductory classes before the page is not rendered. Node and SSR in terms of SEO is not the problem, they are server-side rendering, the first screen will contain enough data.
The first screen rendering time-consuming
now a variety of technical solutions for first-screen rendering time-consuming, apparently using Node is the fastest. After all, it is a server-side rendering, data is acquired to the service provider by the end of the service Node. SSR rendered to spend time with respect to the Node will be more than 30% -50%. Vue Web template and then load the data are read, which would be time-consuming rendering Vue longer. Overall, rendering time-consuming aspects of MVVM framework of the first screen is the slowest.
Asynchronous interface speed
after the first screen is loaded, the page will have a lot of lazy loading, need to request the appropriate data interface to the server. MVVM framework in this regard and web templates are directly connected to the back-end, and Node and SSR programs use Nodejs do interlayer forward once consumed part of a network connection, extra Node is a server to the service provider's service.
High Availability
Web template is no doubt that in terms of high availability is to do the best, as long as the back-office services provider did not hang, in general, not a Web template too many problems. MVVM situation will be more complicated in the browser compatibility requirements are higher, the amount will be more tests, but I fear some places will not test.
Node as an intermediate platform not only care about the front end of CDN Also note that Node server will not be a problem, so that each one more link will be some difference in terms of high availability. The SSR not only to have high availability requirements on the Node, if the front and rear side code also introduces isomorphism, isomorphic codes there may be various problems on the Node. Based on this situation we believe SSR in terms of high availability is the worst.
Technical barriers
on the choice of technology must first consider the appropriateness of the current team, a different team situation will be different. Take the technical aspects of the school recruit threshold is generally on the web template will not be much problem, MVVM frameworks such as Vue could understand one of the more familiar but is relatively less. Web templates and Vue or at least in terms of the front end, while Node situation is a bit different, its knowledge of the complex front-end for a lot. SSR situation even worse, not only need to know the knowledge Node aspects also need to know how to run the same set of code on the Node, as well as the operation of the SSR framework, so the threshold will be higher.
Front and rear end separation
using a web template or MVVM framework needs at least and operation and maintenance personnel to find servers with the placement of a page, and how much will be some back-end aspects of contact. And use Node middleware can solve all problems independently.
Three questions
when talking about the framework of landing, I always have three questions, the first question is whether the items you need SEO. If you need so Node.js is the best choice, but also face the risk of Node.js, now Node.js extreme lack of enterprise-class tools, error debugging difficulties, information is also less than the mainstream language.
The second issue is whether the project needs to be compatible IE, currently a lot of front-end engineers like to use front-end framework. But if the current project requires compatible IE, and then you can say goodbye to these frameworks.
The third question is whether there is a sufficient number of front-end engineers. More thorough separation of front and rear ends, the front end of the more workload. If there is not enough front-end engineers, we will be confronted with a variety of recruitment risk that difficult to recruit experienced front-end engineers, at this stage can only rely on overtime.
Precautions
before and after the relevant meetings end engineers must all participate, and the need to develop a good interface documentation, back-end engineers to write test cases, do not let your front-end engineers act as a full-time test is recommended to use chrome plugin postman or soapui or jmeter, service layer take junit write test cases. ps: front-end test unit can also play it?
The above-mentioned interface is not java in the interface, it plainly call interface method is to call your controler inside.
It increased the workload of the team's front-end, back-end team to reduce the workload and improve the performance and scalability.
We need a number of front-end framework to address similar to the nested page, pagination, page jump control.
If you have the relevant permission to check some of the pages and so on, these relevant data from the interface can also get in through ajax.
For both the front can also do the back-end logic to do, I suggest that is put front-end, and why? Because you need to calculate the logic of computing resources, if placed in the back-end logic to run bandwidth & memory & cpu will consume computing resources and so on, you have to keep in mind is that the server computing resources are limited, but if you put the front , using the computing resources of the client, so that your server load will drop (high concurrency scenarios). This is similar to data validation, front and rear end needs to be done!
Front-end need to have mechanisms to deal with the case of the back-end request timeout and the back-end service downtime, friendly to the user.
Progressive separation of the front and rear ends of
the front and back are separate aspects of the overall steering Node.js middleware, we have a number of small architecture team, responsible for the production of tools and middleware for the Node.js service. For browser compatibility requirements, availability requirements, performance requirements are very high around page electronic business class pages without using the end of the separation with a small amount web template.
For browser compatibility demanding event showcases page, gradual transition from a web template for the Node template. The core application-oriented web page, a page dominated availability requirements, the transition to Node + Vue.js program. Some previously used Vue written page SEO compatible and now wants high performance requirements, you can plan a gradual transition to SSR.
Before and after the end of the separation in the team advancing, according to the actual situation of the team, it should be gradual. Architect to strictly assess the risk boundary, stable business. Business development, new services and more choices to promote high-level separation scheme. For old business transformation should be gradual, select the new requirements.
