GraphQL初步认识
背景
REST作为一种当代网络运用非常盛行的软件架构风格，自从Roy Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的大略易用性，可扩展性，伸缩性受到广大Web开拓者的喜好。
REST 的 API 合营JSON格式的数据交流，使得前后端分离、数据交互变得非常随意马虎，而且也已经成为了目前Web领域最受欢迎的软件架构设计模式。
但随着REST API的盛行和发展，它的缺陷也暴露了出来：
滥用REST接口，导致大量相似度很高（具有重复性）的API越来越冗余。对付前端而言：REST API粒度较粗，难以一次性符合前真个数据哀求，前端须要分多次要求接口数据。增加了前端职员的事情量。对付后端而言：前端须要的数据每每在不同的地方具有相似性，但却又不同，比如针对同样的用户信息，有的地方只须要用户简要信息（比如头像、昵称），有些地方须要详细的信息，这就须要开拓不同的接口来知足这些需求。当这样的相似但又不同的地方多的时候，就须要开拓更多的接口来知足前真个须要。增加了后端开拓职员的事情量和重复度。那我们来剖析一下，当前端需求变革，涉及到改动旧需求时，会有以下这些情形：
做加法：
产品需求增加，页面须要增加功能，数据也就相应的要增加显示，那么REST接口也须要做增加，这种无可厚非。
做减法：
产品需求减少，页面须要减少功能，或者减少某些信息显示，那么数据就要做减法。
一种常日
由于后端接口能够知够数据须要，仅仅是在做显示的时候对数据进行了选择性显示，但接口的数据是存在冗余的，这种情形一个是存在数据透露风险，其余便是数据量过大时造成网络流量过大，页面加载缓慢，用户流量费白白花费，用户体验就会低落。
其余一种做法便是奉告后端，要么开拓新的接口，要么，修正旧接口，删掉冗余字段。
但一样平常来说，开拓新接口每每是后端开拓职员会选择的方案，由于这个方案对现有系统的影响最低，不会有额外的风险。
修正旧接口删除冗余数据的方案每每开拓职员不会选择，这是为什么呢？
这就涉及到了系统的稳定性问题了，旧接口每每不止是一个地方在用，很有可能很多页面、设置不同客户端、不同做事都调用了这个接口获取数据，不做详细的调查，是不可能知道到底旧接口被调用了多少次，一旦改动旧接口，涉及范围可能非常大，每每会引起其他地方涌现崩溃。改动旧接口本钱太高，以是每每不会被采纳。
同时做加减法：
既有加法，又有减法，实在这种就跟新需求没啥差异，前端须要重做页面，后端须要新写接口知足前端须要，但是旧接口还是不能胆大妄为（除非确定只有这一处调用才可以删除）。
每每这个时候，其实用到的数据大多都是来自于同一个DO或者DTO，不过是在REST接口组装数据时，用不同的VO来封装不同字段，或者，利用同样的VO，组装数据时做删减。
看到这些问题是不是以为令人头大？
以是需求频繁改动是万恶之源，当产品小哥哥改动需求时，程序员小哥哥可能正提着铁锹赶来......
那么有没有一种方案或者框架，可以使得在用到同一个领域模型（DO或者DTO）的数据时，前端对付这个模型的数据字段需求的改动，后端可以根据前真个改动和须要，自动适配，自动组装须要的字段，返回给前端呢？如果能这样做的话，那么后端程序猿小哥可能要愉快去世了，前端妹子也不用那么苦口婆心地奉劝后端小哥哥了。
以是GraphQL隆重出世了！
那么问题来了！
Part 1 What is GraphQL
GraphQL简介GraphQL是一种新的API标准，它供应了一种比REST更有效、更强大和更灵巧的替代方案。它是由Facebook开拓并开源的，现在由来自天下各地的公司和个人组成的大型社区掩护。GraphQL实质上是一种基于api的查询措辞，现在大多数运用程序都须要从做事器中获取数据，这些数据存储可能存储在数据库中，API的职责是供应与运用程序需求相匹配的存储数据的接口。它是数据库无关的，而且可以在利用API的任何环境中有效利用，我们可以理解为GraphQL是基于API之上的一层封装，目的是为了更好，更灵巧的适用于业务的需求变革。大略的来说，它
它的事情模式是这样子的：
GraphQL 比拟 REST API 有什么好处？REST API 的接口灵巧性差、接口操作流程繁琐，GraphQL 的声明式数据获取，使得接口数据精确返回，数据查询流程简洁，照顾了客户真个灵巧性。
客户端拓展功能时要不断编写新接口（依赖于做事端），GraphQL 中一个做事仅暴露一个 GraphQL 层，肃清了做事器对数据格式的硬性规定，客户端按必要求数据，可进行单独掩护和改进。
REST API 基于HTTP协议，不能灵巧选择网络协议，而传输层无关、数据库技能无关使得 GraphQL 有更加灵巧的技能栈选择，能够实现在网络协议层面优化运用。
举个经典的例子：前端向后端要求一个book工具的数据及其作者信息。
我用动图来分别演示下REST和GraphQL是怎么样的一个过程。
先看REST API的做法：
REST API获取数据
再来看GraphQL是怎么做的：
GraphQL获取数据
可以看出个中的差异：
与REST多个endpoint不同，每一个的 GraphQL 做事实在对外只供应了一个用于调用内部接口的端点，所有的要求都访问这个暴露出来的唯一端点。Endpoints比拟
REST API's Endpoints
GraphQL 实际年夜将多个 HTTP 要求聚合成了一个要求，将多个 restful 要求的资源变成了一个从根资源 POST 访问其他资源的 Comment 和 Author 的图，多个要求变成了一个要求的不同字段，从原有的分散式要求变成了集中式的要求，因此GraphQL又可以被算作是图数据库的形式。图数据库模式的数据查询
那我们已经能看到GraphQL的前辈性，接下来看看它是怎么做的。
GraphQL 思考模式利用GraphQL接口设计获取数据须要三步：
GraphQL获取数据三步骤
首先要设计数据模型，用来描述数据工具，它的浸染可以看做是VO，用于奉告GraphQL如何来描述定义的数据，为下一步查询返回做准备；前端利用模式查询措辞（Schema）来描述须要要求的数据工具类型和详细须要的字段（称之为声明式数据获取）；后端GraphQL通过前端传过来的要求，根据须要，自动组装数据字段，返回给前端。GraphQL的这种思考模式是不是完美办理了之前碰着的问题呢？！
总结它的好处：
在它的设计思想中，GraphQL 以图的形式将全体 Web 做事中的资源展示出来，客户端可以按照其需求自行调用，类似添加字段的需求实在就不再须要后端多次修正了。
创建GraphQL做事器的终极目标是：
许可查询通过图和节点的形式去获取数据。
GraphQL实行逻辑有人会问：
利用了GraphQL就要完备抛弃REST了吗？GraphQL须要直接对接数据库吗？利用GraphQL须要对现有的后端做事进行大刀阔斧的修正吗？答案是：NO！
不须要！
它完备可以以一种不侵入的办法来支配，将它作为前后真个中间做事，也便是，现在开始逐渐盛行的 前端 —— 中端 —— 后端 的三层构造模式来支配！
那就来看一下这样的支配模式图：
GraphQL实行逻辑
也便是说，完备可以搭建一个GraphQL做事器，专门来处理前端要求，并处理后端做事获取的数据，重新进行组装、筛选、过滤，将完美符合前端须要的数据返回。
新的开拓需求可以直接就利用GraphQL做事来获取数据了，以前已经上线的功能无需改动，还是利用原有要求调用REST接口的办法，最低程度的降落改换GraphQL带来的技能本钱问题！
如果没有那么多成本来支撑改造，那么就不须要改造！
只有当原有需求发生变革，须要对原功能进行修正时，就可以换成GraphQL了。
GraphQL运用的基本架构下图是一个 GraphQL 运用的基本架构，个中客户端只和 GraphQL 层进行 API 交互，而 GraphQL 层再今后接入各种数据源。这样一来，只假如数据源有的数据， GraphQL 层都可以让客户端按需获取，不必专门再去定接口了。
GraphQL运用基本架构
一个GraphQL做事仅暴露一个 GraphQL Endpoint，可以按照业务来进行区分，支配多个GraphQL做事，分管不同的业务数据，这样就可以避免单做事器压力过大的问题了。
GraphQL特点总结声明式数据获取（可以对API进行查询）: 声明式的数据查询带来了接口的精确返回，做事器会按数据查询的格式返回同样构造的 JSON 数据、真正照顾了客户真个灵巧性。一个微做事仅暴露一个 GraphQL 层：一个微做事只需暴露一个GraphQL endpoint，客户端要求相应数据只通过该端点按需获取，不须要再额外定义其他接口。传输层无关、数据库技能无关：带来了更灵巧的技能栈选择，比如我们可以选择对移动设备友好的协议，将网络传输数据量最小化，实现在网络协议层面优化运用。Part 2 Schema & Type
GraphQL支持的数据操作GraphQL对数据支持的操作有：
查询（Query）：获取数据的基本查询。变更（Mutation）：支持对数据的增编削等操作。订阅（Subscription）：用于监听数据变动、并靠websocket等协议推送变动的给对方。GraphQL支持的操作
GraphQL的核心观点：图表模式（Schema）要想要设计GraphQL的数据模型，用来描述你的业务数据，那么就必须要有一套Schema语法来做支撑。
想要描述数据，就必须离不开数据类型的定义。以是GraphQL设计了一套Schema模式（可以理解为语法），个中最主要的便是数据类型的定义和支持。
那么类型（Type）便是模式（Schema）最核心的东西了。
什么是类型？
对付数据模型的抽象是通过类型（Type）来描述的，每一个类型有多少字段（Field）组成，每个字段又分别指向某个类型（Type）。这很像Java、C#中的类（Class）。GraphQL的Type大略可以分为两种，一种叫做Scalar Type(标量类型)，另一种叫做Object Type(工具类型)。那么就分别来先容下两种类型。
标量类型（Scalar Type）标量是GraphQL类型系统中最小的颗粒。类似于Java、C#中的基本类型。
个中内建标量紧张有：
StringIntFloatBooleanEnumIDScalar Type
上面的类型仅仅是GraphQL默认内置的类型，当然，为了担保最大的灵巧性，GraphQL还可以很灵巧的自行创建标量类型。
工具类型（Object Type）仅有标量类型是不能知足繁芜抽象数据模型的须要，这时候我们可以利用工具类型。
通过工具模型来构建GraphQL中关于一个数据模型的形状，同时还可以声明各个模型之间的内在关联（一对多、一对一或多对多）。
工具类型的定义可以参考下图：
工具模型引入关联关系
是不是很方便呢？我们可以像设计类图一样来设计GraphQL的工具模型。
类型润色符（Type Modifier）那么，类型系统仅仅只有类型定义是不足的，我们还须要对类型进行更广泛性的描述。
类型润色符便是用来润色类型，以达到额外的数据类型哀求掌握。
比如：
列表：[Type]非空：Type!列表非空：[Type]!非空列表，列表内容类型非空：[Type!]!在描述数据模型（模式Schema）时，就可以对字段施加限定条件。
例如定义了一个名为User的工具类型，并对其字段进行定义和施加限定条件：
User字段掌握
那么，返回数据时，像下面这种情形便是不许可的：
缺点的表示
Graphql会根据Schema Type来自动返回精确的数据：
精确的表示
其他类型除了上面的，Graphql还有一些其他类型来更好的引入面向工具的设计思想：
接口类型（Interfaces）：其他工具类型实现接口必须包含接口所有的字段，并具有相同的类型润色符，才算实现接口。比如定义了一个接口类型：
那么就可以实现该接口：
联合类型（Union Types）：联合类型和接口十分相似，但是它并不指定类型之间的任何共同字段。几个工具类型共用一个联合类型。输入类型（Input Types）：更新数据时有用，与常规工具只有关键字润色不一样，常规工具时 type 润色，输入类型是 input 润色。比如定义了一个输入类型：
前端发送变更要求时就可以利用（通过参数来指定输入的类型）：
以是，这样面向工具的设计办法，真的对后端开拓职员特殊友好！
而且前端MVVM框架盛行以来，面向工具的设计思想也越来越盛行，前端利用Graphql也会得心应手。
Part 3 GraphQL技能接入架构
Graphql 技能接入架构那么，该怎么设计来接入我们现有的系统中呢？
将Graphql做事直连数据库的办法：最简洁的配置，直接操作数据库能减少中间环节的性能花费。直连数据库的接入
集成现有做事的GraphQL层：这种配置适宜于旧做事的改造，尤其是在涉及第三方做事时、依然可以通过原有接口进行交互。集成现有做事的GraphQL层
直连数据库和集成做事的稠浊模式：前两种办法的稠浊。稠浊接入办法
可以说是非常灵巧了！
你都不用担心会给你带来任何的麻烦。
做事端实现
在做事端， GraphQL 做事器可用任何可构建 Web 做事器的措辞实现。有以下措辞的实现供参考：
C# / .NET
Clojure
Elixir
Erlang
Go
Groovy
Java
JavaScript
Julia
Kotlin
Perl
PHP
Python
R
Ruby
Rust
Scala
Swift
种类繁多，险些盛行的措辞都有支持。
客户端实现在客户端，Graphql Client目前有下面的措辞支持：
C# / .NET
Clojurescript
Elm
Flutter
Go
Java / Android
JavaScript
Julia
Swift / Objective-C iOS
Python
R
覆盖了浩瀚客户端设计措辞，而其他措辞的支持也在推进中。
Graphql的一些做事整理了下目前比较盛行的做事框架：
Apollo Engine:一个用于监视 GraphQL 后真个性能和利用的做事。Graphcool (github): 一个 BaaS（后端即做事），它为你的运用程序供应了一个 GraphQL 后端，且具有用于管理数据库和存储数据的强大的 web ui。Tipe (github): 一个 SaaS（软件即做事）内容管理系统，许可你利用强大的编辑工具创建你 的内容，并通过 GraphQL 或 REST API 从任何地方访问它。AWS AppSync：完备托管的 GraphQL 做事，包含实时订阅、离线编程和同步、企业级安全特性以及细粒度的授权掌握。Hasura：一个 BaaS（后端即做事），许可你在 Postgres 上创建数据表、定义权限并利用 GraphQL 接口查询和操作。Graphql的一些工具graphiql (npm): 一个交互式的运行于浏览器中的 GraphQL IDE。Graphql Language Service: 一个用于构建 IDE 的 GraphQL 措辞做事（诊断、自动完成等） 的接口。quicktype (github): 在 TypeScript、Swift、golang、C#、C++ 等措辞中为 GraphQL 查 询天生类型。想要获取更多关于Graphql的一些框架、工具，可以去awesome-graphql：一个神奇的社区，掩护一系列库、资源等，地址是
https://github.com/chentsulin/awesome-graphql。
想要学习更多Graphql的知识，可以去GraphQL.cn。
好了，一个入门级的Graphql先容篇就这样完结了（只管篇幅也很大哈哈）。
不知道你懂得它的事理和优点了吗？你对它感兴趣吗？看完这篇先容，有没有想动手考试测验一下呢？你会在你下一个项目中引入Graphql并利用它吗？你对Graphql还有什么迷惑的问题呢？或者你有其他问题，都可以在评论区留言或者私信我，大家一起共同磋商。
Graphql还有更多须要先容的东西，没有写出来，这仅仅是一个入门先容哈，后面我会再写一篇文章来详细先容Graphql在详细的利用方面的总结和在项目中利用的实际感想熏染，如果你也对Graphql感兴趣，可以关注我 @IT研究僧大师兄 下一次的文章先容。关注我后可以私信我，发送关键字“Graphql PPT”，获取我自己制作的Graphql PPT。
当然，如果你也和我一样，热衷于技能，热衷于科技、互联网，不妨点个关注吧，我会持续分享干货知识、履历和不雅观点总结。
