初识GraphQL

最近项目上接触到了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的优点

1. REST规范有助于统一API的设计，使得API适用于各种前端设备；

2. REST将业务逻辑抽象为对资源的操作，容易理解；

3. 基于资源的抽象，有利于构建更稳定的服务；

REST的缺点

1. API粒度较粗，使用时存在过度获取（Over-fetch）、获取不足(Under-fetch)的问题

2. 面向资源的一个弊端就是当需要获取关联的资源时，需要进行多次数据交互，比如“文章->评论->评论回复”

GraphQL所解决的问题

1. 对于粒度问题，GraphQL细化到了字段级别，客户端可以自行决定需要服务端返回的字段

2. GraphQL支持Model的关联查询，对类似“文章->评论->评论回复”这样的需求，可以一次性返回
   此外还有一些帖子宣称的GraphQL的优点

1.客户端驱动，由客户端来决定服务端返回什么样的Response
2.API版本控制，由于GraphQL将粒度细化到了字段级别，版本控制也可以做到字段级别，RESTFul的粒度则是资源（uri）级别
3.强类型…

GraphQL的缺点

GraphQL在解决Rest存在的问题的同时，也引入了新的问题：

1. 缓存功能不成熟，相比使用REST API，为GraphQL实现缓存要付出更多的努力；

2. GraphQL暴露了服务端的数据模式，这基本上也就让使用者获取到了服务端的数据结构，使得服务端更容易被攻击；

3. GraplQL目前没有关于身份验证和授权的原生解决方案，需要在业务逻辑层单独实现；

对比SQL

最近刚刚接触GraphQL，不知为啥从一开始听到这个技术，就对其带有一丝偏见，也许是因为它有个“蹭热度”形式的名称吧。
Graph-QL与(S)tructured-QL名称相识，难道是因为Structured这个词被占用了，就换个更高端Graph？
以我粗浅的理解，两者不仅名称类似，还存在很多相似的地方。

1. 语法可以相互转换
   比如GraphQL查询Movie
</