深入理解GraphQL

What is GraphQL

GraphQL是Facebook在2015年推出的一套数据查询语言，它并不是一个数据库查询语言，不依赖于任何特定的数据库管理系统，而是可以用任何其他语言实现的一个用于查询的抽象层，使得在不同的客户端可以使用相同的查询语法获取数据。

GraphQL可以将客户端解放出来，使得客户端不需要与多种不同语言的后端进行通信，并将单个请求转换为使用不同语言的多个服务的多个请求。如上图所示，客户端可以直接与抽象层GraphQL Server通信，抽象层GraphQL Server随后将与不同的服务端口完成通信，并返回结果。

Why we need GraphQL?

GraphQL is the better REST

GraphQL根本目的在于替代 RESTFul API 查询，建立更高效和灵活的数据获取方式。
目前很多科技巨头都已在使用，例如Facebook，GitHub，Pinterest, Twitter, HackerOne等等

GraphQL符合Web 发展的潮流趋势

1.早期的Web应用主要是通过静态HTML标签来展示数据。逐渐发展到使用JavaScript、CSS、SOAP、AJAX等技术给HTML添加动态功能。大部分Web内容通过桌面电脑的Web浏览器来访问。
如上图所示，早期的Web应用基本不分前后端，因为前端一般都是电脑上面的浏览器，页面由 JSP、PHP 在服务端生成，浏览器负责展现。基本上是服务端给什么浏览器就展现什么，展现的控制在 Web Server 层。
但是随着时代的发展，桌面电脑、iPhone、Android和平板电脑的出现，使得客户端变得更加复杂…

2.在Web2.0时代， 轻量级的REST架构成为主流。
如上图所示，REST最大的功劳在于前后端分离以及服务端无状态设计
（服务器不需要记录任何session，所有的状态都通过URL的形式记录在了客户端，无状态服务器均指无会话状态服务器）
REST架构优点：

• 前后端职责很清晰：前端工作在浏览器端，后端工作在服务端。
• 分离关注点：将用户接口（如用户界面）和数据存储分离，如果接口不变，组件可独立进化。
• 清晰的分工：可以让开发并行，测试数据的模拟不难，前端可以本地开发；后端则可以专注于业务逻辑的处理，输出 RESTful 等接口。

REST架构缺点：REST资源化的请求方式只适合面向简单的请求，对于具有复杂资源间关联关系或者个性化的请求就有点无能为力。在一些微服务化了的应用中，为了避免前端向多个微服务同时请求数据然后再组合，不得不增加一个data-view的后端微服务专门用于数据的抽取、转化。

3.在Web3.0时代，Facebook推出的GraphQL很有可能成为主流
如上图所示，GraphQ也和RESTFUL API一样致力于解决：如何有效处理不断变化的Web/Mobile端复杂的数据请求。但为什么说GraphQL可能替代 RESTFul API 查询成为主流呢？这就得详细比较一下了。

REST vs GraphQL

Data Fetching with REST and GraphQL

REST：如上图所示，REST 是多入口的，每个资源对应一个 URL，每个资源由后台定义好后，通过向指定 URL发送 GET 请求来获取资源，或发送 POST 请求来创建或操作资源。大部分 API 会返回 JSON 响应。 资源的类型和获取资源的方法是紧密相关的。客户端不能个性化的收集数据，除此之外，运行和控制多个端点是另一个难点，因为客户端经常需要从多个端点获取数据。 GraphQL：如上图所示，GraphQL是单入口的，所有的请求通过同一个 URL 进入服务器，在服务端，必须定义 Schema作为 GraphQL 请求的入口，一个用户可以通过传递查询字符串和声明他们需要什么来向服务器请求数据集。用户的 GraphQL 请求在服务端解析后，会对应到具体的 Schema。GraphQL 让客户端能够以一种声明性的语言描述其对数据的需求。这种声明性带来了一种围绕着 GraphQL 语言使用的心智模型，该模型与我们用自然语言思考数据需求的方式接近，让我们使用 GraphQL 时比使用其它方式更容易。

Advantages & disadvantages

每个语言或者技术框架都会有它各自的优势，缺点，适用场景。我个人总结了一些GraphQL与RESTFul API各自的优缺点，详见下图。

What problems can GraphQL solve?

GraphQL 漂亮地解决了六个重要问题，为了方便记忆，我也用思维导图画出来了，详见上图。

①

1.能够一次从服务器获取所需数据，没有冗余
2.Rest API需要往返多次，GraphQL与传统的REST方式相比，减少了网络请求次数，它的请求效率要更高
3. Mutation操作也很方便

②

1.服务端和客户端完全解耦，各自职责清晰。
2.GraphQL把客户端解放出来，客户端不需要直接和多种不同语言的后端进行通信。
3.客户端视图的变动完全不会影响到服务端的代码结构。4.GraphQL使得不同客户端使用不同语言进行GraphQL查询。

③

1.多个客户端请求多个服务的数据，GraphQL 层可以简化和标准化此通信过程，不同客户端的query一定是异步的，Mutation不是异步是串行的
2.异步执行策略不会按顺序来集成结果数据。但查询结果会按GraphQL规范顺序来返回。只是数据获取的顺序不确定。
3.graphql-java 是个全异步的执行引擎，调用 executeAsync() 后，返回 CompleteableFuture，graphql-java 保证所有 CompletableFuture 对象组合，最后生成合符 graphql 规范的执行结果 。

④

1.在 REST API 中，没有客户端请求语言。客户端无法控制服务器返回的数据。
2.使用GraphQL，前端开发人员可以用声明式的语言表达所需要的数据，只需要表达需要什么，而不是如何使其可用。
3.GraphQL提供了像GraphiQL一样强大的工具，可以从单一的端点（endpoints）来访问所需要的全部数据，在输入输入的查询都有自动补全和类型纠错功能，这归功于GraphQL的静态类型系统。
4. GraphQL采用所见即所得模型，返回结果就是输入的查询结构
5.因为有schema，所有错误的查询请求都会被服务端捕获，并返回一个错误提醒，这让调试变得易如反掌 。

⑤

1.REST API需要写很多文档说明，费时费力
2.GraphQL的文档永远和代码同步，自动生成，开发无需维护散落多处的文档，调用者也无需担心过期问题。
在GraphiQL的右边有个“Docs”面板，点开可以看到各种类型的签名和描述，每种类型可以继续点击查看详情。客户可以在完全没文档的情况下，仅通过它很快理解所有API。这个“Docs”并不用手动编写，它完全根据服务端代码自动生成，这被Facebook称为自省（Introspection）。

⑥

1.需求变动带来的新增字段不影响老客户端，服务端再也不需要版本号了，极大简化了兼容问题
2.老旧的字段可以废弃，加入@Deprecated注解，这样客户端查询时只会被Warning

总结

本文主要是结合自己所学知识，探讨了一些对GraphQL的理解，也把GraphQL和RESTful做了详细对比。
希望能对大家有所帮助~ 有问题欢迎留言交流，不足之处还请多多指正。