Why GraphQL? 6个问题
GraphQL, 是一个API的标准: specification.
对于每个新技术, 要搞清楚的6个问题:
- 1.这个技术出现的背景, 初衷, 要达到什么样的目标或是要解决什么样的问题.
- 2.这个技术的优势和劣势分别是什么, 或者说, 这个技术的trade-off是什么.
- 3.这个技术使用的场景.
- 4.技术的组成部分和关键点.
- 5.技术的底层原理和关键实现.
- 6.已有的实现和它之间的对比.
1.这个技术出现的背景, 初衷, 要达到什么样的目标或是要解决什么样的问题.
GraphQL是相对于REST API的另一种标准.
相对于REST返回固定结构数据的多个endpoints, GraphQL的server只暴露一个endpoint, 由客户端来规定想要的字段和结构, 服务端精确返回client要求的数据.
初衷和背景
2012年, Facebook有一个新闻类的iOS app. 随着移动用户增多, 网络请求有设备电量消耗, 弱网环境等问题.
这在当时是一个非常紧迫的issue, 于是他们研究出了GraphQL, 减小了需要发送的请求个数和数据传输量.
2015年Facebook将GraphQL开源.
类似的尝试还有Netflix的Falcor和Coursera, 后者后来取消了自己的effort, 加入了GraphQL的阵营.
目标和要解决的问题
GraphQL思想: enables declaratative data fetching.
GraphQL要解决的问题: 优化客户端向服务器请求数据的过程:
- 对于同样的业务需求, REST API可能要请求多个endpoints, GraphQL可以用一个请求.
- 数据形式是客户端定义的, 只取想要的数据, 不会取多余的数据, 减小了数据传输量.
- 各个前端可以访问自己想要的数据.
- 快速开发, feature快速迭代. 升级改动时, 可能不需要后端改动.
2.这个技术的优势和劣势分别是什么, 或者说, 这个技术的trade-off是什么.
GraphQL的优势
- 客户端可以精准取到自己想要的数据, 不再多取或者少取. 多取: 取到了不需要的数据, 可能有性能, 流量问题; 少取: 需要多发请求来满足需求.
- API有strong typed schema. 客户端可以通过schema知道API支持什么, 包括操作, 参数, 可能的响应等. 支持introspection. schema是一个API能力的contract, 不需要再额外写文档, 一旦定义好了之后, 前后端可以独立工作.
- 强类型, 利用schema, 结合build工具, 可以在编译时期对请求进行一些检查.
- 有助于产品快速升级迭代. 前端的改动可以不需要后端的修改.
- 富有洞察力的数据分析: 因为可以精细地知道client要读的数据, 对数据的的使用情况可以有更深的理解. 在API改动的时候可以deprecate掉不用的数据. 也有助于后端的性能分析.
- schema stitching: 多个不同的GraphQL的endpoints可以组合成为一个.
- 社区支持好. 多种语言: https://graphql.org/code/#server-libraries; 多种客户端: https://medium.com/open-graphql/exploring-different-graphql-clients-d1bc69de305f; 多种工具: Prisma, GraphQL Faker, GraphQL Playground, graphql-config.
GraphQL的缺点
- 可能并不适合所有类型的API. 比如认证, 授权(authentication and authorization).
- 服务器端的性能问题.
- 服务器端的Cache. 需要一个全局的id, 讨论见: Caching.
- 通信的快速发展, 实现GraphQL节约的数据传输量可能不值一提, 优势不明显.
3.这个技术使用的场景.
GraphQL是一种规范, 具体实现有多种.
和传输层, 数据库, 数据源类型都不相关.
GraphQL应用场景:
- 在数据库之上.
- 和已有系统集成. 可以用来改造遗留系统, 统一接口, 隐藏实现.
- 混合前两者, 在已有系统和数据库之上.
理想开发场景: 根据数据, 建立好schema之后, 前后端独立开发, 前端可以根据需要拿到想要的数据.
4.技术的组成部分和关键点.
Schema
Schema定义了API的能力, 是server和client之间的协议. 规定了客户端可以请求的数据和类型.
The Schema Definition Language (SDL): Schema Definition Language.
Root Types: Query, Mutation, Subscription.
对应查询, 更改和订阅.
Server端
GraphQL服务器只暴露一个endpoint.
在API的设计上, 需要把数据按照Graph来想, 而不是按照endpoints来想, 更专注于描述数据.
对于Schema定义好的结构, Server端对于每个字段实现resolver function, 进行查询.
Server库: https://graphql.org/code/#server-libraries
Client端
客户端查询, 更加自主的结构, 字段级别的粒度.
Client库: https://graphql.org/code/#graphql-clients
和Server库一样, 这些库为我们封装了一些样板代码, 简化方便了我们的开发.
5.技术的底层原理和关键实现.
Server端实现
- schema的定义. -> structure.
- resolver function形式的具体实现. -> behaviour.
queries/mutations都包含一个字段集合.
在server上, 每个字段都有一个resolver function, 用来读取相应字段的数据.
Server上执行的机制:
The query is traversed field by field, executing “resolvers” for each field.
广度优先. 按层级进行.
为了改善效率, JavaScript有dataloader, 把resolver的调用批处理, 减少重复调用.
Client端实现
客户端实际上发送的是POST请求, GraphQL的query作为JSON payload的字段.
可以用curl命令模拟得到相同的效果, 见:
https://graphql.org/graphql-js/graphql-clients/
introspection query可能是唯一的GET请求.
6.已有的实现和它之间的对比.
REST的好点子: stateless servers, structured access to resources.
REST的缺点: 快速变化的客户端需求可能和REST的静态属性不合.
REST:
- 业务数据不同, 可能需要client向server发送多个请求.
- 请求中可能包含多余数据. old client也会收到新增的数据.
- 弱类型.
- 错误返回不同的状态码.
- API升级需要提供不同的版本号.
GraphQL更加灵活和有效率.
- 单个请求.
- 不包含多余数据.
- 强类型.
- 错误返回是在响应中的"errors"字段, 包含错误list, 每个错误有"message"字段.
- API升级不需要版本号. 新增数据和类型不会影响以前的查询.
REST和GraphQL两者可以共存.
