共计 2906 个字符，预计需要花费 8 分钟才能阅读完成。
近年来，前后端拆散曾经成为中大型软件我的项目开发的最佳实际。
在技术层面，前后端拆散指在同一个 Web 零碎中，前端服务器和后端服务器采纳不同的技术栈，利用规范的 WebAPI 实现协同工作。这种前后端拆散的 ” 混合开发 ” 模式下，前后端通常会部署到不同的服务器上，即使部署在同一台机器，因为宿主程序（如后端用 Tomcat，前端用 nginx）不同，端口号也很难对立。
（图片起源网络）
这意味着位于 A 域（如 https://foo:80/website）的页面，须要调用 B 域的 WebAPI（如 https://bar:8080/webservice），这是一个典型的跨域拜访，浏览器默认会断定该操作有平安危险。如果不进行解决，则会回绝这次 WebAPI 调用，提醒对应的谬误。
（跨域申请导致的谬误）
当初如何该怎么解决跨域的问题呢？目前有 4 个支流技术计划：
JSONP
如果你须要解决的申请只有 GET，能够思考 JSONP。
JSONP 的原理就是利用 \<script\> 标签没有跨域限度的特点，通过 \<script\> 标签 src 属性，发送带有 callback 参数的 GET 申请，服务端将接口返回数据拼凑到 callback 函数中，返回给浏览器，浏览器解析执行，从而前端拿到 callback 函数返回的数据。
（JSONP 的调用流程）
这种做法很惯例，然而你须要为前端提供 JSONP 的响应，其余终端调用时提供不带 JSONP 的响应，因而会带来额定的开发和测试工作量。
iFrame
通常状况下，前后端拆散带来的跨域拜访都局限在同一个主域的不同子域（如 a.foo.com 和 b.foo.com）之间。所以，你能够利用 iFrame 加载位于被调用 WebAPI 所在域的页面，而后将两个页面的 document.domain 设置为主域名（如 foo.com），就通过 iFrame 中的子页面申请 WebAPI 了。
（图片起源网络）
这种做法比拟麻烦，咱们须要为 WebAPI 配套开发起直达作用的页面，但对于开发者而言仍旧有很大的开发工作量。
CORS
和前两种计划相比，CORS（跨域资源共享）是一个 ” 一劳永逸 ” 的计划。
咱们不须要为每个 WebAPI 做额定的解决，而是须要在后端程序启动时，减少一些解决工作。支流的后端服务都有解决 CORS 的类库，这里就不再做开展介绍了。
这个计划的外围原理，是在发动正式的申请前，先发送一个 OPTIONS 谓词的 HTTP 申请，询问发动申请的页面是否有调用该域服务的权限；如果后端说 OK，浏览器就持续申请，否则提醒谬误。
应用这种计划的开发工作量小，如果间接应用成熟类库的话，开发和测试的工作量甚至能够忽略不计。不过，因为每个跨域的申请都会触发一次往外的 OPTIONS 申请，对服务器会造成额定的开销和压力。
反向代理
反向代理机制，把前端的 A 域和后端的 B 域合并成一个 C 域，从根本上解决跨域问题。
这个计划仅需配置，对前后端的程序没有侵入；同时内网中的反向代理通常也不会带来额定的性能开销。
（图片起源网络）
总体来说在编码开发的时代，上述四种计划都有实用的利用场景，各有优缺点。进入低代码开发时代后，前后端拆散的利用面更广，如应用 JavaScript 编码开发前端、配合低代码构建的后端，或应用 Java 编码开发后端，供低代码构建的前端调用。
（低代码时代的前后端拆散，来自 低代码沙龙）
低代码开发的外围价值在于节俭开发投入，晋升开发效率，所以，计划 1（JSONP）和计划 2（iFrame）曾经很少被用到低代码混合开发畛域。相比于计划 3（CORS），计划 4（反向代理）因为性能开销较小，利用场景会更多一些。
上面，咱们将以活字格 +nginx 为例，介绍利用 nginx 解决跨域问题，实现前后端拆散的具体做法。
（反向代理的架构示意图）
利用 nginx 解决跨域问题
- 开始配置之前，咱们应用活字格开发两个利用，仅蕴含前端页面的 frontend 和蕴含后端 WebAPI（服务端命令）的 backend，并将其别离公布到物理机或云主机上，利用的端口设置为 8081 和 8080。咱们能够通过以下地址拜访这两个利用：
- 后端：http://host\_name:8080/backend
- 前端：http://host\_name\_2:8081/frontend
- 装置 nginx，并在配置文件 /conf/nginx.conf 中 HTTP 节点配置前后端的服务器，即 upstream 节点：
upstream backend {server host\_name:8080;}
upstream frontend {server host\_name\_2:8081;}
- 在 HTTP 节点下的 server 节点，配置监听端口和转发策略，这样就能够将 http://host\_name:8080/backend 映射为 http://proxy\_name:8000/backend，http://host\_name\_2:8081/frontend 映射为 http://proxy\_name:8000/frontend
listen 8000;
server\_name proxy\_name;
location /frontend {proxy\_pass http://frontend/frontend ;}
location /backend {proxy\_pass http://backend/backend ;}
- 上述操作后，用户拜访的域名对立成了 http://proxy\_name:8000，跨域问题解决了。然而，不要焦急。活字格默认会启用 Http Referer 验证机制，不容许跨域调用内置服务。所以，你还须要关上前端利用所在的服务端的治理控制台 http://host\_name\_2:22345/UserService/ManagementPage/WebSecurity
在 HTTP Referrer 容许列表中增加 nginx 代理服务器的地址（也就是用户理论应用的地址，记得在前面加一个 * 号适配）。
- 配置实现后，你能够就能够在前端页面中通过【发送 HTTP 申请命令】，调用后端的 WebAPI 了。
（在前端调用后端 WebAPI 并弹窗显示返回后果）
特地提醒：如果你须要将前端、后端和 nginx 部署在同一台机器上，能够将上述 proxy\_name、host\_name、host\_name\_2 对立替换为你的机器名或 IP 地址。
作为一款弱小的反向代理和 Web 服务器，nginx 的用处十分宽泛，本文仅仅应用到了它的反向代理性能。除此之外对于负载平衡的解决 nginx 也有很优良的体现，在后续内容中咱们会为大家做更加深刻的介绍。
如需具体理解如何应用低代码开发前后端拆散的企业级利用，疾速转型全栈工程师，能够查看：
https://gcdn.grapecity.com.cn/forum.php?mod=viewthread&tid=146511&extra=page%3D1%26filter%3Dtypeid%26typeid%3D272
除此之外如果你对更多低代码行业现状与发展趋势感兴趣能够查看：
https://help.grapecity.com.cn…
