最近项目上接触到了GraphQL,但由于对其的理解很不足,应用的时候出现了很多问题和困扰。
此外,GraphQL据说是为了替代RestFul,但在为数不多的实践中,GraphQL
并没有像Docker、K8S那样带给人直观的颠覆性体验,可能随着使用经历的增加,会有新的体会吧。
本文属入门性质,分两部分:
-
GraphQL与RestFul、SQL、BFF的对比
-
GraphQL基础
GraphQL与RestFul、SQL、BFF的对比
对比RESTFul
严格来说,RESTFul与GraphQL并不是一个层面的东西。
REST是一种架构风格,即表述性状态传递(Representational State Transfer),是Web API实现的约束,提倡客户端和服务器以无状态模式交换信息。
GraphQL则是Web API的查询语言,由Facebook于2015年开源,它既不是架构风格,也不是Web服务,可以看作一个中介,用来查询从各种数据源(数据库、Web服务等)接收的数据。
REST的优点
-
REST规范有助于统一API的设计,使得API适用于各种前端设备;
-
REST将业务逻辑抽象为对资源的操作,容易理解;
-
基于资源的抽象,有利于构建更稳定的服务;
REST的缺点
-
API粒度较粗,使用时存在过度获取(Over-fetch)、获取不足(Under-fetch)的问题
-
面向资源的一个弊端就是当需要获取关联的资源时,需要进行多次数据交互,比如“文章->评论->评论回复”
GraphQL所解决的问题
-
对于粒度问题,GraphQL细化到了字段级别,客户端可以自行决定需要服务端返回的字段
-
GraphQL支持Model的关联查询,对类似“文章->评论->评论回复”这样的需求,可以一次性返回
此外还有一些帖子宣称的GraphQL的优点
1.客户端驱动,由客户端来决定服务端返回什么样的Response
2.API版本控制,由于GraphQL将粒度细化到了字段级别,版本控制也可以做到字段级别,RESTFul的粒度则是资源(uri)级别
3.强类型…
GraphQL的缺点
GraphQL在解决Rest存在的问题的同时,也引入了新的问题:
-
缓存功能不成熟,相比使用REST API,为GraphQL实现缓存要付出更多的努力;
-
GraphQL暴露了服务端的数据模式,这基本上也就让使用者获取到了服务端的数据结构,使得服务端更容易被攻击;
-
GraplQL目前没有关于身份验证和授权的原生解决方案,需要在业务逻辑层单独实现;
对比SQL
最近刚刚接触GraphQL,不知为啥从一开始听到这个技术,就对其带有一丝偏见,也许是因为它有个“蹭热度”形式的名称吧。
Graph-QL与(S)tructured-QL名称相识,难道是因为Structured这个词被占用了,就换个更高端Graph?
以我粗浅的理解,两者不仅名称类似,还存在很多相似的地方。
- 语法可以相互转换
比如GraphQL查询Movie <