Suning.com: The ground thinking of the front and back end separation architecture

The separation of front and rear ends is essentially a refinement of job responsibilities. In the past two years, there has been an increasing demand for the separation of the front end and the back end. The most important reason is that the back end engineers cannot simply complete the work on the front end. New technologies have been emerging in the front end in an endless stream. In this case, the back end cannot simply master the front-end technology, and even the front end has a certain burden.

The threshold at the front end is getting higher and higher, and one cannot get everything done, which is also a factor in the separation of the front and back ends.

The separation of the front and back ends is not a panacea and will vary according to different business scenarios. The same application scenarios are also different. The traditional front-end application scenarios include PC terminal and mobile terminal, as well as App hybrid and small programs. Different technologies are used for different application scenarios, and many application scenarios increase the complexity of the architecture.

We faced a number of technical challenges on the front end, the most important of which was the high availability requirements for high traffic. For sites with low traffic, the testing volume is not very large, and only in rare cases can users detect bugs. However, in the case of heavy traffic, the number of perceivers will obviously increase, and the problems encountered in various aspects will also increase, such as the problem of slow network and interface. In view of the large flow, the front end can adopt CDN to resist, at this time, the pressure of the back end will be relatively large. When the back end can not carry the time, it needs the front end to share some of the pressure, can not let the user perceive the web page problems, in this case the high availability requirements will be very high.

The second is the problem that all front-end engineers hate, the browser compatibility requirement is very high. No one is going to like the need to be compatible with IE7, but there is always a need to use IE7 with a large number of users, and this need must be met in order to avoid user complaints.

For e-commerce companies, they have to deal with various activities such as Double 11, Double 12 and 418 every year. In this case, the iteration speed of business is very fast, and it will be very troublesome to deal with the architecture. Another troublesome technology is SEO support. Many SEO technologies are not supported, such as VUE, React and other MVVM frameworks cannot be used.

We mainly use four technical solutions: front-end template (Ajax + string template), MVVM (Vue, React), Node template (Express + EJs), SSR (Node + Vue SSR). The oldest of these is the Ajax + string template, which is essentially a concatenation of strings.

IE6+ is supported for both server rendering and normal rendering. Using SSR or Node for rendering is less compatible with browsers. The technical solution based on the modern MVVM framework is also at a disadvantage, and cannot be used in the occasions with high browser compatibility requirements.

For SEO requirements for web pages, using web templates and Vue solutions, is not appropriate. Compared to web templates, you can add introductions and things like that before the page is rendered. Node and SSR don’t have much of an SEO problem, they are both server-side renderers and both have enough data on the first screen.

Obviously, Node is the fastest technology available for first screen rendering. After all, it is server-side rendering, and the data is fetched from the Node server to the service provider. SSR rendering takes 30% to 50% more time than Node. Both the Web template and Vue read data and then load it, with Vue taking longer to render. Overall, the MVVM framework is the slowest in terms of first screen rendering time.

After the first screen is loaded, many pages will have lazy loading and need to request the corresponding data interface from the server. In this respect, MVVM framework and Web template are directly connected to the back end, while Node and SSR schemes both use Nodejs to do a forwarding at the middle layer, which consumes part of the network connection, and the extra services from the Node server to the service provider.

Web templates do the best job in terms of high availability, and as long as the backend service provider is not hanging up, Web templates generally don’t have too many problems. MVVM is a bit more complex, requires more browser compatibility, and is more testable, but there are always some areas that are not tested.

As an intermediate platform, Node should not only pay attention to front-end CDN, but also pay attention to whether Node server will have problems. In this way, each additional link will be worse in terms of high availability. SSR not only requires high availability on Node, but also introduces front and back end code isomorphism, which may cause various problems on Node. Based on this situation, SSR is considered the worst in terms of high availability.

The choice of technology should first consider whether it is suitable for the current team. Different teams will have different situations. Technical threshold to take college admissions generally in the Web template will not be too big a problem, Vue such MVVM framework may understand a, but more familiar with the relatively few. Unlike Web templates and Vue, which are at least on the front end, Node is a bit more complicated for the front end. SSR is even worse. Not only do you need to know about Node, but you also need to know how the same set of code works on Node and how the SSR framework works, so the bar is even higher.

Using a Web template or MVVM framework requires at least working with o&M and others to find a server to place the page, and some contact with the back end. Using Node middleware solves all of these problems independently.

When talking about framework landing, I always have three questions. The first question is whether your project needs SEO. If you need it, then Node.js is the best choice, but there are also risks with Node.js, which currently has an extreme lack of enterprise-level tools, difficulty in error debugging, and less documentation than mainstream languages.

The second question is whether the project needs to be compatible with IE. At present, many front-end engineers like to use the front-end framework. But if your current project needs to be IE compatible, you can kiss these frameworks goodbye.

The third problem is whether there are enough front-end engineers. The more thoroughly the front and back ends are separated, the more front-end work is done. If you don’t have enough front-end engineers, you will face all kinds of hiring risks, that is, it will be difficult to find experienced front-end engineers, and you will have to work overtime at this stage.

The overall move to Node.js middleware in terms of the separation of the front and back ends, we have a small architecture team that is responsible for producing various tools and middleware for Node.js.

E-commerce pages that have high browser compatibility, usability, and page performance requirements do not use a small number of web templates.

For active display pages with high browser compatibility requirements, gradually transition from web template to Node template. Core application web pages, usability requirements dominated the page, transition to Node + vue.js solution. Certain pages that were previously written in Vue can now be progressively converted to SSR schemes if they want to be SEO compatible and have high performance requirements.

The separation of front and rear ends should also be gradual according to the actual situation of the team. The architect rigorously evaluates risk boundaries to keep the business stable. In business development, new businesses are selected to promote advanced separation schemes. For old business transformation, should step by step, select new needs.