VUE uses proxies to implement joint debugging of front-end and back-end codes

       Nowadays, many companies are more popular about the separation of front-end and back-end development (note: it is the separation of development (including code and developers), rather than the simple separation of front-end and back-end code). For example, front-end development is one wave of people, and back-end development is another wave. people. This can better reflect the specialization of the technical industry and improve the efficiency of the overall project. It is easy to develop using conventional HTML/JS/CSS, etc., and everyone can develop collaboratively in the same environment. But in the environment where VUE is used for front-end development, this conventional collaborative method is obviously not feasible, because the code of VUE cannot be directly used in the project, and it must be compiled and output into HTML/JS/CSS before it can be deployed to the development environmental. This will lead to another problem. The development environment of VUE is not the same as the development environment of the backend. For example, the front-end uses VSCODE to develop VUE, while the background may use eclipse. How did the two pass the joint test smoothly, and then What about publishing to production?

        In fact, there are two situations. One is that the front-end and back-end codes are finally integrated and deployed in one system. The other is that the front-end is deployed on one application server and the background is deployed on another application server. In either case, it will only be released after joint debugging. Because I am deploying together here, I only discuss joint debugging in this case. How to debug if two waves of people do front-end and back-end? One of the simplest methods is to start the service on both sides. The front-end developer writes the IP port and resful or servlet path of the background developer on the code. After debugging, replace this part of the code with the production environment and then build the source code. This should be the most earthy method. Another way is to use the axios proxy, and use the axios configuration to achieve cross-domain and joint debugging. The most important thing is that the code built directly after debugging can be placed in the production environment without modifying the back-end IP port. Let's see how it is implemented. If there is a better way, please leave a message.

      First introduce the axios component in main.js , and then rewrite the baseURL of axios

This sentence means to judge whether it is a development environment, if it is a development environment, use /api, otherwise it is empty

The key sentences have been marked as follows:

Among them, process.env.NODE_ENV and process.env.BASE_API are defined in dev.env.js. This JS defines some development environment variables. code show as below:

After writing the codes of the above two files, we configure the axios proxy in index.js under the config directory, where the target is the background service that the proxy will jump to, and the pathRewrite path is rewritten, which means that the request path starting with / Will jump to the proxy service.

After configuring the above key configuration files, we can use them as follows,

Let's run VUE and look at the page request, and we can clearly see that the request has been proxied to the background service.

Then we build and put the source code files directly on the server without doing task modification. In the actual production environment, the request effect is as follows:

It can be seen that the production environment does not use the agent, that is, the configuration of the development environment and the production environment in VUE does not affect each other, and the front-end developers and the back-end developers can directly build and deploy to the production environment after joint debugging. .

So far, VUE has introduced the joint debugging of front-end and back-end codes using proxies. There may be other better methods. Welcome to leave a message to discuss.

     

Guess you like

Origin blog.csdn.net/tinalucky/article/details/106594307