Nginx能为前端开发带来什么？

IMWeb前端团队

发布于 2019-12-04 12:58:54

5620

发布于 2019-12-04 12:58:54

文章被收录于专栏：IMWeb前端团队IMWeb前端团队

本文作者：IMWeb 黎腾原文出处：IMWeb社区 未经同意，禁止转载

Nginx那么好，我想去看看。

接连逛了两个书城后，我发现并没有Nginx相关的书籍。

这就很奇怪！

Nginx，一名网红（网络服务器红人…），就算没有自传和回忆录，争着介绍它的花边新闻也该有吧。

后来找到仅有的一两本书籍，也直接深入到“源码剖析”的阶段。写得并不十分满意，况且我还不需要这些。

后来发现了原因，大概是因为“使用太简单了，都不值得出书”。

是的，Nginx把纷繁复杂的功能，浓缩成一份简单的配置，极易上手。

当它呈现到你面前时，感觉独具匠心。

Nginx与NodeJs

（这里的标题有点歧义。此处的NodeJs，皆引申为NodeJs所搭建的服务器。）

有人说，作为一名前端，我的真爱是NodeJs。

同时也认同，抛去性能之类的比较，单纯从实现的角度，NodeJs编写的服务器也能实现Nginx的各种功能。

这些我都赞成，但使用Nginx并不意味着抛弃NodeJs。事实上，它们并不冲突，还可以在一起愉快的玩耍。

在业内，这样的模型已很常见：资源转发，反向代理，静态资源处理，负载均衡，这些事情扔给Nginx来处理，只是几行配置的事情；同时在上游，让NodeJs去处理它最擅长的I/O等事情。

合理分配各自擅长的事情，这样的思路，同样可以运用于前端开发中。

以前用NodeJs几百行实现的服务器功能，在npm与github的海洋里花尽心思去寻找的模块，也许在Nginx里是一条成熟的配置。它能帮其分担很多事情，节约了成本。

场景一：环境切换

前端开发中，经常面临多个部署环境切换的问题。

我们通常用配hosts的方式去实现。更优化些，我们将机器的服务绑定了不同的域名：比如正式环境是a.qq.com，测试环境是test.a.qq.com。

然而在拓展性和易用性方面，还不足够好。

而Nginx作为反向代理，就很容易处理资源转发的问题。

思路很简单：

读取请求里的cookie，如果键名host_id有值，则代理到这个IP地址；
如果没有，则代理到默认的正式环境（此处举例为1.1.1.1）;

set $env_id "1.1.1.1";
if ( $http_cookie~* "host_id=(\S+)(;.*|$)") {
    set $env_id $1;
}

location / {
    proxy_set_header Host $host;
    proxy_pass   http://$env_id:80;
}

那接下来的事情，就是怎样用最简便的方式，把IP种在cookie里？

我们应用了nginx-http-footer-filter模块，html文件经过代理时，都注入了一小段js代码。

这段代码，会帮我们展示小菜单，点击某个环境时，则将IP种到cookie里，同时刷新页面，让Nginx完成环境切换。

切换环境，如今只需点击一次。

场景二：SourceMap

在线上环境调试Js代码是件麻烦的事情，因为目前合格的前端部署，代码都应经过压缩。性能问题是优化了，debug可不怎么方便。

而SourceMap正好可以解决此问题。

在最新的各版本浏览器里，如果满足：

压缩后的js文件后面有//# sourceMappingURL=xxx.map格式的注释
浏览器能正常访问到sourceMappingURL

那么，就能把压缩过的代码还原。要实现这样的功能，就必须：

现网环境不带以上形式的注释，同时访问不到sourceMap（安全性考虑）
测试环境带注释，能访问sourceMap

这样的模型，用反向代理+内容纂改的思路再合适不过。

每次构建编译时，我们会把sourceMap文件存放到一台机器（举例为1.1.1.1），命名为js文件名后加.map后缀。随后，使用Nginx，通过这几行配置就能把此功能实现：

location ~ \.js$ {
    footer "\n//# sourceMappingURL=$request_uri.map";
    footer_types "*";
}

只要经过代理，在chrome里，我们能看到每份被压缩过的js文件，都有一个对应的源码文件。

你可以直接使用它来做打断点之类的操作，大大的提升了调试质量。

场景三：内容纂改

其实在以上两个场景里，都涉及了“内容纂改”。

无论是说“纂改”还是“劫持”，大家的印象都不是什么好事情，但另一方面，他们又可以让事情有趣起来。

统一介绍下，Nginx涉及纂改的模块有：

nginx_http_footer_filter：往文件的底部添加文字，可包含Nginx的内置变量；
nginx_http_addition_module：从一个url去读取内容，将之添加到文件的头部或顶部；
nginx_http_sub_module：替换字符

除去上面两种场景，合理运用这些模块对应的配置，可以做出许多小工具，这是很有想象力的事情。

单单针对移动web前端开发，就可以实现：

将weinre脚本插入到html里，让移动web调试更加便捷。
移动web经常用到localStorage优化首屏，但debug时又会受到干扰，通过一个按钮很方便的清除本地缓存。
手机APP内嵌页面，很难将其网址分享给另一个人。通过一个按钮就能生成url对应的二维码等

场景四：本地映射

在Windows下的前端抓包调试，Fiddler+Willow的能力毋庸置疑。

而脱离了.NET体系的Linux和Mac，即使有一些代替工具，但某些方面还是略显不足。

比如：线上接口映射到本地文件。

想到Fiddler的本质也是一个代理，而开启一个有这样能力的Nginx服务，并不是太难的事情。

而且，我们可以做得更灵活，比如：

同时支持慢速调试
同时支持目录层级映射
同时支持正则匹配
JSON返回的数据有可能是变化的（比如分页时候），同时支持动态数据

这些场景，只运用到Nginx里的“rewrite规则”。

从参考的文档可以大致看到，rewrite规则非常灵活，能完成各种场景的转发。

最简单的模型中，我们把所有带cgi-bin路径的请求，rewite到本地的一个服务，同时带上请求的所有参数，

仅需这三行配置即可：

location ~ /cgi-bin/* {
    rewrite ^(.*)$ http://127.0.0.1:8080/cgi-bin/ last;
}

后续的事情，可以在本地创建一个cgi-bin文件夹，在里面放置需要映射的文本，并开启服务到8080端口即可。

场景五：移动侧调试

Fiddler 有一个勾选项 Allow remote computers to connect，并可以指定 listen port 可以使得手机/其它终端通过将本机设为代理而访问本机环境，与 hosts 配合会很实用。

这个功能，用Nginx也很容易做到。

通过 default_server 作为代理，手机终端通过设置网络代理为本机IP和相应的 listen port，从而可以访问本机的 Web 服务。

其中也是用到了ngx_http_proxy_module模块的配置：

 server {
    listen  80 default_server;
    server_name  localhost;
    resolver 8.8.8.8;
    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-Ip $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_pass http://$host;
    }
}

server {
    listen  80;
    server_name  ke.qq.com;
    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-Ip $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_pass http://127.0.0.1:9091/;
    }
}