1. 介绍
1.1. FB员工的介绍
GraphQL 是一种针对 Graph（图状数据）进行查询特别有优势的 Query Language（查询语言），所以叫做 GraphQL
https://www.zhihu.com/question/264629587/answer/949588861
......
数据必需已经以图的数据结构进行存储才有优势
......
Facebook 从来没有公开自己的 GraphQL 后端设计，使得大家必需要用第三方的，但体验显然不如我们在 Facebook 内部使用 GraphQL 好
1.2. 用自己的话解释
一种dsl，声明式、面向数据的查询语言，用于前后端通信。
- 和sql的关系
sql也是声明式、面向数据的查询语言，不过是表模型，而graphql是图模型；graphql是面向前后端通信设计的，不是为了db查询场景设计的，图db领域的查询语言已经有很多了,比如gremlin， 见https://zhuanlan.zhihu.com/p/115098569
不过一些图数据库也开始支持graphql
Stardog and GraphDB (from Ontotext) both offer GraphQL clients now.
https://datalanguage.com/blog/graphql-and-graph-databases
Graphql比传统图db查询语言表达力弱很多，db支持它更多是为了给用户提供语法糖，比如如果上层也是graphql，db支持会让用户更方便
However, GraphQL does only provide another query mechanism for your graph database alongside SPARQL or Gremlin. Moreover it is much less expressive, and most definitely not designed for exploiting the rich semantics of RDF and OWL.
- 和rpc的关系
个人喜欢的归类是：rpc和”面向数据的dsl”都是分布式系统的通信原语，rpc是面向过程调用，sql、graphql等dsl是面向数据。
就graphql各种开源实现看来，和rpc原理基本一样，自己定schema，自己写查询实现
2. 用法
2.1. 教程
- video course
https://www.bilibili.com/video/BV1EE411e7zB?p=3
- tutorial
写的不太好，勉强能看
2.2. 用自己的话解释
2.2.1. 后端
起graphQL服务
image.png
类似于发布一个rpc服务，需要IDL（或者叫schema。好像graphql起了个名字叫SDL） + 实现，传给启动graphQL服务器的库
不同语言有自己的graphql库，包含server/client/tools，比如nodejs的server端有express-graphql，和express整合
难怪大家吐槽没有开源真正的后端运行时，这里每个方法都得写单独的查询实现，很容易导致查询db请求过多，核心难点是怎么减少查询量：存储层自带图查询能力，避免迭代查询。
在实现代码里查db
domain object和 table一一对应
最简单的就是每个领域模型有自己的CRUD方法，实现代码就是CRUD数据库
image.png
https://www.bilibili.com/video/BV1EE411e7zB?p=9
图模型
Q: 如何理解“适合数据预先已经以图的形式存储”，看上面的例子，查表正常查，看起来和图没啥关系?能否举例说明?
A: 可以看下答案中举的例子，如果有复杂的join关系，适合用图建模
image.png
什么是 GraphQL？ - Cat Chen的回答 - 知乎
另一个例子是github api，比如要查layotto仓库的owner和fork、这些fork出来的仓库各自的owner、这些owner的头像和仓库、这些仓库的fork……这就是典型的图模型
2.2.2. 前端查询
GraphiQL : 一个debug控制台
起服务器的时候可以选择起个debug控制台(GraphiQL)，自带个网页客户端+文档站
查询代码：就是发http请求
image.png
https://www.bilibili.com/video/BV1EE411e7zB?p=5
练习
写了github活跃度统计工具，调github graphql API
https://github.com/seeflood/github-weekly-statistics
3. 评价
3.1. pros
- 灵活。包括前后端合作时，对前端来说特别灵活；open api等场景，对于用户来说特别灵活
- 配套工具链非常强大。因为有一套IDL (SDL)规范，社区可以为这套规范开发通用的工具链。比如可以体验下GraphiQL
感觉GraphiQL要是能生成client代码就牛逼了
3.2. cons
推广上存在的问题
https://www.zhihu.com/question/38596306
-
对后端架构改造较大;
-
后端核心实现没开源；社区搞的后端实现有很多问题，比如db查询次数过多等
Facebook 从来没有公开自己的 GraphQL 后端设计，使得大家必需要用第三方的，但体验显然不如我们在 Facebook 内部使用 GraphQL 好
https://www.zhihu.com/question/264629587/answer/949588861
3.3. 选型逻辑：什么时候用graphql
image.png
https://segmentfault.com/a/1190000022369233
此外，之前有同事在后台系统选用graphql暴露api，目的是：以后有新的页面需求、新的后台系统要做的时候，让前端自己调graphql、后端不用写新接口了
4. 业界实践
作为前后端通信协议
https://chinese.freecodecamp.org/news/a-detailed-guide-to-graphql/
一些比较有名的公司比如 Twitter、IBM、Coursera、Airbnb、Facebook、Github、携程等，内部或外部 API 从 RESTful 转为了 GraphQL 风格，特别是 Github，它的 v4 版外部 API 只使用 GraphQL。据一位在 Twitter 工作的大佬说硅谷不少一线二线的公司都在想办法转到 GraphQL 上，但是同时也说了 GraphQL 还需要时间发展，因为将它使用到生产环境需要前后端大量的重构，这无疑需要高层的推动和决心。
体感最强的就是github的API，之前的api满足不了我的工具的查询需求。所以open api场景用graphql带来的好处是灵活
https://docs.github.com/cn/graphql
https://github.blog/2016-09-14-the-github-graphql-api/
图db
不是主流，有些图db会“额外”支持
Stardog and GraphDB (from Ontotext) both offer GraphQL clients now.
https://datalanguage.com/blog/graphql-and-graph-databases
大数据领域
可以由graphql网关对接多个数据源，每个数据源写一个resolver就行了（比如MaxCompute resolver)，用户可以随意的进行聚合多数据源的查询
比如Apollo Federation解决方案可以做跨数据源的查询、合并。我看一些公司内部是自己封装的graphql网关层。
这种场景其实还有作为cross-platform api的价值：用户面向统一的graphql schema编程，不需要关心具体的实现、具体的供应商。
其他领域
pingcap在chaos mesh中用graphql查资源状态
https://www.bagevent.com/event/7811841
Dapr支持graphql binding
https://docs.dapr.io/reference/components-reference/supported-bindings/graghql/
网友评论