reactjs - 独立于后端对 react 前端进行 docker 化是一种好习惯吗？

Question

我即将部署一个 react 应用程序。我的 react 应用程序有一个 API。在 react 开发服务器上，它在端口 3000 上提供 react ，而我的 API 在端口 4000 上。
我看到了两种解决方法。
一种方法是在开发中使用 CORS。如果我们走这条路，我们还需要在生产中使用 CORS。我们将有一个 ENV 文件，它告诉 react 应用程序它应该向哪个主机/端口发出请求。我们的 CI 管道将有 2 个 docker 容器，2 个 repos。当我们部署前端或后端更改时，我们将能够独立重启两台服务器。我们将在 mysite.com 上运行 1 个 docker以及在 api.mysite.com 上运行的 api .
另一种方法是使用 package.json 中的代理并将所有请求转发到我们的后端。即不必向 localhost:4000/sign-in 提出请求我们只是向 /sign-in 提出请求.通过这种方法，我认为使用 monorepo 很有意义。我们会有

app
  api/
    my-api
  ui/
    my-react-app

我的 api 将主要是 RESTful 路由，但是对于所有非 api 路由，这些路由将提供一个 HTML 文件，该文件将为 javascript 提供服务。 CI 管道将构建和最小化并将 JS 推送到 S3 并为其命名，例如 {SHA1}.min.js我们的 API 的 index.html 文件会有

<script src=`{SHA1}.min.js`></script>

我似乎无法决定更好的方法。能够独立部署前端和后端会更简单吗？是否不需要一个只提供一个 html 文件的 docker ？我们应该走哪条路？

Answer 1

注:这个问题没有正确答案(或者可能有多个):这取决于您的环境和您的经验。
在您的应用构建期间，不仅 JS 可能会发生变化。也许您更改了您的网站图标，或可安装的 Logo 或 list 中的其他一些细节，或其他一些 Assets ，如 CSS。因此，部署前端不仅仅是将 JS 部署到 S3 并更改初始 HTML 中的 SHA。
除此之外，使用基本的 NGinx/Apache(可能在 CDN 之后)可以非常快速地提供静态数据。但是您的后端可能需要进行一些计算，从硬盘访问一些数据库或一些数据文件。这是一种不同的工作方式，因此拆分两个部署是一个好主意。它还允许根据需要进行不同的扩展。
无论您是使用单个入口(1 个域)还是将其拆分为两个(2 个域)，我认为这只是您感觉更舒服的方式和您的规模方法的问题。访问 api.yoursite.com/ 并没有太大区别或 yoursite.com/api/从前端。

使用相同的域，捕获 /api/请求将它们代理到后端。其余的请求直接提供或代理到具有静态的第二个网络服务器。如果只是代理的东西，你可以使用 HAProxy 或 Træffick 代替，它可能会比 NGinx 或 Apache 执行得更好。

使用不同的域允许删除第一个代理，这非常快/便宜，但可能允许以不同的方式进行扩展(例如，将更多公共(public) IP 添加到 api.yoursite.com 以实现-缓慢-扩展)。

如您所见，有几个变量:例如，使用 docker-compose 部署到单个服务器是非常不同的。 ，到 Kubernetes 集群或 AWS 的自动缩放组。如果您希望每天获得 100 次访问，这与处理数十亿活跃用户大量访问您的数据库的情况也大不相同。