现在市面上有不少GraphQL（下面简称gql）的资料了，GraphQL这个规范或者说思想出来也有三年多了，不少公司有了实践，有成功的，也有留下一堆坑填不了跑路的😜。大掘金上有篇译文叫《 REST API 已死，GraphQL 长存 》，长时间过去了，用的人也不多😅，所以分享一下基础知识，互相学习。最后，我觉得在偏传统的2B SaaS类领域，gql的潜力还没有被完全释放。
它是什么？从哪里来？要干什么？
简单地讲，对于前端，它就是让你舒舒服服发请求的
严格的说，它是一种api设计思想，用来取代restful api的一种前端处于主导地位的api规范。它把前端所需要的api用类似图数据结构（graph）的方式展现出来，让前端很方便的获取所需要的数据。
起源，restful api的问题
如果采用restful api的话，后端要持续维护api doc，但是实际场景是这样的：
1.来了新需求，后端先评估和开发，后端弄得差不多，前端才开始，然后中间后端一顿猛改
2.由于多种原因，后端经常自己偷偷改掉传参或者返回值，完了接口报错，测试姐姐把前端叫过去一顿批，前端一脸懵圈，仔细检查，发现问题，找后端撕X，这样一个循环非常影响开发效率。
gql出现
由于上面这一堆的问题，facebook公司2012年内部实践了GraphQL，15年刚开源的时候引起了很多大公司和社区关注，落地了很多规范和框架。需要了解详细历史可以看看底下的youtube视频。
这种叫GraphQL的东西帮助人们经过一系列定义和规范，可以发送gql请求非常方便的拿到想要的数据，甚至还可以修改数据，而不用后台的配合，而且一旦Schema确定（数据库那边定义好），前后端就可以快速并行开发，例如下图获得某个用户的信息，我想要这个用户的什么属性就写什么，graphiQl工具可以进行完整的详细的提示，请求主体简单明了
query{
student{
id
name
age
}
course{
id
title
}
}
gql理想使用场景
数据库建好模型，前后端可以同步开始开发需求，前端只有少数需要依赖后端接口，前端开发过程中可以方便的拿到任何想要的数据，从而节省大量联调接口的时间，迅速的完成一个项目。
实现原理
gql的实现挺复杂的，代码有点难懂，不过原理说起来比较简单易懂😀
var { graphql, buildSchema } = require('graphql');
// Construct a schema, using GraphQL schema language
var schema = buildSchema(`
type Query {
hello: String
}
`);
// The root provides a resolver function for each API endpoint
var root = {
hello: () => {
return 'Hello world!';
},
};
// Run the GraphQL query '{ hello }' and print out the response
graphql(schema, '{ hello }', root).then((response) => {
console.log(response);
});
如上就是一个最简单的node版的gql服务器
gql把定义好的schema拿到，用root之类的resolve解析器去解析发送来的'{ hello }'请求，然后返回给相应的json值。上面代码打印出的response如下
{
data:
{
hello: 'Hello world!'
}
}
当然，resolve逐层解析会有一些问题，如果resolve请求数据库，就要用到DataLoader
DataLoader是gql服务器性能的关键一环，也是gql社区的主要推动完善方向，就像react里面的shouldComponentUpdate一样制约着gql服务器的性能。
DataLoader 能让我们从数据库读取数据并让数据能被 GraphQL 处理，我们使用 DataLoader，而不是直接通过 SQL 查询从数据库获取数据，将 DataLoader 作为代理以减少我们实际需要发送给数据库的 SQL 查询。 DataLoader 使用批处理和缓存的组合来实现。如果同一个客户端请求会造成多次请求数据库，DataLoader 会整合这些问题并从数据库批量拉取请求数据。DataLoader 会同时缓存这些数据，当有后续请求需要同样资源时可以直接从缓存获取到。
具体使用
通过服务端对请求的元数据的type进行严格的定义，我们只要在客户端发送gql请求就能返回期望的相应类型的数据
下图是请求格式，query【请求】，mutation【修改】和subscribe【订阅】是三种api发送方式，query用的多一些，mutation相对传统的restful来说不够可靠和安全，subscribe类似websocket
query
{
schema {
types {
id
name // 获取根字段名
fields {
id
name // 获取字段名
}
}
}
}
正式环境下书写的大概长下图这样，一些标量、片段之类的细节不多说了，看GraphQL中文官方网站说的很详细了
辅助工具graphiql和playground
前端进行gql开发的神器，十分好用，带智能提示，这个schema里面都有哪些type，每个类型都会返回什么类型的值，数字还是字符串，一目了然，比看api文档快得多
graphiql是网页版，足够好用
playground对graphiql更进一步，多实现了一些小功能，是electron构建的应用，类似RN里面的react-devtools
封装gql的客户端&服务端框架
使用gql过程中可以自己基于业务进行二次封装，也可以使用现成框架，用于更方便的发gql请求，并与react或者vue组件进行互动。社区框架太多了，就挑几个说一下，具体可以看github上搜集的graphql资料 全
apollo-boost
包含下图5个框架，与react-apollo一起搭配使用，是apollo社区推荐的前端使用方式，开发起来快，但是拓展修改不太方便，不适合自定义的公司项目
apollo-client
上图5个框架中最核心的一个，将各类接口微服务和数据库操作进行封装，集成redux，更易使用，但是略显臃肿，个人觉得，gql与数据库直接通信才是优势，对接rest等有点绕远路了。
relay
facebook官方前端缓存框架，与apollo-client类似，star数比apollo-client要高2k，具体使用起来差不多
apollo-server
apollo-server是一个在nodejs上构建grqphql服务端的web中间件，支持express、koa等，了解不多，毕竟gql服务器端支持很多后端语言，java等主流语言都可以封装gql服务端
graphpack
号称零配置gql服务器，适合迅速学习搭建gql服务器
原理：高度封装了apollo-server，利用webpack和nodemon本地开启一个gql服务器
Gatsby
GatsbyJS这个框架国外挺火的，是一个优秀的静态网站生成框架，优点是搭建起来，维护相当方便，甚至可以交给完全不懂编程的人。
特点是极其适合科学类介绍网站以及各种框架类文档（最适合建立markdown博客），高度封装了gql和markdown解析插件。
prisma
一个orm库外加轻量的后端服务，可自动生成gql接口暴露出来，围绕prisma的生态已经初步建立，社区正在推动prisma2，现在正在待发布阶段，未来可期
和restful比较的优缺点
优点
- 优点就是后端可以少招几个写接口的🐶，可能会节约成本
- 前后端一起开发，节约工期
- 较少维护api文档，节省精力
说了这些，其实单对于前端来说，帮助不算特别大🐶
缺点和难推广的地方
-
后端或者中间层把gql封装相应业务对接数据库是难点，需要高端人力
-
需要前端多少学一点类sql语句，不过大部分场景可以封装好固定的sql语句
-
封装gql不好会产生sql性能问题，三级嵌套联查还有n+1的老问题又会冒出来，需要持续优化
-
前端排除bug需要一定的后端知识，前后端架构多少了解一些
总结
1.如果尝试开发graphql项目，建议直接上apollo全家桶
2.随着社区越来越成熟，前端入门门槛也在降低，graphql可以一试
3.当前技术来说，graphql只适合对接数据库的查询，其他开发成本还是过高
4.尽早上车，多学一门是一门，技多不压身
篇幅所限，只是走马观花的介绍，每个小点展开都是一篇文章，就不多赘述了，如果大家想体验一下gql，带来的生产力提升绝对是物超所值的！大家有看不明白的地方或者作者说错的地方，欢迎在评论区留言，我会着手修改😘，另外，因为个人认知研究不断深入和前端技术快速更迭，这篇文章也会持续的进行更新维护
搜集的优秀资料
市面上一些优秀的资料，欢迎大家补充！
