GraphQL 是更好的 REST

我们在前面的文章中已经讨论过使用 BFF 的必要性和 GraphQL 的基础知识。本文将对 GraphQL 和传统 REST 进行对比，来说明相较于传统 REST，在 BFF 中使用 GraphQL 的优越性。

数据获取

传统的 REST 接口，前端在获取数据的时候，一直存在两个老大难问题，一个是多获取了数据，另一个是少获取了数据。

多获取了数据

在传统 REST 接口中，一个接口返回的信息往往会比页面真实需要的数据要多。比如商品详情接口，接口返回的商品信息是必然比页面上展示的信息多的，除非给每个前端页面都定制接口。这就是多获取了数据的问题。

一般情况下，多获取了数据并没有太大的危害。但是，如果数据模型比较复杂，尤其在这个接口中还要聚合其他模型的信息的时候，接口性能、可用性等有时候会被多余的信息所拖累。

还是以商品详情为例。通常情况下，在商品购买页面，我们需要获取尽可能多的商品信息，传统 REST 可以满足页面需求。但是在订单页面中，我们只需要展示商品的简版信息，比如名称、规格、价格等，其他的信息一概不要。这时候，如果商品详情中聚合了其他信息，需要查询其他服务的，在订单页面中就完全没有必要获取这些信息。如果被依赖的服务稳定性较差，也会导致订单页面的稳定性比较差。

GraphQL 很好了解决了这个问题。我们通过 Query 明确地告知 BFF 需要哪些数据，BFF 在从下游服务获取这些数据返回给前端。不需要的数据，就不会被获取，减少了不必要的系统调用。

少获取了数据

少获取数据，通常表现在列表中。一般在列表接口中，每个列表元素返回的信息都比较简要，而页面上有时候又想展示一些关联的信息。比如商品列表，列表接口中只返回商品的基本信息，如果页面上要展示每个商品的优惠信息的话，需要根据列表返回的信息再调接口获取。

在 GraphQL 中如何解决少获取了数据的问题呢？在 GraphQL 服务端实现中，有个 Resolver 的概念，即每个字段都有一个 Resolver 函数，GraphQL 在执行的时候，会根据 Query 中查询的字段调用每一个 Resolver 函数获取这个字段的值。因此，我们只需要在服务实现时定义好每个字段的 Resolver 函数即可。比如我们可以给每个商品模型定义一个优惠信息的 Resolver，那么在商品列表中的查询中，在 Query 上添加这个优惠信息字段，GraphQL 就会自动查询每个商品的优惠信息。

N+ 1 问题

N + 1 问题说的就是上面商品列表查询优惠信息的问题。在传统 REST 接口中，如果列表返回 10 条数据，前端就需要在通过 10 次请求查询商品的优惠信息，总共需要 11 次请求。N + 1 问题最大的危害是占用数据库资源太多。如果一次返回 100 个商品，那就需要查询数据库 100 次，很容易耗尽数据库的连接资源。

GraphQL 中通过 dataloaderopen in new window 来解决 N + 1 问题。在商品列表的例子中，dataloader 会将这些查询优惠信息的请求合并成一个请求，再将数据库返回的信息分配给每一个商品模型。当然，如果 BFF 不是直接读取数据库，需要后端服务支持批量查询的接口。

开发效率

在传统 REST 模式下，页面变化通常需要后端接口跟着做调整，需要前后端之间重新对接口进行约定、联调、发布。这一串动作都是非常耗时的。

在 GraphQL 中，如果页面变化的内容原先系统中模型之间的关系已经建立，那么只需要前端页面调整查询的内容即可，减少了接口约定、联调等流程，同时纯前端静态资源的发布也比后端服务发布要方便很多。

性能

通常，一个页面的数据请求不止一个。比如商品详情页，需要商品信息、优惠信息、广告信息等各种数据接口。在传统 REST 接口，我们需要分别调用这些接口获取数据。

在 GraphQL 中，我们可以通过一次请求将这些数据全部都拿到。只需要在 Query 中查询多个数据信息即可，GraphQL 会返回多棵 JSON 树。在弱网环境下，GraphQL 可以比传统 REST 获得更好的性能体验。

迭代升级

在传统 REST 接口中，我们升级原有的接口都是通过在路径中增加版本号来实现。比如从 /rest/v1 升级到 /rest/v2。而在 GraphQL 中，我们可以渐进式的实现 API 的升级。

比如在一个影片管理系统中，我们有如下定义：

type Film {
  title: String
  episode: Int
}

1
2
3
4

现在我们可以导演信息，我们只添加了导演名称：

type Film {
  title: String
  episode: Int
  dirctor: String
}

1
2
3
4
5

过段时间，发现需要导演的详细信息：

type File {
  title: String
  episode: Int
  director: String @deprecated
  directedBy: Person
}
type Person {
  name: String
  directed: [Film!]
}

1
2
3
4
5
6
7
8
9
10

通过新添加一个字段 directedBy 同时将原来的 director 标记为 deprecated。GraphQL 的工具会将标记为 deprecated 的字段隐藏掉。这样，我们就可以实现 API 的渐进式升级，同时不需要引入版本号。

细粒度的字段控制

前面说到，GraphQL 可以实现前端页面按需获取数据。在服务端，GraphQL 依然可以对每个字段进行细粒度的数据收集。因为每个字段都有对应的 Resolver 函数，因此我们可以在这些函数中搜集很多信息，比如字段是否还在使用，字段对应的处理性能数据等。

文档能力

在上一篇文章中，我们知道 GraphQL 有一个类型系统，我们通过 SDL 定义 Schema。有了 Schema，我们就有了系统内的所有类型信息。相当于一个字典，我们可以按图索骥查询所需数据。实现了代码即文档的效果。

在 GraphQL 的内省模式中，我们可以查到系统支持的所有 Query 类型、Mutation 类型，以及每个类型的字段说明等信息。避免了 API 文档的维护工作。

关注微信公众号，获取最新推送~

加微信，深入交流~

# 数据获取

# 开发效率

# 性能

# 迭代升级

# 细粒度的字段控制

# 文档能力

数据获取

开发效率

性能

迭代升级

细粒度的字段控制

文档能力