Before the front and back-end separation of our development collaboration model is generally this:

Front-end write a good static HTML page delivered to the back-end development. Static pages can be developed locally, there is no need to consider the business logic only need to implement View.

The back-end using the template engine to set the template, while embedding some of the template variables provided by the back-end and some logical operations.

Then the front-end and back-end integration and docking, encounter problems, front-end rework, back-end rework.

Then integrate until the integration is successful.

Problems with this model

In the front-end debugging to install a complete set of back-end development tools, to start the back-end program completely. When you encounter problems, you need the back-end development to help debugging. We found that the front-end and back-end serious coupling , but also require the back-end staff will be some HTML, JS and other front-end languages . The front-end page is also embedded in a lot of back-end code. Once the back end is developed in a different language, it simply has to be redone.

Like this increased communication costs, debugging costs, and so on, and the front and back of the development progress affect each other, thus greatly reducing the development efficiency.

The separation of front and back ends is not just a development model, but an architectural model for web applications. In the development phase, the front-end and back-end engineers agree on the data interaction interface to achieve parallel development and testing; in the operation phase of the front-end and back-end separation mode needs to be separated from the web application deployment, the front and back-end before the use of HTTP or other protocols for interactive requests.

1. Client and server interact with each other using the RESTFul API

2. Separation of front and back-end code bases

In the traditional architectural model, the front and back-end code is stored in the same code base, or even under the same project directory. The page is also interspersed with back-end code. Both front- and back-end engineers must import the entire project into the development tool when they develop.

Separation of front-end and back-end code bases, front-end code can be Mock test (by constructing a virtual test object to simplify the test environment) pseudo back-end, can support the front-end of the independent development and testing. The back-end code has detailed test cases in addition to the functional implementation to ensure API availability and reduce integration risk.

3. Parallel development

During the development of the front and back **** with the agreement on the form of interaction of the data interface and data format. Then realize the parallel development of front-end and back-end, in which the front-end engineers after the completion of the development can be alone mock test, and the back-end can also use Postman and other interface testing software interface self-testing, and then the front and back-end together with the functionality of the joint tuning and verification of the format, and ultimately automated testing.

After separation, the development model looks like this

Creating a lean team for quality products

By separating the front-end and back-end of the development team, so that front-end and back-end engineers only need to focus on the front-end or back-end of the development work, the front-end and back-end engineers can realize autonomy. They can then build a full-stack, lean development team.

Enhance development efficiency

After the front-end and back-end separation, the decoupling of the front-end and back-end code can be realized, and as long as the front-end and back-end communication agree on the interfaces needed for the application as well as the interface parameters, the parallel development can be started without having to wait for the other side of the development work to finish. At the same time, even if the demand changes, as long as the interface and data format remains unchanged, the back-end developers do not need to modify the code, as long as the front-end changes can be made. In this way, the development efficiency of the entire application will be improved.

Perfect response to complex and changing front-end requirements

If the development team can complete the transformation of the front-end and back-end separation, to create a good front-end and back-end team, the development of independent, so that the developers to focus on specialization, the development capabilities will certainly be improved, and to be able to cope with a variety of complex and changing front-end requirements.

Enhance code maintainability

After the separation of front and back ends, the code of the application is no longer a mixture of front and back ends, and only in the runtime there will be a call dependency. The application code will become neat 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 the change in the development model, what other problems will we encounter in the development process? Let's move on.

Let's take a look at the traditional development, how we do user authentication

The front-end login, the back-end according to the user information to generate a jsessionid, and save this jsessionid and the corresponding user id to the Session, and then pass the jsessionid to the user, deposited in the browser cookie, and after that. browser request takes this cookie with it, and the back-end queries the user based on the cookie value to verify whether it has expired or not.

HTTP has a feature: stateless, that is, before and after the two HTTP transactions they do not know each other's information. And in order to maintain session information or user information, generally available cookie and session technology to cache information.

- Cookies are stored on the client side

- Sessions are stored on the server side

But there are many problems with this. If we have an XSS vulnerability on a page, because cookies can be read by JavaScript, the XSS vulnerability can lead to the leakage of user tokens, which are used as a back-end identifier of the user. As a back-end identifier of the user, the leakage of a cookie means that the user's information is no longer safe. Although we can try to avoid XSS injection by escaping output content, using CDNs, etc., no one can guarantee that this problem won't occur in large projects.

When setting a cookie, you can actually set , nv.tao.com, nz.tao.com, and login.tao.com. So if you want to realize that after logging in to login.tao.com, you can still fetch the Session on other subdomains, it requires us to synchronize the Session across multiple servers. The JWT approach does not have this problem because the user's state is already transmitted to the client.

The problem of cross-domain access is encountered when the client and server are deployed separately to different servers, and is a class of request scenario limited by the browser's same-origin policy.

There are many cross-domain solutions, and the following one uses the Nginx reverse proxy

Reverse Proxy

Proxy access is actually a lot of scenarios in real-world applications, and in cross-domain applications, the principle of the practice is to listen to the same ports, the same domain name through the reverse proxy server, and different paths to map to different addresses. different addresses, for example, in the nginx server, listening to the same domain name and port, different paths forwarded to the client and the server, the different ports and domain name restrictions through the reverse proxy to solve the problem of cross-domain: