Notes on configuring multiple proxies using vue projects

In the development process of Vue project, for the convenience of local debugging, we usually configure devServer in vue.config.js to start a server locally. In this option, we will configure the proxy property to proxy the request directed to the local (for example: /api/action) to the backend development server (for example: http://xxx.xxx.xxx/api/action)

devServer: {
        port: 8081,
        proxy: {
            '/api/action': {
                target: 'http://192.168.200.106:81',
                changeOrigin: true,
                ws: true,
                secure: false
            }
        }
    },
```

In this configuration, pay attention to the following two points:

When there are overlapping interface addresses, the one with the lowest matching degree is placed at the end.

For example:

* Match / to 192.191.1.1;
* Match /api to 192.191.1.2
* Match /api/action to 192.191.1.3

If we write as follows:

proxy: {
            '/': {
                target: 'http://192.191.1.1',
                changeOrigin: true,
                ws: true,
                secure: false
            },
    '/api': {
                target: 'http://192.191.1.2',
                changeOrigin: true,
                ws: true,
                secure: false
            },
    '/api/action': {
                target: 'http://192.191.1.3',
                changeOrigin: true,
                ws: true,
                secure: false
            }
        }

Then all requests to /, /api and /api/action will be proxied to 192.191.1.1

The reason is that the matching here is actually a regular matching process. When we request /api, we first read the first configuration item, and use the / in the configuration to match the /api in the request. It is found that the requested /api contains the configuration item /, and the match is successful. The request is directly proxied to 192.191.1.1. The same is true for the matching of /api/action.

In other words, its matching rule is: use the address in the configuration item to match the address in the request. If the address in the request contains the address in the configuration, the match is successful. Otherwise, pick the next configuration item to continue matching.

Therefore, the fewer characters in the configuration address that match the request address, the lower the match. In the above example, only one character of the address (/) in the configuration matches the request address (/api), so the matching degree is low.

So the correct way to write it should be:

proxy: {
            '/api/action': {
                target: 'http://192.191.1.3',
                changeOrigin: true,
                ws: true,
                secure: false
            },
    '/api': {
                target: 'http://192.191.1.2',
                changeOrigin: true,
                ws: true,
                secure: false
            },
    '/': {
                target: 'http://192.191.1.1',
                changeOrigin: true,
                ws: true,
                secure: false
            }
        }

In this way, requests to the three addresses can be correctly proxied to the corresponding addresses

When multiple addresses proxy the same target, they can be merged

In actual applications, since the backend is developed in microservice mode, during the development phase, we may proxy different services to different addresses. When there are many services, the number of our proxies is also large:

proxy: {
  		'/api/action': {
                target: 'http://192.191.1.3',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action2': {
                target: 'http://192.191.1.4',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action3': {
                target: 'http://192.191.1.3',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action4': {
                target: 'http://192.191.1.4',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action5': {
                target: 'http://192.191.1.5',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action6': {
                target: 'http://192.191.1.6',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action7': {
                target: 'http://192.191.1.5',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action8': {
                target: 'http://192.191.1.6',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action9': {
                target: 'http://192.191.1.7',
                changeOrigin: true,
                ws: true,
                secure: false
            },
			 '/api': {
                target: 'http://192.191.1.2',
                changeOrigin: true,
                ws: true,
                secure: false
            },
			 '/': {
                target: 'http://192.191.1.1',
                changeOrigin: true,
                ws: true,
                secure: false
            },              
        }

When the number of configured proxies exceeds ten, the following error will be reported when the development environment compiles and packages:

insert image description here

In order to solve the error and reduce the code size, we can merge the configuration items with the same target. As we can see from the above, this is actually a regular matching process, so we can use regular syntax to merge them:

proxy: {
  		'/api/action|/api/action3': {
                target: 'http://192.191.1.3',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action2|/api/action4'': {
                target: 'http://192.191.1.4',
                changeOrigin: true,
                ws: true,
                secure: false
            },
             
              '/api/action5|/api/action7': {
                target: 'http://192.191.1.5',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action6|/api/action8': {
                target: 'http://192.191.1.6',
                changeOrigin: true,
                ws: true,
                secure: false
            },
              '/api/action9': {
                target: 'http://192.191.1.7',
                changeOrigin: true,
                ws: true,
                secure: false
            },
			 '/api': {
                target: 'http://192.191.1.2',
                changeOrigin: true,
                ws: true,
                secure: false
            },
			 '/': {
                target: 'http://192.191.1.1',
                changeOrigin: true,
                ws: true,
                secure: false
            },              
        }

Of course, when officially deployed, the backend is still needed to act as a unified agent.

The above is my personal experience. I hope it can give you a reference. I also hope that you will support 123WORDPRESS.COM.

You may also be interested in:

Configure different proxies in Vue to access different background operations at the same time
Vue project configuration cross-domain access and proxy setting method
Vue configuration multi-proxy service interface address operation
ProxyTable configuration interface address proxy operation in webpack+vue-cil
How to configure reverse proxy in VueCli4 project
Vue (2.x, 3.0) configures cross-domain proxy
Vue cli3 configures proxy proxy invalid solution
How to implement proxy v2 version in vue configuration file

<<: Detailed explanation of a method to rename procedure in MYSQL

>>: Detailed example code of mysql batch insert loop