有大量用户交互的数据分析web应用程序的业务逻辑保存在哪里

Question

我正在尝试创建一个web应用程序，其中：

• 用户在浏览器上显示了一个表(称为table0)，其中包含行(大约1000-1500行)和一些列(5-6列)。
• 根据table0中的数据，将根据某些业务逻辑创建3-4个新表。
• 用户只在table0上进行一些更改(添加行、删除行、更改某些列的现有行值)。在这里，用户所做的更改可以是多个，相应的更改必须动态地反映在所有后续(生成)表中(因此，一旦他在table0中做了一些更改，他就必须立即能够看到新表的更新版本)。

以前，我考虑将业务逻辑(如何从table0获取新表)保留在后端，每当用户在UI中更改任何内容时，都会使用所有table0数据对后端进行API调用，后端生成新表并将它们返回给UI。

主要的要求是，在用户对table0所做的每一次更改之后，用户都希望看到新表(生成的)是什么样的，因此(在当前的方法中)导致所有table0数据在网络上传输很多次，我认为这将使其速度慢，而不是非常动态。而且在将来，行数可能会增加，并进一步缓解这一问题。

所以，我想把业务逻辑移到前端，但是无论我在网上读到什么地方，我都发现有人建议把业务逻辑保留在后端。那么，这个问题有什么更好的解决办法呢？

Answer 1

这里没有银弹。你所面对的是在可用性和一致性之间的权衡。

如果一致性更重要：

• 当用户完成对主表的编辑时，您将通过对后端的更改执行请求。后端将更新主表和生成的表。后端然后向前端客户端返回200 Ok。
• 前端等待，在从前一个请求接收到200个Ok之后，它通过额外的请求从后端获得更新的生成表(可以根据业务逻辑对此进行优化)。
• 如果持久化需求允许，请查看用于创建和维护生成表的物化视图。
• 主要的缺点是这种方法速度较慢。

如果可用性更重要，：

• 当用户完成主表的编辑时，您将通过对后端的更改来执行请求。后端继续进行更新逻辑。
• 您的不会在前端阻塞并等待后端的200 Ok，而是手动更新前端生成的表。
• 这种方法工作得很好，因为对后端的第一个请求不会失败。如果请求失败，您的前端将显示不一致的数据。
• 这种方法的另一个缺点是业务逻辑将潜伏在前端，并且很可能最终也会在后端重复。
• 这种方法将带来更好的用户体验。