我们准备在网关中支持GrahpQL了

简单介绍下GraphQL：

GraphQL是一种基于api的查询语言，它提供了一种更高效、强大和灵活的数据提供方式。它是由Facebook开发和开源，目前由来自世界各地的大公司和个人维护。

据说已经在FB内部大量使用了，所以在工程界大家不用担心成为小白鼠了，但是用好相信也是个漫长的过程，需要结合自己业务特点和系统特点慢慢来。

其实一提到QL，你就可以知道他是某种DSL类似的领域语言，本身肯定存在一定的切换成本。

GraphQL在业界主要解决的对手就是Rest API，我们知道Rest API需要遵循一定的设计原则，比如：

https://localhost:8080/person 
https://localhost:8080/person/{id}

针对于具体的业务场景设计对应的endpoint。

这种使用方案带来的最大挑战在于，大前端的业态下，随着客户端需求的快速迭代，功能也越来越复杂，需要提供的接口也越来越多。如何优雅的维护接口的稳定性，设计扩展性满足将来一定的业务需求变更，一直是从事服务端接口开发工程师需要不断思考的问题。

而客户端最可怕的一点，因为代码固化到用户手机上，只要有老版本APP在使用某个接口，你后端这个接口就不能下掉，代码就需要一直在，时间久了，屋子里面堆满了脏袜子，充斥着代码的臭味道，每次都需要捏着鼻子写代码。

业务的不断发展，带来了接口维护成本，一个原因在于这里API接口的设计承担了数据表示的职责：为前端的UI/UX提供展现所需要的数据。比如APP上的个人中心页面，UI/UX需要展现昵称，头像，性别的数据，这是一个来自UI/UX对数据接口返回的需求。

有没有可能将来自UI/UX的需求尽量控制在UI/UX的实现端（客户端）从而减少UI展示层的逻辑变化的复杂度对后端接口的影响呢？

答案是使用GraphQL。

Facebook在接入层添加了一层GraphQL的查询语言。

使用GraphQL，我们可以按需获取数据。同时由于QL语言可以迭代，这样很多需求可以基于原有接口上进行升级，这种升级体现在修改QL上，而不是需要后端修改追加新需求参数。

所以GraphQL专注于在客户端进行数据建模。

Rest VS GraphQL：

GraphQL可以通过一个统一的HTTP API接口来传递数据：

通过文本描述数据请求需求，接口返回匹配需求的数据。

如图，行1～8为客户端请求的GraphQL形式的需求描述，该请求查询id为1的作者的名字，以及要求返回其关联的id为5的一本书的标题；行10～21为对应的匹配客户端数据需求的返回。在这里我们可以看到，客户端有了表达自身数据需求的灵活性。类似的GraphQL中也定义了对数据进行修改的语法。

在项目中使用GraphQL有两种方式，一种是API方式，一种是资源文件方式。

我个人喜欢使用第二种，首先遵循我个人软件设计方法论中的“分离原则”，符合“分离原则”中的“配置与运行分离”。

Demo如下：

想在原有Controller上使用GraphQL，也比较简单，只需要继承GraphQLQueryResolver接口就可以了：

通过GraphQL解决原有Rest API升级不友好，维护不友好的问题之后。其实我们整个API在管理上还存在另一个挑战，就是API泛滥。

API泛滥之后，我们就很难知道哪些接口提供了哪些能力，甚至是哪些字段。常见的管理方式是类似于wiki的管理，但是wiki在哪？怎么找到又是另一个问题。

所以API文档管理不仅仅是“写死”在文档上，而是如何让API“动”起来。

什么意思呢？就是说一个API落地之后，是否可以按照后续迭代的过程不断去进行相应的API维护，让整个生命周期“动”起来。

关于如何处理这个“动”，其实有两种方案，一种是靠人，一种是靠工具。

对于我这种信奉工具与自动化的人来说，肯定是靠工具了。

那么如何通过工具将API接口“动”起来呢？

方式就有很多了，比如编译期，部署期，流量期等不同生命周期进行控制。

其实再往后想一想，客户端哪个View联动哪个API这个应该怎么搞呢？

当然是主动下发+被动上报了，这样我们可以将API管理进行流量闭环，从而完成对于API的生命周期管理，以及实现API“动”起来的目标了。