后端开发教程 - Java、Spring Boot 实战 - msg200.com
告别离线页面
将服务工作者功能减少到最低限度的离线页面 #12834
删除服务工作者 #12974
AWS 安全上线！
尊敬的 DEV 社区成员，
我想提前告诉大家，Forem 团队最近决定移除Service Worker 功能，从而移除我们的离线页面。这可不是我们轻率做出的决定。
和你们中的许多人一样，每当网络出现问题时，我们都非常喜欢使用 DEV 离线页面在浏览器中绘图。然而，最近，维护 Service Worker 的成本对我们团队来说变得异常高昂。在过去的几个月里，我们不得不接二连三地处理紧急问题，而这一切都是因为 Service Worker 的功能。
几周前，我回顾了一下情况。考虑到我们严重依赖边缘缓存，我认为移除 Service Worker 不会对性能造成太大影响，还能为 Forem 工程团队省去很多麻烦。然而，离线页面的问题仍然存在。在与@ben讨论了各种方案后，我们决定精简 Service Worker，使其唯一的功能就是服务于离线页面。
将服务工作者功能减少到最低限度的离线页面 #12834
这是什么类型的 PR？（勾选所有适用项）
- [x] 重构
- [ ] 特征
- [x] 错误修复
- [ ] 优化
- [ ] 文档更新
描述
此 PR 删除了我们一些非常酷的 ReadableStream服务工作者功能，因为它导致了与新代码部署相关的太多错误。
此功能的优点是初始页面加载非常快速，但当前实现的缺点是部署缓存问题难以预测，且实例过多。处理这些问题一直都很棘手，尤其是在 Forem 环境下，我们的 DevOps 无法像单次部署那样快速修复生产环境中的问题，因此处理起来尤为困难。
我们当前实施的根本问题在于，它在处理某些场景方面并不详尽，而处理边缘情况会产生很大的复杂性。
我们认为处理基本的离线功能仍然具有 UX 优势和 SEO 优势……
我们仍然拥有服务工作者生命周期，在此基础上，我们也许能够有条不紊地添加此 PR 删除的某些功能，但我们可以更加注重确保考虑到所有可能的情况，这样我们就不会让用户陷入错误的情况。
我所做的另一项调整就是删除离线页面上图像的“DEV”部分（并清理那里的一些代码）...我们可能希望为 Forem 管理员提供一种新的有趣方式来定制此页面，但我认为进行这项小调整以制作更简约、更通用的离线页面在这里是有意义的。
跟进
使用这种新方法可以删除一些额外的代码，但由于服务工作者运行已下载到用户浏览器的代码的性质（即首先造成这种复杂性的原因），最好等待至少几周再删除一些不再需要的其他代码，以免破坏旧的安装。
相关票据及文件
https://github.com/forem/internalEngineering/issues/333
质量保证说明、屏幕截图、录音
这主要是采用此功能：https://web.dev/offline-fallback-page/
观察功能并测试不同的网络条件以确保不会导致新的问题。
用户界面可访问性问题？
这不应该导致新的 a11y 问题。
添加了测试？
- [ ] 是的
- [x] 不，原因如下：我不太确定如何测试这个。
- [ ] 我需要编写测试方面的帮助
[仅限 Forem 核心团队] 如何传达这一变化？
此 PR 是否会引入影响 Forem 成员或创建者、开发流程或我们任何内部团队的变更？如果是，请说明您将如何与需要了解此变更的人员分享。
- [x] 我已经更新了[开发者文档]
[可选] 哪个 gif 最能描述此 PR 或者它给您带来什么感受？
我们部署完毕并高兴地认为我们的困境已经结束。
我们错了
这次部署几天后，我们的紧急 Slack 频道再次爆满，用户表示无法从 Safari 登录。我们整理了一个修复程序（之后又发布了一个后续修复程序🙈），并发布了修复程序。几天后，紧急频道再次爆满，用户报告了大量登录问题。我们再次发布了修复程序。问题发生三天后，我决定咨询我的工程主管，了解他们对整个情况的看法。
大家对 Service Worker 持续存在的问题有什么看法？Ben 已经将其功能大幅精简，只剩下离线页面，因为它带来的各种问题以及对开发者时间的巨大浪费，但感觉情况并没有好转多少。我实在受不了几天再回到 Slack，#emergency 亮起来，回复量也只有 100 条。
一旦我们识别出所有异常路径，我们是否认为情况会好转？还是我们仍然认为它会像地雷一样继续困扰我们？离线页面功能的成本越来越高，我想知道它是否值得。
我的优秀团队和@ben都表达了他们的想法。
但还有一个问题：我们的离线页面本应有助于提升 SEO 排名！然而，我们并不确定它到底能起到多大作用。最终，我们权衡了所有方案，最终决定最好的方案是彻底移除 Service Worker，并使用 Google Search Console 监控我们的流量。
工程决策的制定总是需要权衡利弊。在本例中，Service Worker 功能对我们的用户和开发者都造成了干扰，这似乎抵消了它带来的所有好处。虽然移除离线页面有点令人失望，但从长远来看，这将使 Forem 平台在未来更加可靠和稳定。
有关更多详细信息，请查看下面的删除 PR。👇
删除服务工作者 #12974
这是什么类型的 PR？（勾选所有适用项）
- [ ] 重构
- [ ] 特征
- [x] 错误修复
- [ ] 优化
- [ ] 文档更新
描述
这将移除我们所有的 Service Worker 功能，并使用一个自毁 Service Worker，这似乎是注销 Service Worker 的最佳方法。请参阅https://github.com/NekR/self-destroying-sw#how-to-use。
相关票据及文件
质量保证说明、屏幕截图、录音
在 Chrome、Firefox 和 Safari 中测试。注意，在 Safari 中，由于 service-companion.js 文件的操作，可能没有注册 Service Worker。在这种情况下，请确保 Safari 的 Web 开发工具控制台中没有抛出任何错误。
- 从主分支拉取最新版本，并在本地部署站点。导航到主页，打开开发者工具，然后导航到开发者工具页面，验证 Service Worker 是否正在运行。
铬合金
火狐
Safari
- 拉取此 PR 的分支并将其部署到本地。刷新当前打开的浏览器窗口，验证 Service Worker 是否已注销。
铬合金
火狐
Safari
用户界面可访问性问题？
N/A 这是前端基础设施
添加了测试？
- [ ] 是的
- [x] 不，原因如下：我已经删除了与服务工作者相关的测试，因此现有的测试应该继续通过。
- [ ] 我需要编写测试方面的帮助
[仅限 Forem 核心团队] 如何传达这一变化？
此 PR 是否会引入影响 Forem 成员或创建者、开发流程或我们任何内部团队的变更？如果是，请说明您将如何与需要了解此变更的人员分享。
- [ ] 我已经更新了开发者文档和/或管理指南，或Storybook（针对 Crayons 组件）
- [ ] 我已更新 README 或添加内联文档
- [x] 我将在变更日志或forem.dev帖子中分享此更改
- [ ] 我会与相关团队内部分享这一变化
- [ ] 我不确定如何最好地传达这一变化，需要帮助
- [ ] 此更改无需传达，原因如下：请将此行替换为有关此更改无需共享的详细信息
[可选]我们需要执行任何部署后任务吗？
[可选] 哪个 gif 最能描述此 PR 或者它给您带来什么感受？
</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/forem/forem/pull/12974">View on GitHub</a></div>