The background,

(1) We use mock server to build our own front-end data simulation service. During the development process of the front-end and back-end, we only need to define the interface specification to carry out their own development tasks. When conducting joint investigation, it is ok to conduct data joint investigation according to the development specifications defined before. The functions of the front and rear end are clearer:

The back-end The front end
Provide data Receive data, return data
Process business logic Handling render logic
Server – side the MVC architecture The Client – side MV * architecture
The code runs on the server The code runs in the browser

There’s a clean separation, there’s a clear division of labor, everything looks good, but… It’s also easy to spot the problem:

  1. Client-side Model is the processing of server-side Model
  2. A client-side View is a different level from a server-side View
  3. The client-side Controller and the Sever side Controller are separate
  4. A client-side Route may not exist on the Server side

That is to say, the server side and the client side of each layer of overlapping responsibilities, we do their own, it is difficult to unify the specific things to do. And there may be some performance issues associated with it. The most specific performance is the commonly used SPA application:

  1. Rendering, values are done on the client side, there are performance issues
  2. Need to wait for resources to complete to proceed, there will be a short white screen and flashing
  3. The experience on low-speed networks on mobile devices is abysmal
  4. Rendering is in the client side, template can not be reused, SEO implementation trouble

As the code gets bigger and bigger, more and more forms need to be verified, and sometimes a form needs to be verified once in a front-end submission. The server needs to perform verification to achieve data reliability; The front-end route may not exist on the server…. And so on. So our previous refactoring may have required deeper thinking.

Two, start refactoring

Before we start refactoring, we need to make a division of the front and back ends. That is, what belongs to the front end and what belongs to the back end. The most traditional division of the front and back ends might look like this:

image.png

Then the problem comes: we divide the wiring front and rear end, is in accordance with the job responsibilities to divide the front and rear end; Or front and back according to the hardware environment? Since NodeJS, we can redefine the category of front and back ends in terms of work function:

image.png

As you can see, there are more NodeJS in the front end than before, so we have built a NodeJS service as the middle layer between the front end and the back end! Why did we choose NodeJS as the middle tier? Nodejs is still JS, so there should be no problem with loading it up syntactically. Secondly development transfer costs also want to be low on, without having to switch back and forth between language logic and syntax:

  1. Familiar language front-end, low learning cost
  2. Are JS, can be back – end reuse
  3. Fitness: event-driven, non-blocking I/O
  4. Suitable for IO intensive services
  5. The execution speed is not bad either

Okay, so with all this stuff going on, what does this middle layer give us? Nodejs is a new layer of services that takes a lot of time to deliver. Let’s take a look at the application scenarios where NodeJS can do more good than harm.

Three, start the middle tier tour

With nodeJS introduced, we reclassify the functions of the front and back ends:

image.png

This is the main idea behind mid-tier Nodejs, and let’s take a look at common business scenarios:

1. Restore interface data reliability

Sometimes the data returned to us by the server may not be the structure that the front end wants. All the presentation data used is provided by the back end through an asynchronous interface (AJAX/JSONP), and the front end just presents it. But the back end often provides the back-end data logic that needs to be handled on the front end. For example, when I develop another feature, I sometimes run into the following problem:

image.png

image.png

If a field returned by the server is null or the data structure returned by the server is too deep, the front-end needs to constantly write code to determine whether the data structure really returns the correct thing, rather than null or undefined:

if (params.items && params.items.type && ...) {
   // todo
}Copy the code

In this case, the front end shouldn’t have to double-check the format of the data, and this shouldn’t be something browser-side JS should do. We can do interface forwarding in the middle layer and do data processing in the forwarding process. Without worrying about data return:

router.get('/buyer/product/detail', (req, res, next) => {
  httpRequest.get('/buyer/product/detail', (data) => {
    // Todo handles datares.send(data); })})Copy the code

Page performance optimization and SEO

Sometimes when we make a single page application, we often encounter the performance problem of the first screen loading. If we connect the middle layer NodeJS, then we can leave the first screen rendering task to NodeJS, and the second screen rendering will still follow the previous browser rendering. (Front-end page swapping, browser-side rendering, direct input of url, server rendering) Server rendering splashes out HTML strings for pages, which can greatly improve the first screen rendering time and reduce the waiting time of users. The most common use of this form is Vue’s server-side rendering, which is also described in this section. Secondly, SEO optimization of a single page is also a good way to deal with it. Since ajax is not supported by search engines such as Baidu at present, if you want to get the support of crawlers, then server-side rendering is also a solution. (PS: If you feel that server-side rendering is too much trouble, HERE is another way to deal with SEO.)

3. Common demand solutions of Taobao

Requirements: In Taobao, a single day 400 million PV, page data from different interfaces, in order not to affect the experience, first generated page frame, in the launch of multiple asynchronous requests for data update page, these extra requests have a great impact, especially in the wireless end.

Solution: Use Bigpiper technology on NodeJS side to merge requests, reduce burden, batch output, and not affect the experience. At the same time, the large interface can be split into independent small interfaces and concurrent requests can be made. Serial => parallel, greatly shortening the request time.

4. More possibilities

image.png

conclusion

This is just one solution to the problem, but again: it all depends on the application scenario. If you have other opinions on the content of this article, you are also welcome to discuss with us.

about

Author: monkeyWang

My homepage: monkeyWang

Part of this article picture paragraph reference article: Taobao front end separation practice

Wechat public account: will push the front end technology articles irregularly, welcome to pay attention to

image.png