我们在使用Rest接口时，接口返回的数据格式、数据类型都是后端预先定义好的，如果返回的数据格式并不是调用者所期望的（比如：只需要用其中的某些字段），作为前端的人员可以通过以下两种方式来解决问题：
与后端沟通，修改接口（更改数据源）自己做一些适配工作（处理数据源）一般如果是个人项目，改后端接口这种事情可以随意，但是如果是公司项目，改后端接口往往是一件比较敏感的事情。因此如果接口的返回值，可以通过某种手段，从静态变为动态，即调用者来声明接口返回什么数据，很大程度上可以进一步解耦前后端的关联。那么graphql是否可以完成此需求呢，我们一起来学习看看吧。
关于graphQL的介绍在网上有很多，但从核心上讲，是一门语言；进一步讲，是一门查询语言；再进一步讲，是一种API查询语言，为我们提供了一种更有效的设计、创建和使用 Api的方法有疑问？API还能查？API不是用来调用的吗？没错，这正是GraphQL的强大之处。
在GraphQL中，通过预先定义Schema和声明一些Type来达到上面的效果，我们需要知道：
对于数据模型的抽象是通过Type来描述的对于接口获取数据的逻辑是通过Schema来描述的Type
Scalar Type(标量类型)
标量类型:String、Int、Float、Boolean、Enum
Object Type(对象类型)
type Product { id: ID name: String isUnShelve: Boolean }Schema
是用来描述对于接口获取数据逻辑的。在graphQL中，我们用Query来描述资源的获取方式。Query?
Query GraphQL中使用Query来抽象数据的查询逻辑，有三种查询类型:
query（查询）mutation（更改）subscription（订阅）GraphQL中Schema,Type,Query之间的关系是怎样的呢？
Query 代表的是查询的统称，也就是一次查询可以成为一个 Query；query 是 Query 的一个类型种类，当前有三种类型： query，mutation，subscription；关系：Schema 由 Type 来描述，Query 的查询语法和格式受 Schema 约束，而 query,mutation,subscription 是 Query 的三种类型，分别对应不同的业务场景。举例说明
查询
//Rest接口 GET /api/getData/product/ //graphql query{ getProduct():[Product] }更改
//Rest接口 POST /api/getData/product/ //graphql mutation { createProduct(): Product }在graphql中就这样可以查询和增加数据了？当然不是喽(才进行一半喲)，咱们继续吧👇👇👇
Resolver
❉ Resolver在graphql中扮演什么样的角色呢？我们来举个🌰吧：
去餐厅时首先会看菜单 （这个菜单就如同GraphQL的Schema），一一列出关于「我们可以点的食物(查询的资料)」、「套餐搭配(资料间的关联)」、「套餐的内容(资料的架构)」等。点完餐，后面的厨房就开使针对我们的餐点料理出你要的食物(拿出你要的资料) ，也就是Resolvers在做的事情。
❉ 问题：如果Schema是菜单、 Resolver是厨房，那点餐的人是？
❉ Resolver（厨房）具体是如何工作的呢（graphql内部工作机制）？
🌰
//查询 Query { getClassify { id product { id, name } } } //type type classify{ id ...... } type Product{ id name ...... }步骤
首先进行第一层解析，需要它的名字是getClassify；之后会尝试使用getClassify的Resolver获取解析数据，第一层解析完毕；之后对第一层解析的返回值，进行第二层解析，当前getClassify还包含2个子Query，分别是id和product: id为标量类型，解析结束;product为对象类型，尝试使用Product的Resolver获取数据，当前field解析完毕;之后对第二层解析的返回值，进行第三层解析，当前product还包含一个Query, id,name，由于它是标量类型，解析结束 。