很多小请求vs几个大请求-Django REST API的角度-不涉及数据库

问题描述 投票:4回答:1

我知道关于SO的相关问题,但是我不确定要求我处理的条件是否会导致答案的任何变化,因此我在这里提出。

我正在Angular中创建一个简单的Web应用程序,该应用程序将从用户导入电子表格数据并将其发送到对它进行数据分析的Django后端。数据结果返回到前端,Angular创建结果的仪表板。电子表格的每一列都会显示一个图表。我面临两个选择:

a)将电子表格保存在浏览器内存中,并将每列数据分别发送到Django服务器,后者对数据进行分析并返回结果。

优点:简单的体系结构。无需缓存。

缺点:如果工作表中有150列,则结果为150对该用户的API调用。

b)发送整个数据表,然后让python处理一切。它将返回大量数据,这些数据必须由Angular解压缩。

优点:每个文件仅一个请求。

缺点:对于后续对同一文件的调用,我可能需要缓存吗?如果文件已更改,可能会导致数据过时。我可能还需要维护每个用户的会话。

我正在使用的限制:我无法将文档存储在Django服务器或DB上。即使这只是一个内部应用程序,文档也可能很敏感,并且用户将不习惯任何形式的存储。

而且,文件的大小很有可能超过100 MB,因此也成为一个因素。

在这种情况下,实施“许多小请求”是否更有意义?如果问题重复,请提前致歉。

python django angular client-server backend
1个回答
2
投票

您没有考虑的另一个因素是浏览器(例如Chrome)仅分配6 TCP ports per host。这意味着,如果您采用“许多小请求”方法,则可能会遇到一些严重的性能问题,具体取决于在后端处理该请求所花费的时间。

另一个要考虑的因素是您将如何处理数据回滚?如果您处理了50%(75)的请求,而用户想取消请求或浏览器崩溃等,那么其他50%会怎样?

如果这是运行在快速网络上的内部应用程序,我个人将只处理每个文件的一个请求。 100GB网络上的100MB并不是那么大的负担。

如果它不在内部网络上,那么我将不得不选择微交易,因为我相信我们都经历了(糟糕)的事情,获得​​上载的99%且在10分钟后失败的用户体验。至少使用微事务处理方法,您可以控制数据回滚,甚至可以打开前端的套接字以进行更新。就像某个列在处理过程中失败一样,那么angular可以尝试重新发送它,等等。

这里没有一个合适的尺码,这只是我的意见。

© www.soinside.com 2019 - 2024. All rights reserved.