同窗，GraphQL了解一下：基础篇

实践篇：GraphQL了解一下：实践篇
进阶篇：GraphQL进阶篇: 挥手Redux不是梦

简介

GraphQL由Facebook发起，其手机客户端自2012年起，就全面采用了GraphQL查询语言， 2015年， Facebook全面开源了第一份GraphQL规范。到目前为止，在Twitter，Github，Pinterest，Shopify等大型网站也获得了普遍的实践。语言也从最初的js，扩展到java ,python，Go。且Apollo-client也逐渐作全了graphql生态。
GraphQL是一种用于 API 的查询语言（规范），是一种协议而非存储。GraphQL对你的API中的数据提供了一套易于理解的完整描述，使得客户端可以准确地得到它须要的数据，并且没有任何冗余；
若是想在读下面的知识以前，对GraphQL先有一个粗狂的认识，能够登陆GitHub GraphQL API 站点，体会一下其使用，可点击右侧的Doc文档查看接口定义。

GraphQL出现的意义

上面是一张咱们经常使用的Restful接口交互和引入GraphQL接口中间层的接口交互对比图，在此以前，咱们先了解一下当前咱们所使用的Restful接口的痛点：

1. 冗余字段大量返回;
2. 渲染一个复杂的页面须要发起多个请求;
3. API定义文档更新不及时；

相信上面的三点，在前端淌过水的你，必定是会有体会的。一个接口，同时用于h5页面和web页面的渲染源数据，但可能H5页面只须要这些数据源的1/10,冗余数据的返回浪费了流量，消耗了时间；因为如今后端更推崇microservice,提供聚合服务的API被认为没有技术含量，因此咱们有时渲染一个关系复杂的页面，须要请求5,6次，才能完整的渲染出一个页面，这期间咱们还得去容错，避免因其中某一个请求的失败致使页面没法渲染的问题；API文档更新不及时，相信这是最多见的吐槽，好好的静态页面写完，并本身照着API文档作完mock，等联调时，接口返回的字段彻底不按API定义来，奔溃。

上图摘自GraphQL官网，其用简单的三句话：描述你的数据（服务端），请求你所要的数据（客户端），获得可预测的结果。其隐藏的意思就是：

1. 服务端（或则中间层）须要描述全部可能的类型系统（Schema），有必定工做量；
2. 按你所需请求你须要的数据，这就解决了不一样客户端，不一样的渲染需求，都请求回一样的数据源的痛点；
3. 获取多个资源只用一个请求，除了你能够描述你某个请求须要返回那些字段，你还能够定义这个请求须要返回那些数据。对应浏览器来说，只发送了一个请求，GraphQL服务端会根据请求定义将这些请求拆分，并最后再将数据拼装返回回来；

听起来是否是特别爽，那实现起来呢？

零碎的GraphQL语法

基础语法

其实GraphQL所须要学习的语法不多，大部分语法与咱们平时的语法一致，能够经过官网详细了解。首先，GraphQL是一门强类型语言，因此和咱们在数据库定义一张表同样，咱们须要定义每个属性的类型.以下图所示：

enum Episode {
      NEWHOPE
      EMPIRE
      JEDI
    }
    type Person{
         id: ID! 
         name: String!
         friends: [Person]
         appearsIn: [Episode]! 
    }

上面是一个简单的类型定义，先是定义了一个枚举，而后咱们定义了一个类型，类型中有四个属性：id、 name、 friends、 appearsIn,其中id和name是标量类型，而friends是一个Person类型，这是一个嵌套类型，仔细想一想应该没什么毛病，毕竟你的朋友和你同样，都是人；而appearsIn是一个枚举类型，看起来仍是很熟悉的；
了解完类型，再了解一下Arguments和resolver,二者都是偏服务端一些，可是了解一下，对graphql的使用原理有进一步的认识；
对于一个Restful API来说，除了知道接口URL，咱们还须要知道接口的传参定义，对于GraphQL其实也同样，虽然URL只有一个，不一样的接口经过type来区别，但传参同Restful API同样，体现了客户端与服务端的交互。好比下面，查询的目标是id = 2的用户，获取他的用户名：

Query{
        user(id: 2) {
            id
            userName
        }
    }

而在服务端定义一个接口时，咱们也须要去定义入参，主要从两个方面，一是类型，二是其是否必填，好比下面这样：
接口定义

user: {
    type: UserType,
    args: {
      id: { type: GraphQLID }
    },
    resolve: (root, args, context, info) => {
      const { id } = args;
      return getUser(id);
    }
  }

查询定义

上面的代码只是定义了一个输入属性id,并未定义其是不是必填，因此当查询时，若是没有配置查询id，查询不会报错，只会获取一个为null的空值结果。可是讲道理的话，咱们但愿这是一个必填项，因此咱们须要修改服务端的代码,将id: { type: GraphQLID } 更换为id: {type: new GraphQLNonNull(GraphQLID)}，这句代码的含义就表示id是一个类型为ID的必填项，再次执行咱们的查询能够获得下面的错误提示，提示id是一个必填的ID类型，同时右侧也没有获取到为空的查询结果；

在讲上面Arguments时候，能够零星的看到type中有一个resolve方法，其接收root, args, context, info四个参数。其中root表明这个type上父节点的resolve值（由于GraphQL支持嵌套查询），args就是上面讲的，context表在Resolver解析链中不断传递的中间变量,和react的上下文类似，而info这个概念，是当前Query的AST对象，比较抽象，可是能够经过查看info,获取这个QUERY的编译对象。这个方法也是后端服务编写的重点部分，经常咱们能够在这里与已有的Restful API关联起来。

核心概念

Schema能够说是GraphQL最具核心的部分，其描述了整个接口向外暴露的形式；像Restful API，咱们会定义一个查询全部人的接口url定义为：/api/v1/user/getUsers，而查询人具体信息的接口url为：/api/v1/user/getUserById,而新增一我的员的接口url定义为：/api/v1/user/createUser，前端人员调用起来很直观。可是graphql是彻底不同的使用方式，其向前端暴露的url就一个像/api/graphql之类的，那这么多接口怎么区分呢？

奥妙就是上面这张图，一个graphql接口都有一个Schema定义，其定义三种操做方式：query（查询）,mutation（变动）和subscription（监听）。再往下延伸，一个查询中包含多个field，也就是多种不一样的查询，好比query user查询人，query message查询消息，query weather查询天气，经过这些就实现了Restful API使用多个url来达到不一样操做的效果。看下面一张图（使用最原生的graphql语言编写，有助于理解）：

总结

这是一篇本身学习GraphQL期间，概括总结到的信息，本身感受是同如今的开发方式相比，须要在前端与Restful API之间增长一层GraphQL中间层，这确实增长了工做量，但看上面提到的语法，其编程仍是很是直观易懂的，在业务不是那么繁重的时候，仍是值得推广的。在下一篇将会讲到：实现一个GraphQL Server与在React应用中引入GraphQL。