情境：
行为：
当用户进入网站时，会向他们显示一系列图书。 其中一些已经在他们的“Read Later”列表中，有些则不是。
用户在每本书旁边都有一个指示，告诉他们该书是否已添加到列表中。
我的问题
我在辩论哪种方案适合我的情况。
选项1：
临 对服务器的请求非常小，响应非常简单（真或假）。
Con：在包含30本书的页面中，我将发送30个单独的http请求，这些请求可以阻止套接字，并且考虑到浏览器和服务器必须为每个执行整个握手，因此速度相当慢交易。
选项2：
专业版：我只提出一个请求，并立即更新所有图书的指标。
Con：“稍后读取”列表可能包含数百本书，传递大型数据可能会导致速度过慢。特别是在屏幕上没有出现30本书的情况下，只有2-3本。 （也就是说，我想检查某个书是否在列表中，为此我让服务器从列表中向客户端发送整个书籍列表。）
因此，
您将以哪种方式最大限度地提高效果：1还是2？
我有什么替代品吗？
答案 0 :(得分：12)
我认为2017年的解决方案不是关于整体性能，而是关于用户体验和用户期望。
现在用户不能容忍延迟。从这个意义上讲，复杂的用户界面尽可能快地响应。因此：如果您可以使用这些小请求来启用用户执行某些操作（而不是等待一个大请求返回2秒），您应该更喜欢该解决方案。
据我所知，有很多“高保真”网站有一个页面可能会发送50个，100个请求......所以我会考虑这种常见做法。
也许它在这里很有用：se-radio.net podcast episode 277在尾部延迟的背景下深入讨论这个主题。
答案 1 :(得分：4)
选项1听起来不错，但在可扩展性方面存在很大问题。
选项2减轻了这种可扩展性问题，我们可以改进其设计：
客户端通过javascript收集仅显示的图书ID，并通过ajax查询一次读取后续信息，仅适用于这30本书。通过这种方式，您仍然可以快速提供页面并请求一小组附加信息，一次只需一个http请求。
服务器端，您可以进一步改进为每个用户缓存读取后ID的内存数组。
答案 2 :(得分：2)
在我看来，这取决于数据的存储方式。如果正在使用关系数据库，只需在相应的表上进行连接，就可以轻松地将布尔标志放入书籍列表中。 这很可能会给你最好的结果，你不必在前端编写任何算法。