我知道有关于SO的相关问题，但我不确定要求我处理的条件是否会导致答案发生任何变化，所以我在这里问。
我正在 Angular 中创建一个简单的 Web 应用程序，它从用户那里导入电子表格数据并将数据发送到对其进行数据分析的 Django 后端。数据结果返回到前端，Angular 创建结果的仪表板。电子表格的每一列都显示一个图表。我面临两种选择：
a) 将电子表格保存在浏览器内存中，并将每列数据分别发送到 Django 服务器，该服务器对数据进行分析并返回结果。
优点：简单的架构。无需缓存。
缺点： 如果工作表中有 150 列，则会导致 150 列 调用该用户的 API。
b)发送整个数据表，让python处理所有事情。它将返回一大块数据作为回报，这些数据必须由 Angular 解压缩。
优点：每个文件只有一个请求。
缺点：对于同一文件的后续调用，我可能需要缓存？如果 文件已更改，可能会导致数据过时。 我可能还需要维护每个用户的会话。
我正在使用的限制：我不能将文档存储在 Django 服务器或数据库上。即使这只是一个内部应用程序，文档也可能很敏感，用户不会对任何类型的存储感到舒服。
此外，文件的大小很可能为 100+ MB，因此这也成为一个因素。
在这种情况下，"许多小请求"是否更有意义？ 如果问题重复，请提前道歉。
您没有考虑的另一个因素是浏览器(例如 Chrome)仅为每个主机分配 6 个 TCP 端口。这意味着，如果您采用"许多小请求"方法，您可能会面临一些严重的性能问题，具体取决于在后端处理该请求所需的时间。
另一个需要考虑的因素是您将如何处理数据回滚？如果您通过了 50% (75) 的请求，并且用户想要取消或浏览器崩溃等，那么其他 50% 会发生什么？
如果这是一个在快速网络上运行的内部应用程序，我个人只会为每个文件批量一个请求。 100GB 网络上的 100MB 并不是太大的拖累。
如果它不在内部网络上，那么我将不得不选择微交易，因为我相信我们都经历过的用户体验达到 99% 的上传并在 10 分钟后失败(糟糕)。至少使用微事务方法，您可以控制数据回滚，甚至可以在前端打开套接字以提供更新。就像如果某个列在处理过程中失败一样，angular 可以尝试重新发送它等。
这里没有一种尺寸，这只是我的意见。