数据|是什么让我放弃了Restful API？( 二 ) 后端|rest|前端|

GraphQL本质上是一种基于api的查询语言，现在大多数应用程序都需要从服务器中获取数据，这些数据存储可能存储在数据库中，API的职责是提供与应用程序需求相匹配的存储数据的接口。

它是数据库无关的，而且可以在使用API的任何环境中有效使用，我们可以理解为GraphQL是基于API之上的一层封装，目的是为了更好，更灵活的适用于业务的需求变化。

简单的来说，它:

文章图片
它的工作模式是这样子的：

文章图片
GraphQL 对比 REST API 有什么好处？REST API 的接口灵活性差、接口操作流程繁琐，GraphQL 的声明式数据获取，使得接口数据精确返回，数据查询流程简洁，照顾了客户端的灵活性。
客户端拓展功能时要不断编写新接口（依赖于服务端），GraphQL 中一个服务仅暴露一个 GraphQL 层，消除了服务器对数据格式的硬性规定，客户端按需请求数据，可进行单独维护和改进。
REST API 基于HTTP协议，不能灵活选择网络协议，而传输层无关、数据库技术无关使得 GraphQL 有更加灵活的技术栈选择，能够实现在网络协议层面优化应用。
举个经典的例子：前端向后端请求一个book对象的数据及其作者信息。
我用动图来分别演示下REST和GraphQL是怎么样的一个过程。
先看REST API的做法：

文章图片
再来看GraphQL是怎么做的：

文章图片
可以看出其中的区别：

与REST多个endpoint不同，每一个的 GraphQL 服务其实对外只提供了一个用于调用内部接口的端点，所有的请求都访问这个暴露出来的唯一端点。

文章图片

GraphQL 实际上将多个 HTTP 请求聚合成了一个请求，将多个 restful 请求的资源变成了一个从根资源 POST 访问其他资源的 Comment 和 Author 的图，多个请求变成了一个请求的不同字段，从原有的分散式请求变成了集中式的请求，因此GraphQL又可以被看成是图数据库的形式。

文章图片
那我们已经能看到GraphQL的先进性，接下来看看它是怎么做的。
GraphQL 思考模式使用GraphQL接口设计获取数据需要三步：

文章图片

首先要设计数据模型，用来描述数据对象，它的作用可以看做是VO，用于告知GraphQL如何来描述定义的数据，为下一步查询返回做准备；
前端使用模式查询语言（Schema）来描述需要请求的数据对象类型和具体需要的字段（称之为声明式数据获取）；
后端GraphQL通过前端传过来的请求，根据需要，自动组装数据字段，返回给前端。

GraphQL的这种思考模式是不是完美解决了之前遇到的问题呢？！
总结它的好处：
在它的设计思想中，GraphQL 以图的形式将整个 Web 服务中的资源展示出来，客户端可以按照其需求自行调用，类似添加字段的需求其实就不再需要后端多次修改了。关注公众号程序员小乐回复关键字“Java”获取大厂面试题和答案。
创建GraphQL服务器的最终目标是：
允许查询通过图和节点的形式去获取数据。

文章图片

GraphQL执行逻辑有人会问：

使用了GraphQL就要完全抛弃REST了吗？
GraphQL需要直接对接数据库吗？
用GraphQL需要对现有的后端服务进行大刀阔斧的修改吗？

答案是：NO！不需要！
它完全可以以一种不侵入的方式来部署，将它作为前后端的中间服务，也就是，现在开始逐渐流行的前端 —— 中端 —— 后端的三层结构模式来部署！
那就来看一下这样的部署模式图：

文章图片
也就是说，完全可以搭建一个GraphQL服务器，专门来处理前端请求，并处理后端服务获取的数据，重新进行组装、筛选、过滤，将完美符合前端需要的数据返回。
新的开发需求可以直接就使用GraphQL服务来获取数据了，以前已经上线的功能无需改动，还是使用原有请求调用REST接口的方式，最低程度的降低更换GraphQL带来的技术成本问题！
如果没有那么多成本来支撑改造，那么就不需要改造！
只有当原有需求发生变化，需要对原功能进行修改时，就可以换成GraphQL了。
GraphQL应用的基本架构下图是一个 GraphQL 应用的基本架构，其中客户端只和 GraphQL 层进行 API 交互，而 GraphQL 层再往后接入各种数据源。这样一来，只要是数据源有的数据， GraphQL 层都可以让客户端按需获取，不必专门再去定接口了。