使用浏览器缓存进行增量更新 [英] Incremental updates using browser cache

问题描述

客户端（AngularJS应用程序）从服务器获取相当大的列表。这些列表可能有数百或数千个元素，这可能意味着几兆字节未压缩（并且一些用户（管理员）获得更多数据）。

The client (an AngularJS application) gets rather big lists from the server. The lists may have hundreds or thousands of elements, which can mean a few megabytes uncompressed (and some users (admins) get much more data).

我不打算让客户端得到部分结果，因为排序和过滤不应该打扰服务器。

I'm not planning to let the client get partial results as sorting and filtering should not bother the server.

压缩工作正常（因数大约为10）并且因为列表不经常更改， 304 NOT MODIFIED 也有很多帮助。但是缺少另一个重要的优化：

Compression works fine (factor of about 10) and as the lists don't change often, 304 NOT MODIFIED helps a lot, too. But another important optimization is missing:

由于列表的典型更改相当小（例如，修改两个元素并添加新元素），仅传输更改声音喜欢一个好主意。我想知道如何正确地做到这一点。

As a typical change of the lists are rather small (e.g., modifying two elements and adding a new one), transferring the changes only sounds like a good idea. I wonder how to do it properly.

类似 GET / offer / 123 / items 应该始终返回商品号码123中的所有商品，对吗？这里可以使用压缩和304，但没有增量更新。像 GET / offer / 123 / items？since = 1495765733 这样的请求听起来像是要走的路，但随后是浏览器缓存没有被使用：

Something like GET /offer/123/items should always return all the items in the offer number 123, right? Compression and 304 can be used here, but no incremental update. A request like GET /offer/123/items?since=1495765733 sounds like the way to go, but then browser caching does not get used:

• 要么没有改变，答案是空的（缓存没有意义）


• 或者有些东西发生了变化，客户端更新了它的状态，并且从不再要求自1495765733以来的更改（并且缓存它更不合理）

显然，当使用since查询时，资源不会缓存任何内容（原始查询只使用一次或根本不使用）。

Obviously, when using the "since" query, nothing will be cached for the "resource" (the original query gets used just once or not at all).

所以我不能依赖浏览器缓存，我只能使用 localStorage 或 sessionStorage ，它有一些缺点：

So I can't rely on the browser cache and I can only use localStorage or sessionStorage, which have a few downsides:

• 它被限制在几兆字节（浏览器HTTP缓存可能会大得多并自动处理）


• 当我达到限制时，我必须实施一些替换策略


• 浏览r缓存存储已经压缩的数据，我没有得到（我必须重新压缩它们）


• 它不适用于用户（管理员）获得更大的列表甚至单个列表可能已经超出限制


• 它在注销时被清空（客户的要求）

• it's limited to a few megabytes (the browser HTTP cache may be much bigger and gets handled automatically)
• I have to implement some replacement strategy when I hit the limit
• the browser cache stores already compressed data which I don't get (I'd have to re-compress them)
• it doesn't work for the users (admins) getting bigger lists as even a single list may already be over limit
• it gets emptied on logout (a customer's requirement)

鉴于有HTML 5和HTTP 2.0，这非常令人不满意。我缺少什么？

Given that there's HTML 5 and HTTP 2.0, that's pretty unsatisfactory. What am I missing?

是否可以将浏览器HTTP缓存与增量更新一起使用？

推荐答案

我认为你缺少一件事：总之，标题。我认为你可以做的，这符合（大多数）你的要求，将是：

I think there is one thing you are missing: in short, headers. What I'm thinking you could do and that would match (most) of your requirements, would be to:

• 首先 GET / offer / 123 / items 正常完成，没什么特别的。


• Subsequents GET / offer / 123 / items 将以 Fetched-At发送：1495765733 标题，指示您的服务器何时发送初始请求。

• First GET /offer/123/items is done normally, nothing special.
• Subsequents GET /offer/123/items will be sent with a Fetched-At: 1495765733 header, indicating your server when the initial request has been sent.

从现在开始，可能有两种情况。

From this point on, two scenarios are possible.

• 要么没有变化，你可以发送304。


• 如果有的话但是，更改新项目，因为先前发送的时间戳包含标题，但是从您的回复中设置 Cache-Control：no-cache 。

• Either there is no change, and you can send the 304.
• If there is a change however, return the new items since the time stamp previously sent has headers, but set a Cache-Control: no-cache from your response.

这使您可以进行增量更新，并缓存初始兆字节大小的元素。

This leaves you to the point where you can have incremental updates, with caching of the initial megabytes-sized elements.

但仍有一个缺点，即缓存只进行一次，它不会缓存更新。你说你的名单不经常更新，所以它可能已经适合你，但如果你真的想进一步推动，我可以想到一件事。

There is still one drawback though, that the caching is only done once, it won't cache updates. You said that your lists are not updated often so it might already work for you, but if you really want to push this further, I could think of one more thing.

收到增量更新后，您可以在后台触发另一个请求，而不会使用您的应用程序根本不会使用的 Fetched-At 标头，但只会在那里更新您的http缓存。它不应该像在性能方面那么糟糕，因为你的框架不会用新的数据更新它的数据（并且可能触发重新渲染），唯一值得注意的缺点是网络和内存消耗。在移动设备上它可能会有问题，但它听起来并不像是打算在它们上显示的应用程序。

Upon receiving an incremental update, you could trigger in the background another request without the Fetched-At header that won't be used at all by your application, but will just be there to update your http cache. It should not be as bad as it sounds performance-wise since your framework won't update its data with the new one (and potentially trigger re-renders), the only notable drawback would be in term of network and memory consumption. On mobile it might be problematic, but it doesn't sounds like an app intended to be displayed on them anyway.

_{我绝对不知道你的用途-case，只会把它扔出去，但你真的确定做某种分页是行不通的吗？对于普通人来说，显示和处理的兆字节数据听起来很多;）}

这篇关于使用浏览器缓存进行增量更新的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！