转淘宝前端的一篇文章作备份

当前端也拥有 server 的能力

作者: 阎王 发表于: 2016-03-09

今天看了不少文章,比较感兴趣的是 Cache API。它是浏览器 Request/Response 的缓存管理工具,其使用风格和运用场景让我瞬间联想到了 ServiceWorker 和 Fetch API,相信很多同学也多次看到过这两个东西,本文会对它们做一个简洁的介绍,并谈一谈我对这些新玩具的看法。

Fetch API

传统的 XMLHttpRequest,出了两个版本,在 XHR2.0 中引入了跨源请求、上传进度事件和对二进制数据的支持等,这些 API 的增强让 AJAX 可以很方便地与 HTML5 API 相结合,例如 File System API、Web Audio API、WebGL 等,让前端对音视频的处理和富客户端元素的处理更加有亲和力。

作为一个与后端交互的通道,XHR2.0 的接口封装依然过于底层。看看 jQuery 对 AJAX 的封装,再回头看看我们今天要介绍的 Fetch API,不得不惊叹,浏览器已经在应用层面思考着功能的拓展,依托着 Promise 产出了十分友好的新一套接口。

以前我们使用 XHR 去请求一个资源,会这么做:

 
// Just getting XHR is a mess!if (window.XMLHttpRequest) {  request = new XMLHttpRequest();} else if (window.ActiveXObject) {  try {    request = new ActiveXObject(‘Msxml2.XMLHTTP‘);  }   catch (e) {    try {      request = new ActiveXObject(‘Microsoft.XMLHTTP‘);    }     catch (e) {}  }}request.onreadstatechange = function(){  // handle data;};request.open(‘GET‘, ‘http://example.com/test.json‘, true);request.send(null);

而使用 Fetch API,我们只需要:

 
fetch(‘http://example.com/test.json‘).then(function(response) {   // Convert to JSON  return response.json();}).then(function(val) {  console.log(val); });

对于 Text/HTML 和 Blob 等格式的请求和转化也是异常方便:

 
// Text/HTML 请求fetch(‘/next/page‘).then(function(response) {    return response.text();}).then(function(text) {  console.log(text); });

// Blob 流fetch(‘flowers.jpg‘).then(function(response) {  return response.blob();}).then(function(blob) {  document.querySelector(‘img‘).src = URL.createObjectURL(blob);});

Fetch API 让我们更加关注请求和响应之间的交互,而不是聚焦在如何请求和如何处理响应两个问题上。

当然,它也存在几个相比 XHR 不足的地方,首先它不能 abort 请求,同时也不能获取请求过程中的 progress 状态,当然也没有 timeout 超时处理。Fetch API 是基于 Promise 的,而 Promise 的状态只有 pending、resolve、reject,不会出现诸如 pending(80%) 的状态提示;我们也无法对一个 Promise chains 做 abort 处理,这些都是能够理解并且接受的。

我也相信,Fetch API 有能力提供这些状态信息和附加的 API,只是在这个不成熟的环境下,它目前不需要迈这么大的步子。

ServiceWorker

ServiceWorker,简单而言就是一个放在前端的 HTTP 拦截器,比如我们要请求一个不存在的 URI 如:/test/a.html,直接请求就会响应 404,而如果我们预先在 ServiceWorker 中注册了这个地址,并且指定响应内容,当再次请求时,你会看到结果是存在的,举个例子:

 
<!-- demo.html --><script>navigator.serviceWorker.register("worker.js", {  scope: "/test/a.html"}).then(function(){  fetch(‘/test/a.html’).then(function(response) {    return response.text();  }).then(function(text) {    console.log(text);   });});</script>

在 demo.html 文件中,我们看到,将 /test/a.html 的请求交给 worker.js 来处理,处理方式为:

 
// workker.jsaddEventListener("fetch", function(evt) {  evt.respondWith(new Response(‘Hi, 阎王‘));});

在 demo.html 的回调中使用 Fetch 获取/test/a.html 这个并不存在的内容,被 ServiceWorker 捕获,交给 worker.js 处理并响应 Hi, yan wang 的文本,整个设计思路十分清晰,很轻松地拦截了来自客户端的请求,并作出了响应。

由于 ServiceWorker 是对 Promise 友好的,响应时也可以模拟服务器休眠状态:

 
addEventListener("fetch", function(evt) {  evt.respondWith(new Promise(function(resolve, reject){    setTimeout(function(){      resolve(new Response(‘Hi, 阎王‘));    }, 1000);  }));});

由于 Fetch API 提供了对 Header 头的修改,我们几乎可以利用 ServiceWorker 实现真实 HTTP Server 的基本功能。

ServiceWorker 一定程度上改变了 Web 协作的交互模式,传统情况下,我们需要开启一个 Web Server,或者让其他人提供 HTTP Server,前后端之间交互,沟通成本比较高。而 ServiceWorker 把 HTTP Server 搬到了客户端,我们可以在浏览器上轻松 Hold 住两端的操作。这也算是 Web 技术栈融合的表现吧。

当我们的目光放在 HTTP 的交互上,ServiceWorker 会有无限的想象空间,比如对 History API 的延伸思考,跨页面共享问题,前端请求合并和分拆问题,mock 数据问题,前后端的联调问题,类 graphQL 问题,数据的缓存更新和复用问题等等。

Cache API

Cache API,简而言之就是一个 Request/Response 的缓存对象组,它的生命周期跟 ServiceWorker 是紧密相连的,它没有失效时间,不删除就会一直保持原样。

 
caches.open(‘test-cache‘).then(function(cache) {  cache.add(‘/index.html‘);});

一个简单的操作,就将 /index.html 这个页面缓存了下来,如果你使用的是最新版的 Chrome,可以打开 DevTools > Resources > Cache Storage,多了一个 test-cache 的缓存表,表中多出一项,Request 为 http://example.com/index.html, Response 为 OK。如下方式可以查看缓存内容:

 
caches.open(‘test-cache‘).then(function(cache) {   cache.keys().then(function(cachedRequests) {     console.log(cachedRequests);  });});

当浏览器处于 idle(空闲) 状态的时候,会将 Cache 资源预加载到本地。这也让我想起了 link 标签中有一个 prefetch 功能,也会有同学想到 Manifest,不过这两个东西都是不能友好控制的,而 Cache 给我们带来了这样的便利。

小结

我一直相当看好 Fetch API 系列相关的新接口,它的特点也很清晰,首先是基于 Promise 的实现,这个实现解决了回调和状态控制的问题,然后是提供了应用级别的接口访问,现在可以把一个 HTTP 请求作为可控的对象随意操作,无论是 Request 还是 Response 都在我们的掌握之中,同时也一定程度解决了跨页面资源共享的问题(至于跨页面通讯,我们有 postMessage 和 MessageChannel 等工具)。

目前浏览器对 Fetch API 和 ServiceWorker 的支持都是比较可观的,虽然 W3C 上的文档状态还是 Draft 模式,相信随着我们对业务需求的更加明确,对前端认知的的不断深入,这些东西将很快被定为 RFC。

本文没有对 API 的使用做深入的说明,一方面是因为这些东西能在 Google 上找到,其次,我觉得有些 API 的设计上还不够成熟,今后会有增删,感兴趣的同学可以去 W3C 提供的文档中深入学习下。

拓展阅读

原文地址:https://www.cnblogs.com/ww01/p/9594629.html

时间: 2024-10-13 16:22:43

转淘宝前端的一篇文章作备份的相关文章

我的阿里梦——淘宝前端必备技能

每天下班路过阿里,看到里面的灯火嘹亮,心里惴惴不安,我也想进阿里,怎么破. 阿里的前端是不是都是大牛?我给他们的差距到底有多大,这个问题困扰我很久,然而,百无聊赖的我习惯性的打开淘宝官网,然后习惯性的f12,我发现了新大陆…… 我仔细看看,很迷茫,看懂的不多,不过,我决定,慢慢来,先搞懂他们都是干啥的,然后晚点偷偷的学. 下面,让小屌丝给你们整理下他们都是干啥用的吧. 1: Angula AngularJS诞生于Google是一款优秀的前端JS框架,已经被用于Google的多款产品当中.Angu

淘宝前端工程师推荐书笔籍大集合

写了几年的不正规前端,从乱的不可开交的css/html/js,到发现需要看书才能解决问题的状态.这里推荐一下 淘宝前端书籍:http://www.xiaomengku.com/index.php/album?id=6 多看书还是可以很好的理顺自己的思维,写了个小js库(HHJsLib)还在不断完善中,此库指在简化后端的开发任务,从减少后端人员对于前端效果纠结时间,来达到加快网站开发速度的目的.有兴趣的同学可以上GitHub交流下:https://github.com/HongJuZiNetStu

淘宝前端工程师:国内WEB前端开发十日谈

转自:http://www.jianshu.com/p/8cf2df3fdbf2 一直想写这篇“十日谈”,聊聊我对Web前端开发的体会,顺便解答下周围不少人的困惑和迷惘.我不打算聊太多技术,我想,通过技术的历练,得到的反思应当更重要. 我一直认为自己是“初级”前端开发工程师,一方面我入道尚浅,只有短短几年,另一方面我自知对技术的钻研并不深入,可能是由于环境的原因,当然最重要的是,我幸运的参与到互联网崛起的浪潮之巅.时势造就了一批技能薄弱但备受追捧的“弄潮者”,这在很大程度上影响我们对“技术本质”

转载:淘宝前端团队的干货《论版本号的正确打开方式》

引用原文评论的一句话:条理清晰, 如此甚叼! 论版本号的正确打开方式 作者: 法海 发表于: 2016-08-04 版本号广泛运用于开发的各种场景:NPM 包的版本定义.对 NPM 包的特定版本的依赖指定.git 的 daily 版本号分支…… 面对如此多的场景,版本号的命名却存在很大问题.举些例子: 开始写一个新项目 / 模块时,不管三七二十一,都从 0.0.1 起版本,直到项目不再维护时,版本还停留在 0.0.48,前两位永远都是 0. API 变化巨大,而版本号雷打不动一步一个脚印.一个二

技术普及帖:你刚才在淘宝上买了一件东西

你发现快要过年了,于是想给你的女朋友买一件毛衣,你打开了www.taobao.com.这时你的浏览器首先查询DNS服务器,将www.taobao.com转换成ip地址.不过首先你会发现,你在不同的地区或者不同的网络(电信.联通.移动)的情况下,转换后的IP地址很可能是 不一样的,这首先涉及到负载均衡的第一步,通过DNS解析域名时将你的访问分配到不同的入口,同时尽可能保证你所访问的入口是所有入口中可能较快的一个 (这和后文的CDN不一样). 你通过这个入口成功的访问了www.taobao.com的

你刚才在淘宝上买了一件东西【技术普及贴】

原文链接:http://blog.renren.com/share/1008228562/11138179294 你发现快要过年了,于是想给你的女朋友买一件毛衣,你打开了www.taobao.com.这时你的浏览器首先查询DNS服务器,将www.taobao.com转换成ip地址.不过首先你会发现,你在不同的地区或者不同的网络(电信.联通.移动)的情况下,转换后的ip地址很可能是不一样的,这首先涉及到负载均衡的第一步,通过DNS解析域名时将你的访问分配到不同的入口,同时尽可能保证你所访问的入口是

揭秘淘宝286亿海量图片存储与处理架构

8月27日下午,在IT168系统架构师大会存储与系统架构分论坛上,淘宝网技术委员会主席,淘宝网核心工程师章文嵩向我们详细介绍了淘宝网图片处理与存储系统的架构.章文嵩博士的演讲日程包括了淘宝的整个系统架构.淘宝图片存储系统架构,淘宝网独立开发的TFS集群文件系统,前端CDN系统以及淘宝网在节能服务器方面的应用和探索. 本文侧重介绍淘宝网后台的图片存储系统架构.包括TFS集群文件系统,以及前端处理服务器架构. 解决海量并发小文件的系统噩梦 对于淘宝网这类型访问量极高的电子交易网站来说,对图片系统的要

[转载]你刚才在淘宝上买了一件东西

你发现快要过年了,于是想给你的女朋友买一件毛衣,你打开了www.taobao.com.这时你的浏览器首先查询DNS服务器,将www.taobao.com转换成ip地址.不过首先你会发现,你在不同的地区或者不同的网络(电信.联通.移动)的情况下,转换后的ip地址很可能是不一样的,这首先涉及到负载均衡的第一步,通过DNS解析域名时将你的访问分配到不同的入口,同时尽可能保证你所访问的入口是所有入口中可能较快的一个(这和后文的CDN不一样). 你通过这个入口成功的访问了www.taobao.com的实际

你刚才在淘宝上买了一件东西

摘自网络,忘了原博主了,sorry ? ? 你打开了www.taobao.com.这时你的浏览器首先查询DNS服务器,将www.taobao.com转换成ip地址. ? ? 不过首先你会发现,你在不同的地区或者不同的网络(电信.联通.移动)的情况下,转换后的IP地址很可能是 不一样的,这首先涉及到负载均衡的第一步, ? ? 通过DNS解析域名时将你的访问分配到不同的入口,同时尽可能保证你所访问的入口是所有入口中可能较快的一个 (这和后文的CDN不一样). ? 你通过这个入口成功的访问了www.t