GraphQL一个简单的入门示例

本文首发于个人博客

什么是GraphQL

官方文档定义：一种用于API的查询语言， Graph + Query
有以下特点

请求你所要的数据不多不少
获取多个资源只用一个请求
描述所有可能的类型系统

解决了什么问题

1. 来说一个实际的场景：

前后端联调接口一直以来都是特别费劲的一个环节，使用REST接口，接口返回的数据格式，数据类型（有哪些字段，字段的类型）都是后端自己预先定义好的，如果返回的数据格式并不是调用者所期望的，作为前端的我们可以通过以下两种方式去解决

和后端沟通，该接口（更改数据源）
自己做一些适配工作（处理数据源）

有这种经历的人都知道，让后端改接口这是一个很不现实方案，尤其是对于三端（web、andriod、ios）公用同一套后端接口的情况下，让后端改接口的结构基本不可能，所以一般都是前端自己做一些接口数据的适配工作

其实我们真的很希望，我们需要什么数据，需要什么格式，后端就按照什么格式给我们返回什么样的数据结构，我们要哪些字段，后端就只给我们返回我们需要的这些字段，其他的都不返回，这样，前端就和后端解耦了，我们不用再每天和后端因为接口问题去撕逼，GraphQL就是一个这样的思路来帮助我们解决这个前后端联调接口的问题，在前端直接写查询，后端只管给前端返回前端查询的这些数据；

2. 还有一种场景:

一个页面里展示的信息， info1, info2, info3，前端需要请求多个接口，info1对应的接口A中的a字段，info2对应的接口B中的b字段，info3对应的接口C中的c字段

// /api/user/A
{
    id: 1111,
    name: '张三',
    a: '当前页面要展示的info1',
    b: 'b'
    // 其他字段
}
// /api/order/B
{
    id: 2222,
    name: 'hahah',
    a: 'a'
    b: '当前页面要展示的info2',
    // 其他字段
}
// /api/system/C
{
    id: 3333,
    name: 'hehe',
    a: 'a'
    c: '当前页面要展示的info3',
    // 其他字段
}

这个时候，稍微有点脾气的前端，都会去找后端撕逼，

前端A: “就这三个字段，你还让我请求三个接口，你不能一个接口都返回给我吗”，
后端B：“哎，我也想啊，但是xxxxx，所以我这边不好改，”，
...
最后那就这样吧。

当然，我举得这个例子是一个很简单的场景，实际开发过程中要比这个还要复杂；

如果使用GraphQL的话，前端自己写查询，这个页面需要哪些需哪数据，后端就返回给哪些数据，
这是考虑到后端所有的接口都在同一个域下面，但是一般比较复杂的系统，后端都会分为不同的域，用户域，商品域，基础模块域，交易域等等，这时即使用了GraphQL也可能

后端C：“你看其他都不是我负责的域，我要是自己给你封装一个，我自己底层需要经过xxxxx等复杂的步骤去获取其他域的，这个很复杂，你还是直接去他哪个域去查询吧”，

有两种方法，

你就再多写一个GraphQL
自己写一个node中间层，中间层来处理这些接口数据的聚合，换句话说，中间层来聚合成一个GraphQL查询来返回给前端，中间层分别取调用服务端的三个接口，然后把三个接口返回的数据聚合成前端所需要的