前言

随着多终端、多平台、多业务形态、多技术选型等各方面的发展，前后端的数据交互，日益复杂。

同一份数据，可能以多种不同的形态和结构，在多种场景下被消费。

在理想情况下，这些复杂性可以全部由后端承担。前端只管从后端接口里，拿到已然整合完善的数据。

然而，不管是因为后端的领域模型，还是因为微服务架构。作为前端，我们感受到的是，后端提供的接口，越发不够前端友好。我们必须自行组合多个后端接口，才能获取到完整的数据结构。

面向领域模型的后端需求，跟面向页面呈现的前端需求，出现了不可调和的矛盾。

我们曾经试图用RESTful风格的无线API聚合层来解决问题。这一层完全由后端工程师开发和迭代（前端作为下游等待聚合接口的契约），他们既要理解背后对接的微服务体系，又要理解每个前端页面的展现需求。

随着页面数量的增加，接口调用方越来越多，后端API聚合层的逻辑越来越重。聚合层自身成为新的瓶颈所在。实际情况是，作为中间层的后端，既难以充分对接背后的微服务体系，也难以充分理解前端的页面展现需求。

他们的整体定位很尴尬，代码里既有UI展示相关的话术等信息，又有大量接口相关的业务逻辑处理。每次发布迭代，都要跟上下游做大量的沟通和联调。

我们最终意识到，让最了解页面数据逻辑的前端接管中间层，让后端回到他们擅长的领域模型，可能是更好的做法。可以减少大家沟通成本，提高前后端的专业化程度，降低联调压力，加快彼此的开发效率。

在这种背景下，我们最后选择使用Node.js搭建专门服务于前端页面呈现的后端，亦即Backend-For-Frontend，简称BFF。

我们面临了很多不同的技术选型，主要围绕在权衡RESTfulAPI和GraphQL。

正如标题所示，我们最终选用的是GraphQLasBFF。

本文将介绍我们对GraphQL所作的考察、探索、权衡、技术选型与设计等多方面的内容，希望能给大家带来一些启发。

一、GraphQL模式出现的必然性

面向前端页面的数据聚合层，其接口很容易在迭代过程中，变得愈加复杂；最终发展成一个超级接口。

它有很多调用方，各种不同的调用场景，甚至多个不同版本的接口并存，同时提供数据服务。

所有这些复杂性，都会反映到接口参数上。

接口调用的场景越多，它对接口参数结构的表达能力，要求越高。如果只有一个boolean类型的参数，只能满足true|false两种场景罢了。

以产品详情接口为例，一种很自然的请求参数结构如下：

里面包含ChannelCode渠道信息，IsOp身份信息，MarketingInfo营销相关的信息，PlatformId平台信息，QueryNode查询的节点信息，以及Version版本信息。最核心的参数ProductId，被大量场景相关的参数所围绕。

审视一下QueryNode参数，很容易可以发现，它正是GraphQL的雏形。只不过它用的是更复杂的JSON来描述查询字段，而GraphQL用更简洁的查询语句，完成同样的目的。

并且，QueryNode参数，只支持一个层级的字段筛选；而GraphQL则支持多层级的筛选。

GraphQL可以看作是QueryNode这种形式的参数设计的专业化。相比用JSON来描述查询结果，GraphQL设计了一个更完整的DSL，把字段、结构、参数等，都整合到一起。

仿照格林斯潘第十定律：

任何C或Fortran程序复杂到一定程度之后，都会包含一个临时开发的、不合规范的、充满程序错误的、运行速度很慢的、只有一半功能的CommonLisp实现。
https://zh.wikipedia.org/wiki/格林斯潘第十定律

或许可以说：

任何接口设计复杂到一定程度后，都会包含一个临时开发的、不合规范的、只有一半功能的GraphQL实现。

从SearchParams，FormData到JSON，再到GraphQL查询语句，我们看到不断有新的数据通讯方式出现，满足不同的场景和复杂度的要求。

站在这个层面上看，GraphQL模式的出现，有一定的必然性。

二、GraphQL语言设计中的必然性

作为一个查询相关的DSL，GraphQL的语言设计，也不是随意的。

我们可以做一个思想实验。

假设你是一名架构师，你接到一项任务，设计一门前端友好的查询语言。要求：

1）查询语法跟查询结果相近

2）能精确查询想要的字段

3）能合并多个请求到一个查询语句

4）无接口版本管理问题

5）代码即文档

我们知道查询结果是JSON数据格式。而JSON是一个key-valuepair风格的数据表示，因此可以从结果倒推出查询语句。

上图是一个查询结果。很显然，它的查询语句不可能包含value部分。我们删去value后，它变成下面这样。

查询语句跟查询结果拥有相同的key及其层次结构关系。这是我们想要的。

我们可以再进一步，将冗余的双引号，逗号等部分删掉。

我们得到了一个精简的写法，它已经是一段合法的GraphQL查询语句了。

其中的设计思路和过程是如此简单直接，很难想象还有别的方案比目前这个更满足要求。

当然，只有字段和层级，并不足够。符合这种结构的数据太多了，不可能把整个数据库都查询出来。我们还需要设计参数传递的方式，以便能缩小数据范围。

上图是一个自然而然的做法。用括号表示函数调用，里面可以添加参数，可谓经典的设计。

它跟ES2015里的（MethodDefinitionsShorthand）也高度相似。如下所示：

前面演示的GraphQL参数写法，参数值用的是字面量userId:123。这不是一个特别安全的做法，开发者会在代码里，用拼接字符串的方式将字面量值注入到查询语句，也就给了恶意攻击者注入代码的机会。

我们需要设计一个参数变量语法，明确参数位置和数量。

我们可以选用$xxx这种常见的标记方法，它被很多语言采用来表示变量。沿用这种风格，可以大大减少开发者的学习成本。

前后端通讯的另一个痛点是，命名。前端经常吐槽后端的字段名过于冗长，或者不知所云，或者拼写错误，或者不符合前端表述习惯。最常见的情况是，后端字段名以大写字母开头，而前端习惯Class或者Component是大写字母开头，实例和数据，则以小写字母开头。

我们期望有机会进行字段名调整。

别名映射（Alias）语法，正是为了这个目的而出现的。

上面这种别名映射的语法，在其它语言里也很常见。如果不这样写，顶多就是变成：

uidasUid或者uid=Uid这类做法，差别不大。我认为选用冒号更佳，它跟ES2015的解构语法很接近。

至此，我们拥有了key层级结构，参数传递，变量写法，别名映射等语法，可以编写足够复杂的查询语句了。不过，还有几个小欠缺。

比如对字段的条件表达。假设有两次查询，它们唯一的差别就是，一个有A字段，另一个没有A字段，其它字段及其结构都是相同的。为了这么小的差别，前端难道要编写两个查询语句？

这显然不现实，我们需要设计一个语法描述和解决这个问题。

它就是——指令（Directive）。

指令，可以对字段做一些额外描述，比如

@include，是否包含该字段；

@skip，是否不包含该字段；

@deprecate，是否废弃该字段；

除了上述默认指令外，我们还可以支持自定义指令等功能。

指令的语法设计，在其它语言里也可以找到借鉴目标。Java，Phthon以及ESNext都用了@符号表示注解、装饰器等特性。

有了指令，我们可以把两个高度相似的查询语句，合并到一起，然后通过条件参数来切换。这是一个不错的做法。不过，指令是跟着单个字段走的，它不能解决多字段的问题。

比如，字段A和字段B，拥有相同的总体结构，仅仅只有1个字段名的差异。前端并不想编写一样的key值重复多次。

这意味着，我们需要设计一个片段语法（Fragment）。

如上所示，用fragment声明一个片段，然后用三个点表示将片段在某个对象字段里展开。我们可以只编写一次公共结构，然后轻易地在多个对象字段里复用。

这种设计也是一个经典做法，跟JavaScript里的SpreadProperties很相近。

至此，我们得到了一个相对完整的，对前端友好的查询语言设计。它几乎就是GraphQL当前的形态。

如你所见，GraphQL的查询语言设计，借鉴了主流开发语言里的众多成熟设计。使得任何拥有丰富的编程经验的开发者，很容易上手GraphQL。

按照同样的要求，重新来一遍，大概率得到跟当前形态高度接近的设计。这是我理解的GraphQL语言设计里包含的必然性。

三、GraphQL的组成与链路

查询语法，是GraphQL面向前端，或者说面向数据消费端的部分。

除此之外，GraphQL还提供了面向后端，或者说面向数据提供方的部分。它就是基于GraphQL的TypeSystem构建的Schema。

一个GraphQL服务和查询的链路，大致如下：

首先，服务端编写数据类型，构建一个数据结构之间的关联网络。其中Query对象是数据消费的入口。所有查询，都是对Query对象下的字段的查询。可以把Query下的字段，理解为一个个RESTfulAPI。比如上图中的，Query.post和Query.author，相当于/post和/author接口。

GraphQLSchema描述了数据的类型与结构，但它只是形状（Shape），它不包含真正的数据。我们需要编写Resolver函数，在里面去获取真正的数据。

Resolver的简单形式如下

每个Query对象下的字段，都有一个取值函数，它能获取到前端传递过来的query查询语句里包含的参数，然后以任意方式获取数据。Resolver函数可以是异步的。

有了Resolver和Schema，我们既定义了数据的形状，也定义了数据的获取方式。可以构建一个完整的GraphQL服务。

但它们只是类型定义和函数定义，如果没有调用函数，就不会产生真正的数据交互。

前端传递的query查询语句，正是触发Resolver调用的源头。

如上所示，我们发起了查询，传递了参数。GraphQL会解析我们的查询语句，然后跟Schema进行数据形状的验证，确保我们查询的结构是存在的，参数是足够的，类型是一致的。任何环节出现问题，都将返回错误信息。

数据形状验证通过后，GraphQL将会根据query语句包含的字段结构，一一触发对应的Resolver函数，获取查询结果。也就是说，如果前端没有查询某个字段，就不会触发该字段对应的Resolver函数，也就不会产生对数据的获取行为。

此外，如果Resolver返回的数据，大于Schema里描绘的结构；那么多出来的部分将被忽略，不会传递给前端。这是一个合理的设计。我们可以通过控制Schema，来控制前端的数据访问权限，防止意外的将用户账号和密码泄露出去。

正是如此，GraphQL服务能实现按需获取数据，精确传递数据。

四、澄清关于GraphQL的几个迷思

有相当多的开发者，对GraphQL有各种各样的误解。在这里挑选几个重要的例子，加以澄清，帮助大家更全面的认识GraphQL。

4.1 GraphQL不一定要操作数据库

有一些开发者认为GraphQL需要操作数据库，因此实现起来，几乎等于要推翻当前后端的所有架构。这是一个重大误解。

GraphQL不仅可以不操作数据库，它甚至可以不从其它地方获取数据，而直接写死数据在Resolver函数里。查看graphql.js的官方文档，我们轻易可以找到案例：

上图定义了一个schema，只有一个类型为String的hello字段，它的resolver函数里，无视所有参数，直接return一个helloworld字符串。

可以看到，GraphQL只是关于schema和resolver的一一对应和调用，它并未对数据的获取方式和来源等做任何假设。

4.2 GraphQL跟RESTfulAPI不是对立的

在网络上，有相当多的GraphQL文章，将它跟RESTfulAPI对立起来，仿佛要么全盘GraphQL，要么全盘RESTfulAPI。这也是一个重大误解。

GraphQL和RESTfulAPI不仅不对立，还是互相协作的关系。

在前面关于Resolver函数的图片中，我们看到，可以在GraphQLSchema的Resolver函数里，调用RESTfulAPI去获取数据。

当然，也可以调用RPC或者ORM等方式，从别的数据接口或者数据库里获取数据。

因此，实现一个GraphQL服务，并不需要挑战当前整个后端体系。它具有高度灵活的适配能力，可以低侵入性的嵌入当前系统中。

4.3 GraphQL不一定是一个后端服务

尽管绝大多数GraphQL，都以server的形式存在。但是，GraphQL作为一门语言，它并没有限制在后端场景。

上图还是前面展示过的graphql.js的官方文档，最下面一行，就是一个普通的函数调用，它发起了一次graphql查询，其response结果如下：

这段代码，不只能在node.js里运行，在浏览器里也可以运行（可访问：https://codesandbox.io/s/hidden-water-zfq2t查看运行结果）

因此，我们完全可以将GraphQL用在纯前端，去实现StateManagement状态管理。Relay等框架，即包含了用在前端的graphql。

4.4 GraphQL不一定需要 Schema

这是一个有趣的事实，GraphQL语言设计里的两个组成部分：

1）数据提供方编写GraphQLSchema；

2）数据消费方编写GraphQLQuery；

这种组合，是官方提供的最佳实践。但它并不是一个实践意义上的最低配置。

GraphQLTypeSystem是一个静态的类型系统。我们可以称之为静态类型GraphQL。此外，社区还有一种动态类型的GraphQL实践。

graphql-anywhere:RunaGraphQLqueryanywhere,withoutaGraphQLserveroraschema.
https://github.com/apollographql/apollo-client/tree/master/packages/graphql-anywhere

它跟静态类型的GraphQL差别在于，没有了基于Schema的数据形状验证阶段，而是直接无脑地根据query查询语句里的字段，去触发Resolver函数。

它也不管Resolver函数返回的数据类型对不对，获取到什么，就是什么。一个字段，不必先定义好，才能被前端消费，它可以动态的计算出来。

在某些场景下，动态类型的GraphQL有一定的便利性。不过，它同时丧失了GraphQL的部分精髓，这块后面将会详细描述。

值得一提的是，不管是静态类型的GraphQL还是动态类型的GraphQL，都是既可以运行在服务端，也可以运行在前端。

4.5 GraphQL不一定返回JSON 数据格式

这是另一个有趣的事实。最初我们演示了，如何基于JSON数据结果，反推出GraphQL查询语法的设计。而现在，我们却说GraphQL可以不返回JSON数据格式。

没错。当一个新事物出现之后，随着它的不断发展，它可以脱离其初衷，衍生出不同的形态。

上图还是来自graphql-anywhere里的例子。

在这里，它实现了一个gqlToReact的Resolver，可以把一个graphql查询转换为ReactElement结构。

不只是动态类型的GraphQL有这个能力，静态类型的GraphQL也有可能实现一样的效果。

不过这种做法，目前仅仅停留在能力演示阶段。其妙用还有待社区去挖掘和探索。

五、GraphQL的几种使用模式

到目前为止，我们见识到了GraphQL的高自由度和灵活性。在搭建GraphQLServer时，也可以根据实际需求和场景，采用不同的模式。

5.1 RESTful-Like模式

这个模式就是简单粗暴的把RESTfulAPI服务，替换成GraphQL实现。之前有多少RESTful服务，重构后就有多少GraphQL服务。它是一个简单的一对一关系。

默认情况下，面向两个GraphQL服务发起的查询是两次请求，而不是一次。举个例子：

前端需要产品数据时，从之前调用产品相关的RESTfulAPI，变成查询产品相关的GraphQL。不过，需要订单相关的数据时，可能要查询另一个GraphQL服务。

有一些公司拿GraphQL小试牛刀时，采取了这个做法；将GraphQL用在特定服务里。

不过，这种模式难以发挥GraphQL合并请求和关联请求的能力。只是起到了按需查询，精确查询字段的作用，价值有限。

因此，他们在实践后，发现收效甚微；认为GraphQL不过如此，还不如RESTfulAPI架构简单和成熟。

其实这是一种选型上的失误。

5.2 GraphQLasanAPIGateway模式

在这个模式里，GraphQL接管了前端的一整块数据查询需求。

前端不再直接调用具体的RESTful等接口，而是通过GraphQL去间接获取产品、订单、搜索等数据。

在GraphQL这个中间层里，我们将各个微服务，按照它们的数据关联，整合成一个基于GraphQLSchema的数据关系网络。前端可以通过GraphQL查询语句，同时发起对多个微服务的数据的获取、筛选、裁剪等行为。

值得一提的是，作为APIGateway的GraphQL服务，可以在其Resolver内，向前面提到的RESTful-like的GraphQL发起查询请求。

如此，既避免了前端需要一对多的问题，也解决了APIGatewayGraphQL需要请求RESTful全量数据接口的内部冗余问题。让服务到服务之间的数据调用，也可以做到更精确。

GraphQL服务是一个对数据消费方友好的模式。而数据消费方，既可以是前端，也可以是其它服务。

当数据消费方是其它服务时，通过GraphQL查询语句，彼此之间可以更精确获取数据，避免冗余的数据传输和接口调用。

当数据消费方是前端时，由于前端需要跟多个数据提供方打交道，如果每个数据提供方都是单独的GraphQL，那并不能得到本质上的改善。此时若有一个Gateway角色的GraphQL，可以真正减少前端调用的复杂度。

5.2.1 两类GraphQLAPIGateway服务

同样是APIGateway角色的GraphQL服务，在实现方式上也有不同的分类。

1）包含大量真实的数据操作和处理的GraphQL

2）转发数据请求，聚合数据结果的GraphQL

第一类，是传统意义上的后端服务；第二类，则是我们今天的重点，GraphQLasBFF。

这两类GraphQL服务的要求是不同的，前者可能包含大量CPU密集的计算，而后者总体而言主要是NetworkI/O相关的行为。

许多公司并不提倡使用Node.js构建第一种服务，不管是构建RESTful还是GraphQL。我们也一样。

因此，后面我们讨论的GraphQL，如果没有特别声明，都可以理解为上面所说的第二种类型。

5.3GraphQLasaBackendFramework

在澄清关于GraphQL的迷思时，我们指出，GraphQL可以不作为Server。

这意味着，一个包含GraphQL实现的Server，不一定通过GraphQL查询语句进行前后端数据交互，它可以继续沿用RESTfulAPI风格。

也就是说，我们可以把GraphQL当作一个服务端开发框架，然后在RESTful的各个接口里，发起graphql查询。

不管是前端还是其它后端服务，都不必知道GraphQL的存在。前端的调用方式，还是RESTfulAPI，在RESTful服务内部，它自己向自己发起了GraphQL查询。

那么，这个模式有什么好处跟价值？

设想一下，你用RESTfulAPI风格实现BFF。由于PC端和移动端的场景不同，它们对同一份数据的消费方式差异很大。

在PC端，它可以一次请求全量数据。

在移动端，因为它屏幕小，它要分多次去请求数据。首屏一次，非首屏一次，滚动按需加载N次，多个2级页面里M次。

我们要么实现一个超级接口，根据请求参数适配不同场景（即实现一个半吊子的GraphQL）；要么实现多个功能相似，但又不同的RESTful接口。

其中的差异太大了，所以很多公司索性就把BFF分成，PC-BFF和Mobile-BFF两个BFF服务。

我们可以把PC-BFF和Mobile-BFF整合成一个GraphQL-BFF服务。即便前后端不通过GraphQL查询语句进行交互，我们也可以在各个接口里，编写相对简单的查询语句，代替更高成本的接口实现。

也即是说，使用GraphQL搭建BFF，如果出现前后端分工、沟通等方面的矛盾。我们可以将GraphQL服务降级为RESTful服务，无非就是把需要前端编写的查询语句，写死在后端接口里面罢了。

如果实现的是RESTful服务，要转换成GraphQL服务，就没有那么简单了。

有了这种优雅降级的能力，我们可以更加放心大胆的推动GraphQL-BFF方案。

六、GraphQL精髓

理解GraphQL的精髓所在，可以帮助我们更正确地实践GraphQL。

首先来想一下，GraphQL为什么要叫GraphQL，其中的Graph体现在什么地方？

GraphQL的查询语句，看起来是JSON写法的一种简化。而JSON是一个Tree树形数据结构。为什么不叫TreeQL，而是GraphQL呢？

6.1 TreeVSGraph

一个重要的前置知识是，什么是Tree，什么是Graph，它们有什么关系？

下图是一个Tree的结构示意图。

Tree有且只有一个Root节点，并且对于每个非Root节点，有且只有一个父节点；它们组成了一个层次结构。其中任意两个节点，有且只有一条连接路径；没有循环，也没有递归引用。

下图是一个Graph的结构示意图。

而Graph里的节点之间，可能存在不只一种连接路径，可能存在循环，可能存在递归引用，可能没有Root节点。它们组成了一个网络结构。

我们可以把Graph这种网络结构，通过裁剪连接路径，把它压缩成任意节点只有唯一连接路径的简化形态。如此网络结构退化成层次结构，它变成了Tree。

也就是说，Graph是比Tree更复杂的数据结构，后者是它的简化形式。拥有Graph，我们可以按照不同的裁剪方式，衍生出不同的Tree。而Tree里包含的信息，如果不增加其它额外数据，不足以构建足够复杂的Graph结构。

6.2 GraphQL里的Graph结构

在GraphQL里，承担构建网络结构的，并非GraphQL查询语句，而是基于GraphQLTypeSystem构建的Schema。

上图是一个GraphQLSchema，定义了A,B,C,D和E五种数据类型，它们分别挂载到入口类型Query里的a,b,c,d和e字段里。

A,B,C,D,E里面，包含着递归的结构。A里面包含B和C，B里面包含C和D，D里面包含E，E里面又包含A，又回到了A。

这是一个复杂的关系网络。要构建递归关联，并不需要这么复杂。直接A里包含B，和B里包含A也行，此处是一个演示。

有了这个基于数据类型的Graph关系网络，我们可以实现从Graph中派生出JSONTree的能力。

上图是一个GraphQL的查询语句，它是一个包含很多key的层次结构，亦即一个Tree。

它从根节点里取a字段，然后向下分层，找到了e。而e节点里也包含一个跟根节点同类型的a字段，因此它可以继续向下分层，重来一遍，又到了e节点，此时它只取了data字段，查询中止。

我编写了一个简单的Resolver函数，用来演示查询结果。

它很简单。Query里返回跟字段名一样的字母，任何子节点的数据，都是拼接父节点的字母串。如此我们可以从查询结果看出数据流动的层次。

查询结果如下：

第一个e节点的data字段里，拿到了父节点里的data数据，其父节点的data数据又是通过它的父节点里获取的，因此有一个数据链条。

而第二个e节点同理，它有两段链条。

只要不编写后续字段，我们可以停留在任意节点的data字段里。

也就是说，我们用作为Tree的Query语句，去裁剪了作为Graph的Schema数据关联网络，得到了我们想要的JSON结构。

通过这个角度，我们可以理解为什么GraphQL不允许Query语句停留在Object类型，一定要明确的写出对象内部的字段，直到所有LeafNode都是Scalar类型。

这不仅仅是一个所谓的最佳实践，这也是Graph本身的特征。对象节点里，可能通过循环或者递归关系，拓展出无限大的数据结构。Query语句必须写清楚，才能帮助GraphQL去裁剪掉不必要的数据关联路径。

6.3 Graph网络结构的实际价值

前面的A,B,C,D,E案例，并不能直观的让大家感受到，Graph网络结构的实际价值。它看起来像一个连线游戏。

放到Facebook的社交网络场景下，其必要性和价值就凸显了。

假设我们要一次性获取用户的好友的好友的好友的好友的好友，基于RESTfulAPI我们有什么特别好的方法吗？很难说。

而Graph这种递归关联的结构，实现这种查询轻而易举。

我们定义了一个User类型，挂到Query入口上的user字段里。User类型的friends字段又是一个User类型的列表。这样就构建了一个递归关联。

getFriends查询语句，可以不断地从任意用户开始，关联其friends，得到friends数组结果。任意一个friend也是User，它也有自己的friends。查询语句在最外层的friends停了下来，它只查询了id和name字段。

看到这里，另一个经典的关于GraphQL的误解出现了：只有像Facebook，Twitter这类社交关系网络，才适合GraphQL，而我们的场景下，GraphQL并不适用。

其实不然，社交关系网络里使用GraphQL特别有效，不意味着其它场景下，GraphQL不能带来收益。

设想一个电商平台的场景，它有用户、产品和订单这组铁三角，其它库存、价格，优惠券，收藏等先不提。在最简单的场景下，GraphQL依然可以发挥作用。

我们构建了User，Product和Order三个类型，它们彼此之间有字段上的递归关联关系，是一个Graph结构。在Query入口类型上，分别有user,product和order三个字段。

据此，我们可以实现从user,product和order任意维度出发，通过它们的关联关系，实现丰富而灵活的查询。

比如，查看用户的所有订单及其跟订单相关的产品，Query语句如下：

我们查询了id为123的用户，他的名字和订单列表，对于每个订单，我们获取该订单的创建时间，购买价格和关联产品，对于订单关联的产品，我们获取了产品id，产品标题，产品描述和产品价格。

当我们的后端人员组织架构是按照领域模型来划分时，用户，产品和订单，通常是3个团队，他们各自提供领域相关的接口。通过GraphQL我们可以很容易将它们整合到一起。

再比如，查看一个产品下的所有订单及其关联用户，Query语句如下：

我们查询了id为123的产品，它的产品标题，产品描述和价格，以及关联的订单。对于每个关联订单，我们查询了订单的创建时间，购买价格以及下订单的用户，对于下订单的用户，我们查询了他的用户id和名称。

如你所见，只要构建出了Graph结构的数据网络，它不像Tree那样有唯一的Root节点。从任意入口出发，它都可以通过关联路径，不断的衍生出数据，得到JSON结果。

我们不必疲于编写面向产品详情页的接口，面向订单详情页的接口，面向用户信息的接口。我们编写了一个数据关系网络，就足以适配不同的场景。

此处演示的，只是用户，产品和订单这三个资源的关系网络，已经可以看出GraphQL的适用性。在实际场景中，我们能搭建出更复杂的数据网络，它具备更强大的数据表达能力，可以给我们的业务带来更多收益。

七、我们的GraphQL-BFF实践模式

在掌握上述关于GraphQL的纲领知识后，我们来看一下在实践中，GraphQL-BFF的一种实际做法。

首先是技术选型，我们主要采用了如下技术栈。

开发语言选用了TypeScript，跑在Node.jsv10.x版本上，服务端框架是Koav2.x版本，使用apollo-server-koa模块去运行GraphQL服务。

Apollo-GraphQL是Node.js社区里，比较知名和成熟的GraphQL框架。做了很多的细节工作，也有一些相对前沿的探索，比如ApolloFederation架构等。

不过，有两点值得一提：

1）Apollo-GraphQL属于GraphQL社区的一部分，而非Facebook官方的GraphQL开发团队。Apollo-GraphQL在官方GraphQL的基础上进行了带有他们自身理念特点的封装和设计。像ApolloFederation这类目前看来比较激进的方案，即使是GraphQL官方的开发人员，对此也持保留态度。

2）Apollo-GraphQL的重心是前文所说的第一类APIGateway角色的GraphQL服务，本文探讨的是第二类。因此，Apollo-GraphQL里有很多功能对我们来说没必要，有一些功能的使用方式，跟我们的场景也不契合。

我们主要使用的是Apollo-GraphQL的graphql-tools和apollo-server-koa两个模块，并在此基础上，进行了符合我们场景的设计和改编。

7.1 我们的GraphQL-BFF架构设计

GraphQL-BFF的核心思路是，将多个services整合成一个中心化datagraph。

每个service的数据结构契约，都放入了一个大而全的GraphQLSchema里；如果不做任何模块化和解耦，开发体验将会非常糟糕。每个团队成员，都去修改同一份Schema文件。

这明显是不合理的。GraphQL-BFF的开发模式，应该跟service的领域模型，有一一对应的关系。然后通过某种形式，多个services自然整合到一起。

因此，我们设计了GraphQL-Service的概念。

7.1.1 GraphQL-Service

GraphQL-Service是一个由Schema+Resolver两部分组成的JS模块，它对应基于领域模型的后端的某个Servcie。每个GraphQL-Service应该可以按照模块化的方式编写，跟其它GraphQL-Service组合起来后，构建出更大的GraphQL-Server。

GraphQL-Service通过GraphQL的TypeExtensions构建数据关联关系。

如上所示，我们的UserService里面，只涉及到了User相关的类型处理。它定义了自己的基本字段，id和name。通过extendtype定义了它在Order和Product数据里的关联字段，以及定义在Query里的入口字段。

从UserSchema里我们可以看到，User有两类查询路径。

1）通过根节点Query以传递参数的方式，获取到User信息。

2）通过Product或Order节点，以数据关联的方式，获取到User信息。

上图是OrderService的Schema，它也只涉及了Order相关的类型逻辑。同样是通过extendtype定义了在User和Product里的关联字段，以及定义了在根节点Query里的入口字段。

Order数据跟User一样，有两种消费路径。一种通过Query节点，另一种是通过数据关联节点。

前面我们演示User,Order和Product铁三角关系时，是在同一个Schema里编写它们的关联。我们把多个GraphQL-Service的Schema整合到一起后，可以生成同样的结果：

上图不是我们手动编写的，而是merge多个GraphQL-Service的Schema后生成的结果。可以看出来，跟之前手写的版本，总体上是一样的。

有了解耦的Schema并不足够，它只定义了数据类型及其关联。我们需要Resolver去定义数据的具体获取方式，Resolver也需要解耦。

7.1.2 GraphQL-Resolver

不管是在官方的GraphQL文档里，还是Apollo-GraphQL的文档里，Resolver都是以普通函数的形态出现。

这在简单场景下，没有什么问题。正如在简单场景下，用node.js的http.createServer就可以创建一个server。

如上，设置状态码，设置响应的Content-Type，返回内容即可。

然而，在更复杂的真实项目中，我们实际上需要express、koa等服务端框架，用中间件的模式编写我们的服务端处理逻辑，由框架将它们整合为一个requestListener函数，注册到http.createServer(requestListener)里。

在GraphQLServer里，虽然endpoint只有/graphql一个，但不代表它只需要一组Koa中间件。

正如一开始我们指出的，每个超级接口里都包含一半功能的GraphQL实现。GraphQL是往超级接口的方向更进一步，不能简单地以普通接口的眼光去看待它。

在Query下的每个字段，都可能对应1到多个内部服务的API的调用和处理。只用普通函数构成的resolverMap，不足以充分表达其中的逻辑复杂度。

不管是用endpoint来表示资源，还是用GraphQLField字段来表示资源，它们只是外在形式略有不同，不会改变业务逻辑的复杂度。

因此，采用比普通函数具有更好的表达能力的中间件，组合出一个个Resolver，再整合到一个ResolverMap里。可以更好的解决之前解决不了，或者很难的问题。

所谓的架构能力，体现在理解我们面对的问题的复杂度及其本质特征，并能选择和设计出合适的程序表达模型。

后面我们将演示，正确的架构，如何轻易地克服之前难以解决的问题。

7.1.3 用koa-compose组织我们的Resolver

或许很多同学并不清楚，express或koa里的中间件模式，可以脱离作为服务端框架的它们而单独使用。正如GraphQL可以单独不作为server，在任意支持JavaScript运行的地方使用一样。

我们将使用koa-compose这个npm模块，去构造我们的Resolver。

前文里提到的gql函数，接受一个Schema返回一个GraphQL-Service，每个GraphQL-Service都有一个resolve方法：

resolve方法，接受两个参数。第一个是typeName，对应GraphQL-Schema里的ObjectType的类型名称；第二个是fieldHandlers，每个handler支持中间件模式，最终它们将被koa-compose整合成一个Resolver。

以UserService为例，其Resolver写起来如下：

作为普通函数的Resolver接收的所有参数，都被整合到了ctx里面。ctx.result则是该字段的最终输出，类似于koaserver里的ctx.body。我们刻意采用了ctx.result这个不同于ctx.body的属性，明确区分我们处理的是一个接口还是一个字段。

在简单场景下，中间件模式的Resolver跟普通函数的Resolver，仅仅是参数的数量和返回值的方式不同。并不会增加大量的代码复杂度。

当我们多个字段要复用相同的逻辑时，编写成中间件，然后将handler变成数组形式即可。（在代码里我们用json模拟了数据库表，所以是同步代码，实际项目里，它可以是异步的调用接口或者查询数据库）。

上面的logger，只是一个简单案例。除此之外，我们可以编写requireLogin中间件，决定一个字段是否只对登陆用户可用。我们可以编写不同的工具型中间件，注入ctx.fetch,ctx.post,ctx.xxx等方法，以供后续中间件使用。

每个GraphQLField字段，都拥有独立的一组中间件和ctx对象，跟其他字段互相不影响。我们同时，可以把所有字段共享的中间件，放到koaserver里的中间件里。

如上图所示，绿框是endpoint，可以编写koaserver层面的middleware。而蓝框是GraphQLField字段，可以编写Resolver层面的middleware。endpoint层面的middleware对ctx的修改，会影响到后面所有字段。

也就是说，我们可以像上面那样。挂接口层面的logger，可以知道整个graphql查询的耗时。编写一个中间件，在next之前，挂载一些方法，供后续中间件使用；在next之后，拿到graphql的查询结果，进行额外的处理。

7.2 解决mock难题

GraphQL是天生mock友好的模式，因为其Schema里已经指明了所有数据的类型及其关联；很容易可以通过fakerdata之类的手段，自动根据类型生成假数据。

然而，在实践中，实现GraphQLMocking还是有不少的挑战。

如上图所示，在ApolloGraphQL里，mock看似很简单，只需要在创建服务时，设置mock为true，或者提供一个mockresolver即可。但是，一个全局的，跟着服务创建走的mock，太过粗暴。

mock的价值在于提供更好的数据灵活性以加速开发效率。它既可以在没有数据时，提供假数据；也可以在真数据的接口有问题时，不用重启服务，也能降级为假数据。它既可以是整个GraphQL查询级别的mock，也可以是字段级别的mock。

作为超级接口的GraphQL服务，全局的，在启动阶段就固化的mocking，意义不大。

ApolloGraphQL的mocking实践问题，正是它采用普通函数来描述Resolver所带来的；它很难简单的通过拓展某个resolver而支持mocking。它不得不在创建服务时，额外新增一个mockresolvermap去承担mocking职能。

而我们的composedresolver处理动态mocking却异常简单。

它不仅可以在运行时动态确定，它不仅可以细化到字段级别，它甚至可以跟着某次查询走mock逻辑（通过添加@mock指令）。

上图是默认情况下，基于faker这个npm包，根据数据类型生成的mockdata。

在我们的设计里，默认的mocking，其内部实现方式很简单。我们先是编写了上图，根据GraphQLType调用faker模块对应的方法，生成假数据。

然后在createResolver这个将中间件整合成resolver的函数里，先判断中间件里是否存在自定义的mockhandler函数，如果没有，就追加前面编写的mocker处理函数。

我们还提供了mock中间件，让开发者能指定mock数据来源，比如指定mockjson文件。

mock中间件，接收字符串参数时，它会搜寻本地的mock目录下是否有同名文件，作为当前字段的返回值。它也接收函数作为参数，在该函数里，我们可以手动编写更复杂的mock数据逻辑。

有趣的地方是，mock/user.json文件里，只包含上图红框的数据，其关联出来的collections字段，是真实的。这是合理的做法，mock应该跟着resolver走。关联字段拥有自己的resolver，可能调用自己的接口；不应该因为父节点是mock的，子节点也进入mock模式。

如此，我们可以在父节点resolver对应的后端接口挂掉后，mock它，让没挂掉的子节点resolver正常运行。如果我们希望子节点resolver也进入mock。很简单，添加一个@mock指令即可。

如上所示，user字段和collections字段的resolver都进入了mock模式。

自定义mockresolver函数的方式如上图所示，mock中间件保证了，只有在该字段进入mock模式时，才执行mockresolverfunction。并且，mockresolverfunction内部依然有机会通过调用next函数，触发后面的真实数据获取逻辑。

以上所有这些灵活性，都来自于我们选用了表达能力和可组合性更好的中间件模式，代替普通该函数，承担resolver的职能。

总结

至此，我们得到了一个简单而灵活的实践模式。我们用Schema去构建DataGraph数据关联图，我们用Middleware去构建ResolverMap，它们都具备很强的表达能力。

在开发GraphQL-BFF时，我们的GraphQL-Service跟后端基于领域模型的Service，具有总体上的一一对应关系。不会产生后端数据层解耦后，在GraphQL层重新耦合的尴尬现象。

关于GraphQL还有很多话题可以讨论，比如batching,caching等。这部分内容在网络上很多GraphQL的文档和教程里都可以找到，这里我们不再赘述。

总的而言，根据我们对GraphQL的考察和实践，我们认为它可以比RESTfulAPI更好的解决我们面对的问题。

我们对GraphQL的期望，不仅仅停留在BFF层。我们希望通过积累在BFF层使用GraphQL的成功经验，帮助我们摸索出在MicroFrontend架构上使用GraphQL模式的合理设计。

如前面所演示的，像User，Product和Order这种公共级别的数据类型，不可能只由一个团队去维护，它们需要被其它团队所拓展。使得我们可以通过用户，找到它关联的订单，收藏，优惠券等由其它团队维护的数据。

放到MicroFrontend架构上，一个支付按钮，也夹杂了多种类型的数据，产品信息，用户信息，库存信息，UI展示信息，交互状态信息等等，综合了这些信息，支付按钮被点击时，才得到了充分的数据，可以决定是否去支付。

朴素MicroFrontend的设计，用Vue,React,Angular不同框架，分别维护不同组件，通过router/message-passing等方式互相通讯。在我看来，这是对后端微服务架构的拙劣模仿。

后端服务，各自部署在独立环境中，对体积不敏感；因而可以采用不同的语言和技术栈。这不意味着将它简单的放到前端里一样成立。无法共享前端开发的基础设施，这不是微前端，这是一种人员组织架构上的混乱。

GraphQL让我们看到，基于领域模型的微前端架构，可能是更好的方向。一个简单的支付按钮，也综合了多个领域模型，由多个开发者有组织的协同开发。并不因为它表面上看起来是一个Button组件，就由某个团队单独维护。

当然，探索GraphQL的其它方向的前提是，GraphQL-BFF架构得到成功的验证。就现阶段的实践成果来看，我们对此充满了信心。

尽管我们的代码暂无开源计划，不过相信这篇文章，足够完整和清楚地介绍了我们的GraphQL-BFF方案。希望它能给大家带来一点帮助。

作者介绍：

古映杰，携程研发高级经理，负责前端框架和基础设施的设计、研发与维护。开源项目react-lite和react-imvc作者。

本文转载自公众号携程技术中心（ID：ctriptech）。

原文链接：

https://mp.weixin.qq.com/s/PovMmO6ddcpBO5A2WtY89Q

创作场景

全面解析 GraphQL，携程微服务背景下的前后端数据交互方案