我们应该如何决定一些逻辑应该在前端还是后端实现？

Question

我有一个关于网页设计和开发的非常普遍的问题。我们应该如何决定一些逻辑应该在前端还是后端实现？对此有一般指导或原则吗？

我们的用例：我们有一个内部门户网站（React + AWS Lambda 和 API 网关）。我们想向门户添加一项新功能来预测产品销售。用户可以提供产品、目标日期等。UI 将根据不同的折扣（10%、20%、30% 等）显示多个预测销售额。另一个功能是用户上传配置集合的 CSV 文件，UI 会以 CSV 文件形式提供结果以供下载。我们目前已经有一个外部服务提供一个 API，该 API 获取带有配置和响应预测的产品列表。所以我们的后端 lambda 需要连接到该服务。根据我的理解，我们有两个选择：

1. 后端（AWS Lambda+API Gateway）公开一个简单的通用API（类似于ML服务）。它获取具有配置的产品列表，并响应它们的预测列表。在这种情况下，前端有责任根据不同的用例构建请求。例如，需要通过不同的折扣来扩大用户的输入。如果用户上传文件，则需要解析文件并将其转换为API的请求格式，前端收到响应后需要将其转换为CSV文件进行下载。由于前端已经构建了请求并处理响应，后端 lambda 除了将请求转发到 ML 服务之外什么也不做。
   • 优点：
     • API本身是可扩展的。如果我们需要更多的 UI 功能，例如使用更多配置绘制图表，我们可以简单地重用相同的 API。
   • 缺点：
     • UI 很重，后端除了请求转发什么都不做。如果我们走这条路的话，可能会更重，比如文件解析、创建等。
2. 后端（Lambda+API Gateway）暴露特定的API，而不仅仅是一个。它接受用户的输入并将输入扩展为具有配置（例如不同折扣）的产品列表。之后后端调用ML Service获取预测结果，并按照前端需要的格式返回结果供前端渲染。在本例中，我们可能有 2 个 API。第一个是针对单一产品案例，它采用具有其他用户输入的产品并响应返回基于不同折扣的预测列表。第二个 API 用于文件上传-下载情况，它将文件作为输入并响应文件或 URL。在这种情况下，前端将纯粹关注用户体验和数据渲染。
   • 优点：
     • UI可以纯粹专注于用户体验和数据渲染。
   • 缺点：
     • 后端API非常具体且不可扩展，我们将来必须添加更多API。从开发的角度来看，这是次要的，因为 lambda 本身基于 Spring Boot，因此可以轻松地使用 @RequestMapping 在控制器中添加更多 API。

我是网页设计和开发的新手，因此任何信息、指导或资源参考都将受到高度赞赏！谢谢！

Answer 1

还要考虑的另一件事是查看这两个服务之间是否存在紧密耦合。发布后端服务变更的工作量是多少？与前端服务部署是否紧密耦合。 是否可以将两个服务部署解耦？然后，考虑到向后兼容性，我们会选择独立部署这两个服务中的更改。

还有一些其他事情可以让你更容易做出决定，但从高层次来看，最好是，如果我们解耦服务，以便任何更改/恢复都更快、更安全。

但是，是的，正如 @J Asgarov 提到的：“最后，这是你的决定 - 做出选择，看看什么有效。”