AWS：使用 api 网关代理 EC2 实例中服务的前端和后端 api 端点是一种好习惯吗？

Question

我正在 AWS 中构建我的应用程序。

我已经在 EC2 实例中部署了我的 Reactjs 前端项目：172.0.0.1:80。

我还在另一个 EC2 实例中部署了运行许多 api 端点的 Typescript/Express JS 后端服务：172.0.0.2:3000。

172.0.0.1 和 172.0.0.2 是 EC2 实例的 VPC 私有 IP 地址。

我正在尝试将 AWS API Gateway 用于反向代理，但我不确定这是否是一种好的做法，或者是一般使用 AWS 云工具的好方法。详情如下：

• 我已将我的自定义域配置到 api 网关，以便对 www.myapp.com 的任何访问都定向到 api 网关。

• 如果用户在浏览器中输入 url www.myapp.com，API Gateway 会将 http GET 请求代理到 172.0.0.1:80

• 当用户与前端交互时，会触发 GET/PUT/POST 请求，并且目标 URL 都具有www.myapp.com/api/[xxx] 之类的模式。例如 www.myapp.com/api/user, www.myapp.com/api/photos, ....

  API 网关会将这些请求代理到172.0.0.2:3000。

• 我还想将 AWS Cognito 服务与 API 网关集成以进行身份​​验证，以便用户可以登录/注销。

现在，以这种方式使用 api 网关是一种好习惯吗？

这是在 AWS 云上托管应用程序的正确方法吗？

Answer 1

这似乎是一种合理的方法。这是一个有点自以为是的问题，因为“良好实践和“正确方式”是主观的。API 网关很灵活，允许许多可能是“良好实践”的使用模式，并且可以以“正确方式”完成，但仍然是完全不同。

也就是说，这种方法似乎是合理的，但您可能能够以不同的方式托管前端项目以提高效率。考虑Building server-side rendering for React in AWS Lambda 中显示的方法：

在这种方法中，前端是静态的并呈现在客户端上，因此使用 S3 存储静态文件并使用 CloudFront 分发这些文件是一种很好的方法。它显示了一个由 Lambda 处理的动态后端，它具有无服务器的优势，但它也可以是 EC2。如果您的前端代码不是静态的，或者您希望来自 EC2 实例，则可以改为使用 API Gateway，如您所述。

与这张图片相比，我喜欢你的方法的一点是，客户端为应用程序提供了一个域，而 API Gateway 将路由路由到正确的端点。这样可以对最终用户隐藏一些实现细节。