许多小请求 vs 少量大请求 - Angular 到 Django REST API - 无涉及数据库

Question

我知道stackoverflow上有相关的问题，但是我不确定我所面临的条件是否会对答案造成任何改变，所以我在这里发问。 我正在使用Angular创建一个简单的webapp，该应用程序从用户导入电子表格数据，并将数据发送到Django后端进行数据分析。 数据结果返回给前端，Angular创建了结果的仪表板。每个电子表格列都显示为图表。我面临两个选择：

a）将电子表格保留在浏览器内存中，并将每个数据列单独发送到执行数据分析并返回结果的Django服务器。

优点：简单的架构，无需缓存。 缺点：如果工作表中有150个列，则会导致向API的150次调用。

b）发送整个数据表并让Python处理所有内容。 它将返回一个大块数据，需要由Angular解包。

优点：每个文件仅有一个请求。 缺点：对于相同文件的后续调用，可能需要缓存。如果文件已更改，则可能会导致旧数据。我还可能需要针对每个用户维护会话。

我正在使用以下限制进行开发：我不能在Django服务器或DB上存储文档。即使这只是一个内部应用程序，文档可能是敏感的，用户不会接受任何形式的存储。

此外，文件的大小很可能超过100 MB，因此这也成为一个因素。在这种情况下，“许多小请求”是否更有意义？如果问题是重复的，请提前道歉。

- javapyscript

Answer 1

你没有考虑的另一个因素是浏览器（假设是Chrome）每个主机只分配6个TCP端口。这意味着，如果采用“许多小请求”的方法，取决于后端处理该请求需要多长时间，您可能会面临一些严重的性能问题。

还有一个需要考虑的因素是，如何处理数据回滚？如果已完成50％（75个）的请求，用户想要取消或浏览器崩溃等，那么剩余的50％会发生什么情况？

如果这是在快速网络上运行的内部应用程序，我个人会选择单个文件的批量一次性请求。在100GB网络上，100MB并不会拖累太多。

如果不在内部网络上，则必须选择微交易，因为上传到99％然后在10分钟后失败的用户体验是我们所有人都经历过的（糟糕）。至少使用微交易方法，您可以控制数据回滚，并且甚至可以在前端打开套接字以提供更新。例如，如果在处理过程中某个列失败了，angular可以尝试重新发送它等。

没有适用于所有情况的解决方案，这只是我的个人意见。

- Zze

---

感谢您提供如此详细的答案。我想我不必担心回滚了。REST API 的输入是电子表格数据，从 REST 到前端的输出是图表绘制坐标。前端只有在 Angular 中所有数据都准备好后才会更新，这意味着如果用户中途中止，他们什么也没看到，浏览器会自动丢弃收集的临时数据，而 REST API 也不知道，因为它只是按需提供服务。如果我的理解有误，请告诉我。谢谢。 - javapyscript