浅谈GraphQL

GraphQL 是一种用于 API 的查询语言也是一个满足你数据查询的运行时。 GraphQL 对你的 API 中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余.
GraphQL服务搭建
首先需要运行一个Express GraphQL服务器，express-graphql模块提供了一个创建Express服务的简单方法来运行GraphQL API，graphql模块创建GraphQL的类型系统和服务 graphQL服务。
1.创建工程，
2.初始化项目，
3.安装依赖包
npm init -f
npm install graphql express express-graphql --save
npm isntall babel-cli babel-preset-es2015 --save-dev
npm install -g nodemon

• 编写 GraphQL Schema，Schema是Graph请求的入口，用户的请求也将对应到具体的Schema

• 创建 server.js，链接 schema

• 在浏览器运行可以看到查询界面，输入 Schema里定义的数据就可以查询

  GraphQL 语法特性和使用方式

支持多操作：query->查询，mutation->修改，规范是写在查询语句前，默认不写就是query

支持参数，实现各种功能，比如：查询数据，排序，分页，… …等

语法其他特性，别名，片段，定义变量，指令，… …等

 // 查询语句-有参数
query{
  posts(index:1){
    _id,
    title,
    content
  }
}
// 返回结果
{
  "data": {
    "posts": [
      {
        "_id":"03390abb55...",
        "title": "New Feature: ...",
        "content": "I'm content."
      }
    ]
  }
}
// 修改语句
mutation create{
  createAddress(
    Id:100,
    Code:"234234",
    Name:"我的城市",
    FirstStr:"A"){
    Id,
    Code,
    Name
  }
}
// 返回结果
{
  "data": {
    "createAddress": {
      "Id": 100,
      "Code": "234234",
      "Name": "我的城市"
    }
  }
}

GraphQL核心概念
模式（Schema）
GraphQL 有自己的语言类型，用于编写模式。 这是一种人类可读的模式语法，称为规范与描述语言（SDL）
类型（Type）
类型是 GraphQL 最重要的特性之一。
类型是表示 API 外观的自定义对象。比如：GraphQLList,
GraphQLObjectType,
GraphQLSchema,
GraphQLString,
GraphQLInt,
GraphQLFloat,
GraphQLEnumType,
GraphQLNonNull

query (查询)为了简单地解释这一点，GraphQL 中的查询是获取数据的方式。可以获得想要的数据。
mutation (更改)在 GraphQL 中，更改是修改服务器上的数据并获取更新数据的方式，就像REST 的 CUD
subscription (订阅)订阅是让客户端与服务器保持实时连接的方式。这意味着无论何时在服务器中发生事件，并且每当调用该事件时，服务器都会将相应的数据发送到客户端。

强类型：GraphQL与 C 和 Java 等后端语言相得益彰，服务端能对响应的形状和性质做出一定保证，而RESTful是弱类型的，缺少机器可读的元数据；
分工：GraphQL让服务端定义好支持哪些Queries，把对数据的Query需求下放到客户端管理，分工明确的同时保持对 API 的聚焦；
分层：GraphQL的Query本身是一组分层的字段，查询就像返回的数据一样，是一种产品(工程师)描述数据和需求的自然方式；(PS：部分翻译的，国外好像都把产品叫做 Product Engineers 而不是 Product Manager。感觉在吐槽的样子)
预测性：GraphQL的Query只返回客户端要求的内容，没有任何冗余(不浪费流量)，而且它只有一个接口地址，由此衍生了另一个特性；
兼容性：需求变动带来的新增字段不影响老客户端，服务端再也不需要版本号了，极大简化了兼容问题；(App 通常是 1-2 周的固定周期发版，在原生应用不强制升级的世界里，会出现用户 1-2 年都不升级的情况。 这意味可能同时有 52 个版本的客户端查询我们的服务端，而在 Fackbook 中 GraphQL API 曾支持了横跨 3 年的移动端)
自检性：GraphQL能在执行Query之前(即在开发时)提供描述性错误消息，在给定查询的情况下，工具可以确保其句法是正确有效的，这使得构建高质量的客户端变得更加容易；
Doc & Mock：GraphQL的文档永远和代码同步，开发无需维护散落多处的文档，调用者也无需担心过期问题，而且基于类型系统的强力支撑和 graphql-tools，mocking 会变得无比容易。
GraphQL通过它的特性解决了不少问题，当然它不是没缺点的.

缺点：

1.GraphQL的文档和事例少，尤其是Production级别的，几乎没有，大多数时候还得摸索着来，开源库还比较混乱，效率有点低
2.Application使用与迁移成本，它从根本上改变了数据的组织和暴露方式，可能从数据层到业务层都有很大影响，并不适合现有的复杂系统“先破后立”
3.每一种类型都需要一个resolve的处理，相对于REST，根据业务可能会写更多的resolve，查询时可能会因一个层级结构复杂而且有许多域有很大数据量的query跑许多个resolves，可能会存在频繁的查找数据库影响性能
4.缺乏动态类型，例如没有异构类型，只能自己写 Scalar 或者写成繁琐的Interface继承
5.对待error处理，REST根据 HTTP status code和message就可以得到响应的信息。而QgraphQL只要请求成功的status就是200，需要检查response查找error
总结：
今天我们只是讲了一些GraphQL的基本知识，但我们依然可以看出GraphQL的出现可以使我们后端API具有更大的灵活性以及扩展性，满足了不同client对数据的需要，大大丰富了API的数据提供的能力。GraphQL 的出现拓宽了我们对于API接口的认知，而且就近些年来看，越来越多的公司或组织已经开始尝试使用 GraphQL 了。在用好 GraphQL 的同时，我们要保持思考，时刻迸发出新的、更好的解决思路。