Scheme and technical selection of front and rear end separation

1. What is front-back separation?

Understanding front-end separation can be understood from three aspects:

1. Interactive form

2. Code organization form

3. Development mode and process

1. 1 interactive form

The front end and back end are not separated.

After the backend assembles and presents the data and pages, it outputs the final html to the browser. After receiving it, the browser will parse the html, parse the imported css, execute the js script, and complete the final page display.

Anterior and posterior separation

The back end only needs to agree with the front end on the received and returned data format (usually JSON format), and provide the front end with an API interface. The front end can call API through HTTP request to interact. After the front-end obtains the data, the page is assembled and rendered, and finally presented in the browser.

1.2 code organization form

The front end and back end are not separated.

In the early days of web application, the front-end pages and back-end business data processing codes were all placed under one project, even in the same directory, and the front-end pages and back-end codes were mixed together. Both front-end and back-end development engineers need to import the whole set of code into development tools for development. At present, the coupling degree between front-end code and work is too high, so the front-end can't develop and test independently, and the back-end personnel have to rely on the front-end to complete the development after completing the page. In the worst case, the front-end engineers need to know the back-end template technology (jsp), and the back-end engineers need to know the front-end technology and orally explain the page data interface to cooperate with the development. Otherwise, the front end can only be "silhouette", and only output HTML, CSS and a small amount of JS irrelevant to business logic; Then from the back end to the back end jsp, the js code of the business is also written.

Anterior and posterior separation

The front-end code and the back-end code are placed in different projects, the front-end code can be developed independently, and the back-end API service can be run and tested independently through mock/easy-mock technology. Back-end code can also be independently developed, run and tested. Through swagger technology, API documents can be automatically generated for front-end reading, and automatic interface testing can be carried out to ensure the usability of API and reduce the integration risk.

1.3 development mode and process

The front end and back end are not separated.

In the project development stage, the front-end compiles business-independent HTML, CSS and a small amount of js (pure effect) according to the prototype and UI design draft, and gives it to the backstage staff, who turns HTML into jsp, and performs data binding and some logical operations through JSP template syntax. After the background is completed, all the codes, including front-end code and back-end code, are packaged into a war and then deployed to the same server to run. At most, do a separation between static and dynamic, that is, deploy pictures, css and js to nginx respectively.

The specific development process is as follows: Sketch.

Anterior and posterior separation

After the front-end and the back-end are separated, the front-end writes HTML, CSS and a few js (pure effect) irrelevant to the business according to the prototype and UI design draft, and the back-end also designs the API according to the prototype, and agrees with the front-end in API data specification. Wait until the background API is completed, or just after the API data specification setting is completed. The front end can call API through HTTP, and can also complete data assembly and business logic writing through simulated data. The front and rear ends can be parallel, or the front end can be developed first and then the back end can be developed.

The specific development process is as follows: Sketch.

Second, the advantages and disadvantages of separation before and after.

Compared with the above three aspects, the front-end separation architecture has changed a lot compared with the traditional web architecture, which seems to have many benefits. Regardless, it is still necessary to rationally analyze whether it is worth doing.

Judging from the current development trend of application software development, there are two main aspects that need attention:

Pay more and more attention to the user experience. With the development of the Internet, multi-terminal has begun.

Large-scale application architecture model is developing towards cloud and micro-service.

We mainly improve in the following four aspects through the front-end and back-end separation architecture:

Build a lean team for quality products.

By separating the front-end and back-end of the development team, the front-end and back-end engineers only need to focus on the front-end or back-end development work, so that the front-end and back-end engineers can achieve autonomy and cultivate their own unique technical characteristics, and then build a full-stack lean development team.

Improve development efficiency

After front-end and back-end are separated, front-end and back-end codes can be decoupled. As long as the front-end and the back-end communicate and agree on the interface and interface parameters required by the application, they can start parallel development without waiting for the other side's development work to end. At the same time, even if the requirements change, as long as the interface and data format remain unchanged, the back-end developers do not need to modify the code, as long as the front-end changes. In this way, the development efficiency of the whole application will be improved qualitatively.

Perfect response to complex and changeable front-end requirements

If the development team can complete the transformation of front-end and back-end separation, build excellent front-end and back-end teams, and develop independently, so that developers can focus on specialization, the development ability will inevitably be improved, and they can perfectly cope with all kinds of complex and changeable front-end requirements.

Enhance the maintainability of the code.

After the front-end and back-end are separated, the application code is no longer mixed, and only the runtime will have call dependency. The application code will become neat and clear, and it will be easier to read and maintain the code than before.

So what's wrong with separating the front and rear ends? I didn't expect the back-end engineers to become omnipotent unless you said that the front-end team would be equipped. . .

Second, the front-end and back-end are separated.

To separate the front end from the back end, the technical architecture of the front end has changed greatly, and the back end has been replaced by restfull-style API, plus Swagger technology to automatically generate online interface documents.

At present, the front-end and back-end separation schemes mainly have two front-end technical architectures:

Traditional hydrotherapy

Server-side SSR presentation

2. 1 traditional hydrotherapy

Traditional SPA refers to a single-page application, that is, the whole website has only one page, and all functions are presented through this page. Because a person's naked eye looks at a page at a certain point in time, why do you need to make multiple pages with different functions? Just keep a page as a template, and then update the content of this template page by routing jump. Indeed, now a single-page application can be easily realized through technologies such as reac family bucket, tvue family bucket, modularization, routing and wabpack.

The running process of a single-page application

1. The user accesses the website url through the browser.

2. Download the single-page html file (index.html) to the browser, and then download the css and js referenced in the html.

3. After downloading 3.css and js to the browser, the browser begins to parse and execute the data asynchronously requested by js to the back-end service.

4. After the requested data is completed, the data is bound and presented, and the last complete page is presented in the user's browser.

2.2 server rendering

The server-side rendering scheme is that data binding and rendering are completed on the server side, and the server outputs the final html to the browser. Do you have any questions after reading this? Isn't this the era when the front and rear ends are not separated again? The answer is no, because the server here is used for front-end data binding and rendering, that is, sharing part of the browser's work with the server. At present, the server with this ability is NodeJs server.

Its principle is actually to insert a NodeJs server between the browser and the front-end code. When the browser requests the front-end page, it will first pass through the NodeJs server, and NodeJS will read the front-end page and execute the asynchronous back-end API. After obtaining the data, it will do page data binding, rendering and other work, complete a final html and then return it to the browser, and finally it will be displayed by the browser.

Running process of server-side rendering application:

1. The user accesses the website url through the browser.

2.Nodejs server receives the request and reads the corresponding front-end html, css and js.

3.Nodejs parses and executes js, and asynchronously requests data from the back-end API.

After 4.4. NodeJs requests completion data, which is bound and rendered to get the final html.

5.NodeJs outputs html to the browser, and the browser displays it.

PS: In fact, the essence is to write the front end as a nodeJs server-side web application. After implementing server-side rendering, we finally run a Nodejs server-side application. Single-page application is to deploy static pages to a static resource server to run.

See here, do you have any questions? Why bother with server-side rendering?

2.3 SPA and server rendering scheme comparison

The advantage of SPA is that it is simple to develop and deploy. The disadvantage is that it is slow to load for the first time and needs better network and unfriendly search engine optimization.

So, here are the reasons for using server-side rendering (excerpt from official vue statement):

Compared with traditional SPA (single page application), server-side rendering (SSR) has the following advantages:

Better SEO, because search engine crawlers can directly view fully rendered pages.

Note that so far, Google and Bing can index synchronized JavaScript applications well. Synchronization is the key here. If your application initially shows loading daisy-graphs, and then gets the content through Ajax, the crawling tool will not wait for asynchronous completion before crawling the page content. That is to say, if SEO is very important to your site and your pages get content asynchronously, you may need server-side rendering (SSR) to solve this problem.

Faster content acquisition time, especially for slow network conditions or slow devices.

You don't have to wait to download and execute all JavaScript before displaying the markup rendered by the server, so your users will see the fully rendered page faster. Generally speaking, it can produce a better user experience. For those applications whose content time is directly related to the conversion rate, server-side rendering (SSR) is very important.

There are some trade-offs when using server-side presentation (SSR):

Limited by development conditions. Browser-specific code can only be used in some life cycle hook functions; Some external libraries may require special handling to run in server rendering applications.

More requirements related to build setup and deployment. Unlike a completely static single-page application (SPA) that can be deployed on any static file server, the server rendering application needs to be located in the running environment of Node.JSServer

More server-side load. Rendering a complete application in Node.js obviously takes up more CPU resources (CPU intensive -CPU intensive) than a server that only provides static files, so if you expect to use it in a high-traffic environment, please prepare the corresponding server load and adopt the caching strategy wisely.

Take vue as an example. Please refer to the official guide for server-side rendering:/chrisfritz/prerender-spa-plugin.

Third, the front and rear separation technology selection

-artTemplate+bootstrap (not recommended, incomplete front-end separation)

-vue series bucket (recommended)

-react family bucket (recommended, ecological)