我正在尝试创建一个网络应用程序，其中：
- 在浏览器上向用户显示一个表(称为 table0(，其中包含行(大约 1000-1500 行(和几列 (5-6( 列。
- 根据 table0 中的数据，根据某些业务逻辑创建 3-4 个新表。
- 用户仅在 table0 上进行一些更改(添加行、删除行、更改某些列的现有行值(。在这里，用户所做的更改可以有很多，相应的更改必须动态地反映在所有后续(生成的(表中(因此，一旦他在 table0 中进行一些更改，他必须立即能够看到新表的更新版本(。
以前我想将业务逻辑(如何从 table0 获取新表(保留在后端，每当用户更改 UI 中的任何内容时，都会使用所有 table0 数据对后端进行 API 调用，后端生成新表并将它们返回到 UI。
主要要求是，在用户对 table0 进行每次更改后，用户都希望看到新的(生成的(表的外观，因此(在当前方法中(导致所有 table0 数据通过网络多次传输到后端，我认为这将使它变慢且不是很动态。此外，在未来，行数可能会增加并进一步缓解此问题。
因此，我正在考虑将业务逻辑转移到前端，但是我在网上读到的任何地方都发现有人建议将业务逻辑保留在后端。那么这个问题有更好的解决方案吗？
这里没有灵丹妙药。您正在处理的是可用性和一致性之间的权衡。
如果一致性更重要：
- 当用户完成主表的编辑后，您可以执行请求，其中包含对后端的更改。然后，后端将更新主表和生成的表。然后，后端将 200 Ok 返回到前端客户端。
- 前端等待，在从上一个请求收到 200 Ok 后，它通过其他请求从后端获取更新生成的表(这可以根据您的业务逻辑进行优化(。
- 如果您的持久性需求允许，请查看用于创建和维护生成的表的具体化视图。
- 主要缺点是这种方法较慢。
如果可用性更重要：
- 当用户完成主表的编辑后，您可以对后端进行更改。后端继续执行更新逻辑。
- 您不会在前端阻止并等待后端的 200 Ok，而是手动更新前端生成的表。
- 此方法工作正常，只要对后端的第一个请求不会失败。如果该请求失败，前端将显示不一致的数据。
- 这种方法的另一个缺点是业务逻辑会潜伏在前端，并且很可能最终也会在后端复制。
- 这种方法将带来更好的用户体验。