Before the front-end and back-end separation, our development collaboration model was generally as follows:

The front-end writes static HTML pages and delivers them to the back-end development. Static pages can be developed locally, and there is no need to consider business logic. You only need to implement View.

The backend uses a template engine to set templates, and embeds some template variables and some logical operations provided by the backend.

Then when the front-end and back-end are integrated and docked, if there is a problem, the front-end reworks and the back-end reworks.

Then integrate until the integration is successful.

Problems with this model

During front-end debugging, a complete set of back-end development tools must be installed, and the back-end program must be fully started. If you encounter a problem, you need back-end development to help debug it. We found that the front-end and back-end are severely coupled, and back-end personnel are required to know some front-end languages ??such as HTML and JS. There is also a lot of back-end code embedded in the front-end page. Once the backend is developed in another language, it will almost have to be redone.

This increases a lot of communication costs, debugging costs, etc., and the front-end and back-end development progress interact with each other, thus greatly reducing development efficiency.

The separation of front-end and back-end is not just a development model, but an architectural model of web applications. In the development phase, front-end and back-end engineers agree on data interaction interfaces to achieve parallel development and testing; in the running phase, the front-end and back-end separation mode requires separate deployment of web applications, and the front-end and back-end use HTTP or other protocols to make interactive requests.

1. The client and server interact using the RESTFul API interaction method

2. Separation of front-end and back-end code bases

In the traditional architecture model, front-end and back-end The client code is stored in the same code base, or even in the same project directory. The page is also mixed with back-end code. When front-end and back-end engineers develop, they must import the entire project into the development tool.

The front-end and back-end code bases are separated. The front-end code has a pseudo-backend that can be used for Mock testing (a method of simplifying the test environment by constructing virtual test objects), which can support independent development and testing of the front-end. In addition to functional implementation, the back-end code also has detailed test cases to ensure the availability of the API and reduce integration risks.

3. Parallel development

During the development period, the front-end and back-end teams agree on the interaction form and data format of the data interface. Then realize the parallel development of the front and back ends. After the development is completed, the front end engineers can conduct mock testing alone, and the back end can also use interface testing software such as Postman to conduct interface self-tests. Then the front and back ends jointly perform functional joint debugging and verify the format, and finally Automated testing.

After separation, the development model is like this

Build a lean team for high-quality products

By separating the development team from the front-end and back-end, front-end and back-end engineers only need Focusing on front-end or back-end development work enables front-end and back-end engineers to achieve autonomy, cultivate their unique technical characteristics, and then build a full-stack lean development team.

Improve development efficiency

After the front-end and back-end are separated, the front-end and back-end codes can be decoupled. As long as the front-end and back-end communicate and agree on the interfaces and interface parameters required for the application, parallel development can begin. , without waiting for the other party's development work to be completed. At the same time, even if the requirements change, as long as the interface and data format remain unchanged, 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 entire application will inevitably be qualitatively improved.

Perfectly cope with complex and changing front-end needs

If the development team can complete the transformation of front-end and back-end separation, build an excellent front-end and back-end team, develop independently, and allow developers to focus Specialization and development capabilities will inevitably be improved, and can perfectly cope with various complex and changing front-end needs.

Enhance code maintainability

After the front-end and back-end are separated, the application code is no longer a mixture of front-end and back-end, and there will only be call dependencies during runtime. The application code will become clean and clear, and both code reading and code maintenance will be easier than before.

After using the front-end and back-end separation architecture, in addition to changes in the development model, what other problems will we encounter during the development process? Let's look down.

Let’s first take a look at traditional development, how we perform user authentication

Front-end login, the back-end generates a jsessionid based on user information, and saves this jsessionid and the corresponding user id to the Session, and then pass the jsessionid to the user and store it in the browser cookie. Then the browser requests to bring this cookie, and the backend queries the user based on this cookie value to verify whether it has expired.

HTTP has a characteristic: stateless, that is, the two HTTP transactions do not know each other's information. In order to maintain session information or user information, Cookie and Session technologies are generally used to cache information.

- Cookie is stored on the client side

- Session is stored on the server side

But there are many problems with this, if our page has an XSS vulnerability , since cookies can be read by JavaScript, XSS vulnerabilities will cause user tokens to be leaked. As the backend identifies users, the leakage of cookies means that user information is no longer safe. Although we can try to avoid XSS injection by escaping output content, using CDN, etc., no one can guarantee that this problem will not occur in large projects.

When setting cookies, you can actually set nv.taobao.com, nz.taobao.com, login.taobao.com. Therefore, if we want to realize that after logging in to login.taobao.com, we can still get the Session under other subdomain names, this requires us to synchronize the Session on multiple servers. Using JWT does not have this problem because the user's status has already been transmitted to the client.

When the client and server are deployed to different servers separately, they will encounter the problem of cross-domain access, which is a type of request scenario restricted by the browser's same-origin policy.

There are many cross-domain solutions. The following solution uses Nginx reverse proxy

Reverse proxy

There are actually many scenarios for proxy access in practical applications. , the principle and method of application in cross-domain is: monitor the access of the same port and the same domain name through the reverse proxy server, and map different paths to different addresses. For example, in the nginx server, the same domain name and port are monitored, and different paths are forwarded. Go to the client and server, and use reverse proxy to restrict different ports and domain names to solve cross-domain problems: