这是我在 Mozilla Hacks 上发表的第一篇帖子，尽管我拥有个人博客，但这是我作为 Mozilla 成员发表的第一篇帖子（耶！）。这个月我一直在参与 Service Worker Cookbook 项目——这是 网页应用开发者计划 (WADI) 的一部分——这让我有机会将我在 Service Workers 方面的专业知识付诸实践，同时学习如何利用这项令人兴奋的网页技术来造福网页。让我与大家分享一些我的最新想法。

本系列之前的文章由我的同事 David Walsh 撰写，讨论了 应用缓存 以及它缺乏灵活性，因此我不会进一步深入探讨这个主题。但是，我会关注 Service Worker Cookbook 中的更多食谱。David 介绍了它并讨论了一些 离线食谱；我想更进一步，看看 Service Workers 的其他一些用途。

今天的 Service Workers

尽管 Service Workers 已经开发了一段时间，但我们现在才开始听说 Service Workers 被实际使用。回顾一下，这个 API 最初的目的是纠正应用缓存的错误。一些网络考古 揭示了最初的意图就是修复离线缓存，让网页开发者能够 以一种合理且分层的方式构建 URL 友好、默认离线的应用。

最初的方法引入了通过一个概念来控制导航，这个概念演变成 Service Worker 的 fetch 功能事件：一种拦截网络请求并使用从网络、数据库或程序生成的获取数据的方式来响应。最好的部分？受控的页面不必知道它们实际上是被劫持的（虽然可以告知它们），因此服务逻辑完全与应用程序逻辑解耦。一个完美的“中间人”。

但是作为黑客（毕竟这是 Hacks 博客！），我们喜欢做的是为相关问题精心设计解决方案，而“精心设计”通常意味着滥用某事物的真实意图。在 Mozilla，从我们的 WADI 和 Firefox OS 计划中，我们正在探索以下 Service Workers 的非标用途。

API 分析

让我们从一个中间人的直接应用开始：API 分析。假设您想要获取有关 API 使用情况的统计数据，但没有服务器访问权限。当前的解决方案操作客户端代码，生成 HTTP 请求，并将相应的日志发送到分析服务。一个 Service Worker 可以做得更好，它会拦截每个请求，提取它的参数，发送日志进行分析，并将原始请求发送到网络。

安装打包应用

在探索其他奇特的用途之前，这里有一个更传统的用途——一个 Service Worker 可以通过安装打包应用来离线资源。可以下载一个单独的 zip 包，并在启用 Service Worker 时解压它。这减少了每个 HTTP 请求带来的开销，并且使下载资源成为一个原子操作。对大型静态资源（如字体或图像）进行智能自动缓存是另一个将资源离线的好例子。

模拟服务器

回顾中间人方法，通过充当代理，一个 Service Worker 可以模拟一个服务器并实现客户端期望通过网络访问的 API。ServiceWorkerWare 是在 Firefox OS 中开发的，是一个用于支持 新 Gaia 架构 的库，它允许开发者以声明式的方式编写 Service Workers，遵循流行的 Node.js Express 库的理念，但在客户端实现。

实现现代框架功能

Service Workers 在现代框架的构建模块中也有自己的位置。以模板插值为例。许多当前流行的网页应用框架，如 backbone.js 和 Angular，通过将它们的属性插值到模板中来渲染模型。我们之前提到的新 Gaia 架构引入了渲染存储的概念，这是一个离线缓存，用于存储将模板与数据模型插值后的结果，这样当客户端第二次请求同一个模型时，就可以从渲染存储中检索它，从而避免 插值延迟。

依赖注入

现代框架中的另一个流行概念是依赖注入，它指出依赖代码不需要知道它的依赖是如何构建的。它只知道抽象接口，而具体的实现由一个称为注入器的抽象工厂提供。一个 Service Worker 可以充当依赖注入器。一个框架可以使其组件通过脚本标签声明 API 依赖项，然后 Service Worker 充当注入器，识别对抽象资源的请求并使用实际模块进行响应。

延迟请求

如果设备没有连接，但应用继续接受操作，客户端应用和云端的服务最终将不同步。框架的一个有趣功能可以是提供一个请求延迟器。例如，在离线状态下，一个 Service Worker 可以保留对 API 的请求，并在连接恢复时释放它们。在此期间，Service Worker 可以通过使用通用的 OK (状态码 200) 或 ACCEPTED (状态码 202) 响应客户端操作来模拟服务器。一旦连接恢复，Service Worker 可以通过从延迟请求队列中重新创建对网络的请求来与云同步。

网络逻辑思路

最后，Service Worker 还可以在网络逻辑中使用，也许将一个请求复用到多个源，测量每个源的可用性和质量，并通过正确的通道返回数据。在结束之前，我举一个小例子。假设我们有一个在线视频应用。用户想要观看一部高清电影，因此应用请求电影 URL，但在开始提供内容之前，Service Worker 会拦截请求，询问服务器的负载级别，选择负载最低的服务器，并开始从该特定服务器提供内容。听起来熟悉吗？没错，这是一个负载均衡器，但现在可以在客户端实现！很棒，不是吗？

总结

现在就到这里了，朋友们！七种用途，七种奇特的食谱，不仅仅是缓存内容以供离线使用。目前，Service Worker Cookbook 项目展示了所有这些方法（以及其他方法）来利用 Service Workers API 提供的功能。我们不会止步于此——还有很多东西需要探索；Push API 将继续存在，Background Sync 即将推出，流式 HTTP 响应和可取消的请求也即将到来。谁知道未来会有什么机遇呢？

有关 Service Workers 和其他平台实现状态的更多信息，请查看 Platatus，我们会让您了解最新信息！