GraphQL

最近有个DASHBOARD的任务，把测试结果汇总到dashboard中显示。项目中有用到GraphQL，第一次接触。玩了几天，总算deliver了一个story。:)

http://graphql.cn/

GraphQL是由Facebook开发和开源，本质上是一种基于api的查询语言。给人的感觉就是在数据层和业务层封装了一层数据处理（ETL中的T或适配器）。

当提起API设计的时候，大家通常会想到SOAP，REST等设计方式，目前市场上应用挺火的就是REST，那个有REST，为啥又会有它？或者它存在意义是什么？应用场景主要在以下方面：

1.移动端用户的爆发式增长需要更高效的数据加载

Facebook开发GraphQL的最初原因是移动用户的增加、低功耗设备和松散的网络。GraphQL最小化了需要网络传输的数据量，从而极大地改善了在这些条件下运行的应用程序。

2.各种不同的前端框架和平台

前端框架和平台运行客户端应用程序的异构环境使得我们在构建和维护一个符合所有需求的API变得困难，使用GraphQL每个客户机都可以精确地访问它需要的数据。

3.在不同前端框架，不同平台下想要加快产品快速开发变的越来越难

快速的迭代和频繁的产品更新是必不可少的。对于REST来说，服务器公开数据的方式常常需要修改，以满足客户端的特定需求和设计更改。这阻碍了快速开发实践和产品迭代。

上面说的有点冠冕堂皇，举个栗子。拿手机端举例，一般都会有这么一个模块-个人中心。它包含了个人基本信息和使用app相关的会员信息。如果使用rest api的方式，我们可能需要getUser(Integer userId), getUserDetail(User user),getUserOrders(User user)等这样的api，查询数据库的次数比较频繁，砖石会员数据量大，很容易导致页面加载数据缓慢，体验不好。而相对来说GraphQL只需要下一次查询，就会将相关的信息返回给你，返回的数据格式可以定制。有这种优势的话，前端mock数据也是很方便。而且当后端业务调整，对前端几乎没影响，GraphQL已经帮你隔离了。读到这，也许你已经发现他的瓶颈在哪？没错，性能。它的处理是无法绕开大sql查询，需要持续的优化！优化！

下面我们再来看看友好的地方：

1.强大的开发者工具

这个开发工具是可以在本地run起来的。最左边history可以看到历史使用到的查询方法，最右边是目前已经定义好的query，可以根据它来定制查询需要返回的数据（可以把对象，以及对象相关的属性一层层的拼接）。

2.脱离存储引擎的限制

GraphQL 引擎已经有多种语言实现，通过 GraphQL API 能够更好利用你的现有数据和代码。你只需要为类型系统的字段编写函数，GraphQL 就能通过优化并发的方式来调用它们。

至于怎么写代码，可以参考官网的例子：http://graphql.cn/code/#graphql-clients

最后秀一下我的成果:)