2

场景：

作为微前端实现并托管在 S3 上的共享组件...

  • 包含托管在 S3 上的整个应用程序（webpacked）的 JS 包
  • JS 包包含带有最新提交的哈希，例如 component.{hash}.js

问题：

当我们发布一个新包时，考虑到浏览器/CDN 缓存，确保新包在发布后被所有客户端使用的最佳策略是什么？重要提示：我们希望客户立即获得更新（内部）。

例子

  1. 在发布时，生成一个 component.html 文件，该文件根据最新的哈希值拉入包（脚本标签）。将新的 component.html 发送到 S3。客户使用<link rel-'import' href='somedomain.com/component.html'>总是给他们最新的发货版本。

问题：捆绑包仍然可以利用 CD/浏览器缓存，但无法缓存 HTML 文件，因为我们需要它在任何版本中都是热的。同样奇怪的是，我们必须进行两次下载才能获得一个捆绑包。

  1. 作为 NPM 模块交付，客户端可以在构建时使用该模块。

问题：如果我们有 10 个客户端，则所有 10 个客户端都需要构建和发布才能与新组件一起发布。假设 package.lock 不会导致通配符出现问题（不太清楚）。

注：内部组件；可能会发生频繁的变化，例如 AB 测试等。

4

1 回答 1

0

使用您的组件的页面/应用程序使用发布的任何新版本的组件进行测试和更新通常很重要。因此，您使用 NPM 的想法是一个不错的想法。通常希望有这个延迟时间，以便页面/应用程序的开发人员可以验证功能并处理可能发生的任何 API 更改（有意或其他）。

对于 NPM，语义版本控制 (SemVer)是事实上的标准。这个想法是您以这样一种方式对您的版本进行编号，以便可以在应用程序中立即更新错误修复（没有 API 更改）。 一些开发人员可以安装模块的最新补丁版本。 许多人更喜欢锁定到特定版本，并且只会在测试后像任何其他更新一样发布。

除了 NPM，我过去所做的是为库使用散列或版本化 URL。我还保留了一个latestURL，它重定向到最新版本。对于那些集成我的库而不关心他们使用什么版本的人，他们总是会以这种方式获得最新版本。此外，浏览器可以缓存重定向目标并与可能指定确切版本的其他页面共享该缓存。

重要提示：我们希望客户立即获得更新（内部）。

在所有情况下，这并不是真正可能的。在大多数情况下，使用适当的响应标头进行缓存将解决它。虽然有边缘情况。例如，如果用户加载一个页面，然后在你的 JavaScript 加载之前离线，你会怎么做？

部署新页面时总是很棘手。您的一些客户将使用旧版本，一些使用新版本。尽可能保持向后兼容性，并根据您的情况设置缓存标头。

于 2018-11-22T02:48:32.470 回答