FetchQL: 通过 Fetch 封装的 GraphQL 客户端查询库

[gucheen]

https://github.com/gucheen/FetchQL

最近的项目用到了 GraphQL ，为了方便在客户端操作，写了这个库，和 Apollo Server 的相关功能其实有重合。

主要功能就是对请求操作的封装。

使用一个统一的类来进行管理的话，相对逻辑会清晰很多。

其他称得上功能的就是：内建拦截器、获取 enum 类型的数据结构、更加细化的错误处理。

[winkidney]

:boom:

[nanlong]

四五个月过去了，能否介绍一下这段使用 GraphQL 的感受，是否有坑？是否更方便快捷？是否解决了以前的痛点？

[gucheen]

@nanlong
坑肯定还是有的。
定义 schema 麻烦，官方库的标准定义方法，结构复杂以及数量上来了确实是写吐，我们使用工具来通过简单的定义方法生成最终的 schema 。
js 自身数据类型太弱，比如 long 类型的数据或者 unix timestamp 处理起来就烦。
对 SOA 服务的调用参数和返回值都最好进行约束，不然就是凭空增加工作量，尤其我们 Java 和 Python 的服务同时在使用， Python 还是走的 thrift 协议。
前端使用时编写查询语句显然是比以前增加了工作量。
还有 node server 去调用其他服务时的各种问题。

方便快捷自然是要有的。
参考 github 现在开始提供 graphql 版本的 API ，使用非常灵活，前端自行获取需要的数据结构，后端也不需要关心 web api 层面的机构。
独立的 type 可以自由选择需要的 fields ，不同的 type 也可以自由组合。
另外像是 enum 和 input 也很大程度上提升了服务的健壮性。
同时由于类型系统和自省机制，配合各种工具，可以快速的查看整个 schema 定义。

关于是否解决痛点。
最大的体验就是原来占用大量开发工时的 web api 接口开发，很大一部分都可以被替代掉了，只要不是新的业务模型，很多都可以通过调整查询语句结构来完成，非常高效和方便。
接口的不确定性（不能知道接口的参数和返回值）的问题也得到了很大的缓解，最起码前端到 graphql 的通信是稳固的。
异常处理也很好用。