What we will Talk?

之前总是看到GraphQL这个词（以下简称 GQL ），最近几天终于花时间了解一下 GQL ，最明显的一个结论是：它不是访问 DB 的，它是一种 API 设计方式。
GQL 可以说是一种规范/协议，不出意外会搜到 https://graphql.org 这个地址，这个网站只是对它的一些概念介绍，不包含什么框架与入门，所以上不了手。

个人感觉的优点

更加灵活
GQL 示例给人的第一个感觉就是：要什么字段就返回什么字段，返回结构与请求结构一模一样，不多不少，这也是各个 GQL 相关的网站常见的描述。此外，不像 Rest API 那样编写出一大堆 UR L，甚至多到有些URL名字很像，GQL 只有一个访问入口，它的不同查询/修改靠的是向这个路径传递不同的指令参数。
减少重复性工作
GQL中有个叫做 resolver 的东西，它被用来描述如何获取字段对应的数据，一次查询就是对这些 resolver 的链式组合。如果能把它设计好了，是可以减少重复性代码的，因为实现GQL规范的开源工具帮我们做了很多看不到的组合操作。
缓存
GQL客户端自带缓存，减少重复向服务端发起请求的次数。

个人感觉的缺点

复杂度增加
- 说白了就是没有 Rest API 简单直接，对于用惯了 Rest API 的开发人员来说，思维不是那么容易转变过来。
- 在编写 Rest API 的时候，前后端开发共同确认渲染所需数据，然后编写特定的接口，GQL 其实还是需要共同确认所需数据，后端编写 resolver 提供指令支持，所以交流这一步并没有简化。
- 相对于Rest API，GQL 就像是多包了一层。Rest API 在访问数据源之后，将查询得到的数据组合返回前端即可，而 GQL 则是访问数据源之后，把结果交给了resolver，然后由 GQL 组合再返回前端。回想一下 GQL 只有一个路径其他全靠指令，或许“多”的这一层就相当与 Controller 吧，或许应该叫做 API 。
有可能导致负优化
resolver 组织不好可能会导致访问DB的次数猛增。
错误处理
由于包了一层，导致距离 HTTP 思维方式较远，直接返回 200，具体什么错误需要到响应结果里查询，这一点需要看后端开发讲不讲武德，而 Rest API 甚至可以通过 HTTP 响应就可以更快确认问题所在。