React / Nextjs SSR和API-云架构偏好

Question

如果您在Node.js中有一个SSR Web服务器并且要托管一个API（也在Node.js中），那么“一般”是一种更好的设计来托管和扩展这些分组在一起的资源，或者在其中使用每个节点两者的集群？我附了一张图表，以更好地解释我的意思。

之所以这样问，是因为互联网上的许多项目都表明Express API和React SSR正在同一资源库中构建并一起部署。通常这与我认为是标准程序的做法背道而驰，但我开始怀疑自己，并希望从社区中获得一些投入。

在配置A中，每个云服务器都有两个进程，一个为next.js Web服务器，另一个为node.js Express API。配置B将这两个部分分开。

以下是一些明显的优点-我都能看到两者的缺点，但是我想知道我是忽略了明显的内容还是大多数开发人员都选择一条道路而不是另一条道路。

配置A

优点

• 成本更低（SSR和API之间的网络流量可以在本地完成）
• 更容易设置和维护云基础架构
• 共享代码（全部使用JS-包括本地代码模块）

缺点

• 可能无法很好地扩展（如果每个服务器API占用80％的CPU，那么即使您不需要额外的SSR容量，您也不得不同时扩展这两者）
• 安全风险（如果有人闯入您的Web服务器，则他们可以直接访问连接到数据库的服务器）
• 单点故障（即使只有Web服务器是DDOS，API也会受到影响）

配置B

优点

• 更好的可扩展性
• 更好的安全性（如果正确实施）
• 更容易的部署（重启服务器仅影响目标实例）

缺点

• 价格更高
• 从SSR（预渲染）进行的API调用速度较慢
• 重复代码（例如React JWT解码等）

Answer 1

通常来说，解决方案B是生产环境中的首选方法。如您所述，可伸缩性会更好，并且您可以更改API节点而不影响SSR节点，并且流量将在这两个部署组之间分配。如果您的API陷入困境，那么您的网页仍会响应加载（假设初始渲染不依赖于API调用）。第二种方法的另一个好处是可以使用Redis或Memcache之类的功能来缓存API调用。

如果您只是部署一个小项目或不期望太多流量，则可能不需要方法B的复杂性，这就是为什么很多人选择沿着路线A前进的原因，因为您根本不这样做需要额外的并发症。