reactjs - 缓存问题 : React + REST server behind CDN

Question

我正在寻找一种模式，可以让我为我的用户改善 UX。我有一个在 CloudFront 后面运行的 REST 服务器，它被前端的普通 React 应用程序使用。
我将简化我的例子来说明我的问题。
我有一个名为 GET /posts/<id> 的端点.当浏览器要求它时，它带有 max=age=180这意味着它将被存储在浏览器的缓存中以及对 GET /posts/<id> 的任何后续调用将在这 180 秒的持续时间内从浏览器的缓存中提供服务，之后它将再次访问 CDN 以尝试获取新副本。
这对大多数用户来说没问题。我不介意任何帖子的更新在传播给所有用户之前最多延迟 3 分钟。但是有一个用户是这篇文章的作者。该用户可以使用 PATCH /posts/<id> 更改此帖子.让我们调用那个用户 编辑 .
这是我现在遇到的一个场景:

编辑器加载帖子页面，然后调用 GET /posts/5

CDN 将最新的副本提供给前端。

编辑然后对帖子进行更改并通过 PATCH /posts/5 将其提交到后端.

然后编辑器使用 Command-R(或 CTRL-R)刷新浏览器选项卡。

结果前端再请求GET /posts/5再次 - 但从 获取过时的副本之前 更改是因为距离上次 GET 还没有过去 180 秒和 GET后发出PATCH

我想要的体验是:

编辑器加载帖子页面，然后调用 GET /posts/5

CDN 将最新的副本提供给前端。

然后编辑器对帖子进行更改并通过 PATCH /posts/5 将其提交到后端。 .

在 Command-R 浏览器选项卡刷新 GET /posts/5 后带回一份数据副本，其中包含编辑器对 PATCH 所做的更改马上，不管 ttl 的 180 秒在获得新副本之前。

至于其他用户，他们完全可以在 GET /posts/5 时等待 180 秒，然后帖子中的更改才会传播给他们。

我正在使用 Axios，但我不认为 SWR 和 React-Query 支持突变。据我所知，这将允许编辑器为他只是 PATCH'ed 的对象声明一个突变。在服务器上，以便他对 GET /posts/5 进行的任何后续调用将从那里提供服务，直到可以从后端获得更新的版本。
我的问题是:

带有“突变”的 SWR 可以通过 GET /posts/5 为突变的对象提供服务吗？透明的？

突变会在浏览器选项卡硬刷新后幸存下来吗？或浏览器关闭，重新打开和后续 /GET posts/5 ?

是否有另一种模式/最佳实践来解决这个问题？

Answer 1

TL;博士 :只需在请求的末尾附加一个无害的、乱码的查询字符串 GET /posts/<id>?version=whatever
好问题。我必须承认我不知道这个问题的完整答案，但我想在前端开发人员中分享一项众所周知的技术。
该技术称为cache busting .我不确定这是否是最佳实践，但我很确定它被广泛实践，因为它很容易理解。
想法很简单。当您将更改的查询字符串添加到末尾时，您有效地更改了 URL，因此不会命中缓存，从而避免了整个缓存问题。
因此，针对您的特定用例的解决方案的详细步骤如下:

通常你只会请求 GET /posts/<id>所有用户

当用户登录时，无论什么算法都会生成一个哈希键。为简单起见，我们只使用递增整数并将其称为 version .您存储此 version在 localStorage 中，因此它可以通过页面刷新生存。

现在您需要区分用户查看自己的帖子或其他帖子的场景。当男人在看他自己的时候，你总是用 GET /posts/<id>?version=n

每当用户编辑他的帖子并点击保存按钮时，你就会撞到 version来自 n至 n+1

下次他去发布查看页面时，应用程序请求 GET /posts/<id>?version=n+1它没有被缓存，并且会检索最新的内容。

最后一件事，确保您的服务器安全地忽略 ?version=n请求参数。

我相信这个问题还有其他解决方案。我不是服务器配置和 HTTP header 方面的专家，所以我不会进入该主题，但必须要寻找一些东西。
作为纯前端解决方案，有 Serivce Worker API供您考虑。此 API 的主要目的是使开发人员能够以编程方式控制缓存策略。
使用此 API，您可以保留当前的应用程序代码，只需安装一个 Service Worker，然后您就可以在后台使用相同的缓存破坏技术来获取新内容，或者在出现以下情况时删除缓存(使用 Cache API)用户编辑，甚至伪造 GET /posts/<id> 的回复来自 PATCH /posts/<id>该用户只是发送。