Recently colleague small G always moping, let me feel flustered, is I squeeze small G at ordinary times? I thought for a second, should not ah, the workload had been assessed in advance, there is no reason to work overtime every day.

After sitting down to chat, little G joked to me, “the efficiency of bug change is too low, working overtime to change the bug every day, can not leave work early to accompany the goddess!”

I took a deep breath. “Oh my God, I forgot to teach Little G the secrets…”

Under the guidance of step by step questioning, I made clear the problem of small G……

Problem is introduced into

NPM run dev or NPM start takes too much time to debug.

Due to environment differences, we access different backend service domain names in the development environment and production environment. When we debug production problems, it is inevitable to change the Webpack devServer proxy configuration to point to the production domain name, and then restart the devServer. This process is usually slow.

Sometimes the test environment can also reproduce the bug, so just access the test environment can also identify the cause of the problem. But that’s not the focus of this article, which focuses on improving debug efficiency.

Webpack-dev-server Reverse proxy

After 202 years, if you as a developer don’t know about reverse proxies, it’s worth paying attention.

As we know, cross-domain is an inescapable problem for the front end. If you don’t want to bother your backend colleagues during development, the front end must solve cross-domain problems on its own. Of course, you help back end colleagues to buy latiao, he gave you through CORS to solve cross-domain is also possible.

Fortunately, Webpack-dev-Server solves this pain point by implementing http-proxy-Middleware.

It is also very simple to configure:

proxy: {
  // Url rules that require proxy
  "/api": {
    target: "https://dev.xxx.tech".// The reverse proxy's target service
    changeOrigin: true.// When enabled, a virtual request header Origin is created
 pathRewrite: {  "^/api": "" // Rewrite the URL, which is usually used  }  } } Copy the code

At this time, small G interrupted me, indicating that I did not understand.

What does reverse proxy mean? For example, IF I want to borrow money from Jack Ma, Jack Ma will certainly not lend it to me.

But I have a good friend Lao Zhang, I then find Lao Zhang borrowed 1W, but I did not expect this friend and Ma Yun good relationship, he borrowed 1W from Ma Yun there, and then transferred to me. In other words, I don’t know where the money I borrowed actually came from, all I know is that I borrowed it from my friend, Lao Zhang, who made me a layer of reverse proxy.

Specifically, in development, my front-end child needs to call the back-end interface from the domain name https://dev.xxx.tech, but my front-end development service runs at http://localhost:8080. Directly calling the back-end interface will cross domains and be blocked by the browser same-origin policy, so this way is impossible.

So I need from the front-end server to act as an agent, so I can use this form http://localhost:8080/api/user/login call interface, like in the front your own interface (because of my visit is a front end of the url).

However, is actually a front-end server to act as a layer of agent, the proxy to https://dev.xxx.tech/user/login http://localhost:8080/api/user/login this interface. This is pointless for front-end developers.

The simple summary is: the reverse proxy hides the real server; In contrast, the forward proxy hides the real client, such as Kexueshangwang.

The debug pain points

Question, assuming we are feature branch development demand, at this time of the above notice to instant screen and solve a bug, assuming that production environment of the domain name to https://production.xxx.tech.

We tend to stash code, and then fix branch cutting, modify the target value of “https://production.xxx.tech”, then re-run NPM start restart development server access production environment, quietly waiting, emptying himself…

This is when we think, “Gee, if only we didn’t have to wait so long!”

Yes, a lot of times a bug is not complicated, it may take a minute to fix the bug, whereas it takes us a minute to switch environments and re-run the development server (in most cases more than that). So how to solve this problem?

Proxy layer decoupling

Yes, some of you have already thought that the problem can be solved by taking the proxy server out of the box. I no longer need to tie the front-end compilation process to the service proxy goal. In a production environment, this kind of Nginx forwarding is already familiar to most people, but few will attempt to do the same in a development environment. So try this!

Download Nginx

Let’s download Nginx as usual and select Windows Stable.

Fixed front end agent

To avoid having to switch the proxy target and re-run NPM start in case of a debug line problem, we fixed the proxy Target in the front layer. For example, I have fixed access to 127.0.0.1:8090 (of course, the actual access to which port can vary depending on the individual).

proxy: {
  "/api": {
    target: "127.0.0.1:8090".// Fixed proxy target
    changeOrigin: true.    pathRewrite: {
 "^/api": ""  }  } } Copy the code

Then from 127.0.0.1:8090 is definitely not access to the back-end interface, please continue to read!

Nginx proxy

Since the interface access to the front end is fixed at 127.0.0.1:8090, Nginx will do the rest. In Nginx, we need to listen on port 8090 and forward all requests to the target server.

server {
  listen       8090;
Server_name 127.0.0.1;
  location / {
 proxy_pass https://dev.xxx.tech; Proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade;  proxy_set_header Connection "upgrade";  proxy_set_header Host $host;  # proxy_set_header X-Real-IP $remote_addr;  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  } } Copy the code

This item carries information about Host, X-real-ip, and X-Forwarded-for. This item holds the domain name of the server requesting it and the IP addresses of the original client and proxy server. Note

If you do not comment x-real-ip, the Real IP address of the front end access entry is 127.0.0.1 or localhost. Nginx does not recognize such a local IP address and returns 404. The client request does not proxy to another remote server. Don’t pull, here specific reason I also don’t know, if there is a big guy know the reason, also please dial down, too thank you.

With the configuration above, we can decoupage the front-end agent layer from the Nginx agent layer. The front-end is fixed to access the back-end interface locally, 127.0.0.1:8090, and the specific interface is propositioned to the development environment, test environment, or production environment, as determined by Nginx. Just modify nginx.conf and restart.

Nginx hot restarts are fast, one-command, and almost zero wait time.

// This is the command for Windowsnginx.exe -s reload
// Linux is like thisnginx -s reload
Copy the code

The local domain name

Hear here, small G will I a army again.

It’s a good thing I was prepared and didn’t mess up.

If the local port is occupied, the simplest solution is to change the port.

In order to eliminate this situation, we can introduce local domain names, both “install force” effect.

As we know, domain names are resolved to get the real service IP. And there are some key nodes in the process of domain name resolution that we should know about.

• Browser cache
• Hosts file of the operating system
• Local DNS
• Root DNS
• gTLD Server

Borrow a picture on the Internet to explain the general process (encroachment).

The above image does not mention the hosts file, but it does not affect our magic change. As long as we in the operating system hosts file this node under the hands and feet, you can achieve the local domain name.

First, we find the file C:\Windows\System32\drivers\etc\hosts, open it and add a new parse record at the end

127.0.0.1 www.devtest.com
Copy the code

Then save the file. You need administrator permission to save the hosts file.

This is the equivalent of telling the local operating system that if the user visits www.devtest.com, I’m going to give him 127.0.0.1

Therefore, we can only listen for port 80 of 127.0.0.1 on Nginx. The configuration is as follows.

server {
  listen       80;
Server_name 127.0.0.1;
  location / {
 proxy_pass https://dev.xxx.tech; Proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade;  proxy_set_header Connection "upgrade";  proxy_set_header Host $host;  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  } } Copy the code

Finally, we simply set the proxy target to www.devtest.com in the front-end engineering.

proxy: {
  "/api": {
    target: "http://www.devtest.com".// Fixed proxy target
    changeOrigin: true.    pathRewrite: {
 "^/api": ""  }  } } Copy the code

This front end access an interface will be acting to http://www.devtest.com/user/login, http://localhost:8080/api/user/login And www.devtest.com is parsed by the local hosts file to 127.0.0.1. Then Nginx listens on port 80 of 127.0.0.1 and forwards the request to the real back-end service. Perfect!

By the way, www.devtest.com is a domain name that I specially named cannot visit, so you must not resolve www.taobao.com this kind of address to the local oh, otherwise you can’t buy a gift for the goddess don’t blame me…

Today to share with you the dry goods on so many, wish you work on time to accompany the goddess!

See the end, ask a focus like, welcome to add my wechat communication technology, small talk can also oh!

This article uses mdnice smart blue theme layout