The front-end students use nginx to build their own web server, and the background program is specially deployed on one server (our company had three sets of environments before, development/testing/production). The advantage of this is that
1. The front-end code is basically a static file, and it takes only a few seconds to restart once.
2. You don't need to configure the background language development environment, you don't need to care about how the background code runs, and you don't need to care how many dependency packages he uses.
3. There are no restrictions on the network environment, it does not matter whether it is an internal network or an external network.
This idea is good, but one problem that needs to be solved is how to respond to the ajax request sent on the page after the front-end builds its own static server? Because we do not have a real background server interface locally. So we have to find a way to use nginx to forward the request to the real remote background server, and then the background server returns the data to nginx, and nginx receives the data and then returns the page to us. This technique is generally referred to as request forwarding or reverse proxying.
(Another way is to set all API requests to use absolute paths by judging when location.href == localhost, and then turn off the cross-domain check of the browser. Turn off the cross-domain check method, right-click the chrome property, and append to the target: --disable-web-security --user-data-dir=C:\tmp Note that it is appended!!!)
It is not difficult to use nginx to build a static server. There are a lot of tutorials on the Internet, which will not be introduced here. The difficulty lies in how to request forwarding. I didn't know much about nginx configuration at first, and the online tutorials were ambiguous. It took me several days to figure out this process. The following is a configuration diagram of nginx
The configuration is very simple, but I have been doing it for several days. Here I will tell you about the key parts.
1. location supports the absolute path of the configuration project
2. Assuming that our background API address starts with API, location ^~ /api/ means that nginx will intercept requests containing "/api/" in the request address. In fact, this is our ajax request path. After intercepting the request According to the writing method, this request will be forwarded to the address of proxy_pass below in two cases.
for example:
a. As shown in the figure above, if the URL of proxy_pass ends with /, the matching /api/ will not be included when the request is forwarded, that is to say, if the login request URL is localhost:60001/api/user/login, proxy_pass URL is http://a.xx.com:8080/platform/, Nginx will forward this request to http://a.xx.com:8080/platform/user/login
b. If the URL of proxy_pass does not end with /, then the request will be forwarded with the matching /api/, that is to say, if the login request URL is localhost:60001/api/user/login, and the proxy_pass URL is http: //a.xx.com:8080/platform, Nginx will forward this request to http://a.xx.com:8080/platform/api/user/login
3. Generally, after we log in, the server will write the token back to our local area through Set-Cookie. If the proxy_cookie_path is not set, the server Set-Cookie command will be invalid, and the cookie cannot be stored locally, resulting in the loss of the token.
One thing to note about proxy_cookie_path here is that if the proxy_pass URL is http://a.xx.com:8080/platform/ in this case proxy_cookie_path should be set to /platform/ / (note the space between the two slashes).
If proxy_pass URL is http://a.xx.com:8080/ in this case proxy_cookie_path should be set to // (note the space between the two slashes)
Restart nginx and you will find that everything is normal.