在 Node 的不同机器上将 API 调用从前端重定向到后端

Question

我有一个 Node 应用程序，它应该运行一个 Docker 容器的前端和另一个容器的后端。前端和后端都使用 Express。目前我正在尝试将从前端客户端调用的 API 重定向到后端。

示例：38.127.211.116 上的前端运行ning 调用 api /api/get-price/toy/1 并且此 api 应转发到后端运行ning 87.105.146.57.

我设法在前端服务器中使用代理来做到这一点，我使用了一个名为“http-proxy-middleware”的 npm 包。目前我的代码看起来像这样（路径下的所有内容 ?api 都转发到后端）：

.use('/api', createProxyMiddleware({
    target: process.env.NODE_ENV === "prod" ? "someValue" : https://${devIpAddress}:${process.env.BACKEND_PORT}/`,
    // changeOrigin: true,
   secure: process.env.NODE_ENV === "prod" ? true : false // is it safe to have false in prod?
}))

我有几个问题，因为我不完全理解不同方法的含义：

代理与 CORS：这种方法（从前端到后端的代理）还是从前端到后端的直接调用允许后端中的 CORS 更好？有哪些优缺点？
代理中的安全选项：我可以从文档中阅读：'set secure to true/false, if you want to verify the SSL Certs'。如果我总是使用 false，也在 prod 中使用，那么缺点是什么？我会有安全问题吗？如果有，是哪一个？因为使用代理我的后端地址是隐藏的（？）但是如果我只有一台机器每个用户无论如何都可以看到和调用我的所有 API 那么验证调用者有什么意义？
代理中的来源选项：启用更改源的优势是什么？
身份验证：该网站的一些页面将需要用户身份验证。对于 API，我认为该过程将非常简单，因为调用将被重定向到后端，响应将根据用户凭据以正确的响应传回。我对前端的用户身份验证处理更感兴趣。因为我必须提供 html 页面，而这些页面应该只提供给记录 users.But 具有凭据的数据库在后端，所以这里最好的策略是什么？我想在共享 public Express 文件夹的代码之前放置一个中间件，并在用户请求需要登录的页面时向后端发送 http 请求。如果响应是肯定的，则请求将继续显示页面继续，否则它将退出。但我想知道这是否是正确的方法。类似于：

.use("/admin", ()=>{
    // pseudo code
     const result = httpCallToBackend();
     if(!result) exit;
 }) // if positive go to next instruction - show html page
.use(express.static(process.env.STATIC_FOLDER_PATH, { extensions: ["html"] }))

Answer 1

意见问题，这是我的...

代理与 CORS。通常我会推荐从浏览器直接调用 API 并根据需要使用 CORS。如果前端和后端服务器不在同一地点（就像您的情况一样），直接调用尤为重要。通过代理，您在服务器之间增加了额外的网络开销，并为用户增加了一个额外的跃点。没有太多理由使用代理，除非您有一些需要它的业务需求。
安全。使用代理时，您直接从一台服务器与另一台服务器进行通信。有些人可能觉得在这种情况下不需要额外的安全性，可以将 secure 设置为 false。同样，如果您的服务器不在同一地点，那么我肯定会保留它。
改变起点。仅当您在使用源来定义应用程序以将调用定向到的多租户虚拟服务器上时，这才重要。对于容器化，这在最近是非常不寻常的。
身份验证。这是代理可能更好的原因之一。使用代理，您将能够在单个服务器上的任何路由上设置授权中间件。就个人而言，我认为这还不够。我会让前端服务器调用后端服务器以获取登录用户信息，然后您可以在两个服务器上独立进行身份验证。

在 Node 的不同机器上将 API 调用从前端重定向到后端

Redirect APIs calls from frontend to backend on different machines in Node

proxy

backend

node.js

express

docker