阅读 6259

fly.js vs axios

fly vs axios

这是fly的第二篇文章,主要是将fly和axios进行一个全面的对比。

首先感谢大家支持,在fly的第一篇文章 JS HTTP 请求终极解决方案 - fly.js 发布后,github 首日破百星,如果您是新读者,在您了解了fly之后,如果您喜欢,不用找打赏入口,去github star一下就是您对作者的最大的支持。

在Angular、React、Vue这些移动端web框架大行其道的今天,很大的改变了WEB应用的开发方式。而这些框架通常都只专注于View层,而对于http请求,开发者一般都会单独引入一个http 请求库,如axios。笔者也是从使用axios过来的,但随着项目的使用,觉得 axios 不尽完美,在一些场景用起来并不舒服,所以才有了Fly。

在设计 Fly 的过程中,为了符合使用习惯,借鉴了axios(但并不完全兼容),下面将 Fly 和 axios做一个详细的对比:

共同点

  1. 都支持Promise API
  2. 都同时支持Node和Browser环境
  3. 都支持请求/响应拦截器
  4. 都支持自动转换 JSON

不同点

浏览器环境

浏览器环境下两者功能不分伯仲,最大的不同是大小,fly.min.js只有4K左右,而axios.min.js 12K左右。Fly更轻量,集成成本更低。

Node环境

Node下 Fly 的功能要明显强于axios,Fly在node下不仅提供了文件下载、上传的API,而且还可以通过 fly.$http 直接调用 request 库 的所有功能,详情请参照Node下增强的API

请求转发

Fly最大的特点就是在混合APP中支持请求转发,而axios不支持,关于请求转发的详细内容请参照请求重定向值得注意的是,作者决定写fly之前最重要的一个背景就是,在web app中,webview无法拦截ajax请求,而当时现有的js http请求库没有一个提供请求转发的功能。

Http Engine

Fly中提出了Http Engine的概念,Fly可以通过更换Http Engine的方式实现很多有趣的功能,比如全局Ajax拦截,详情请参考 全局ajax拦截

设计思想

Fly采用分层的设计思想,将上层用户接口和底层Http Engine分离。采用适配器模式,让实现Http Engine变的非常容易。正是这样的框架设计,可以通过替换底层Http Engine的方式,使得fly能够在灵活的支持各种环境的同时又能保证上层接口的一致性。还有,通过adapter,用户完全可以自定义http请求的实现.......还有很多高级的玩法。

总结

在浏览器端,fly和axios实现的功能差不多,fly以轻巧取胜;在node端,fly占有明显的优势;而在于web app中,fly 的请求转发功能是独有的。而在设计思想上,fly更是技高一筹,这使得fly能够轻松的在不同的环境下运行并可以方便的对其进行定制化。

最后贴出fly github地址,如果你喜欢,欢迎star,以使更多的人知道fly,感谢你的支持:github.com/wendux/fly

关注下面的标签,发现更多相似文章
评论