「译」GraphQL与REST,优势是什么

由 Facebook 开创的 GraphQL,自 2015 年面世以来就一直在改进着 web 和原生应用。相比较于传统的 REST API,它的几个优势也使得其使用率迅速提升。

优势 1:更少的数据

大多数你消费的目标数据来源于某个地方的数据库。如果你正好在 SQL 数据库上工作,你应该知道,只请求你所需要的字段比请求所有的字段要更高效。

在 REST 的体系中,几乎不可能只指定你需要的字段。结果,你通常会获取比你所需要的更多的数据。如果你需要一次获得多条记录,这时你就需要处理一个指数级的问题。

在 Manifold,我们与所有 REST 终端返回的数据做斗争。

REST

1
https://api.catalog.manifold.co/v1/products

这个链接返回 141 KB 的 JSON 数据,并且这还不是我们最重的终端。(我们最重的 REST 终端返回 1M 以上的 JSON 数据!)对于这个终端,任何时候我们需要任意产品的数据的时候,这份数据都会装载到客户端里。并且,在 REST 工作的方式中,这只是我们需要渲染一个页面所需的几个调用中的一个。

相比于我们的 GraphQL 终端:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
//request
{
products(first: 100) {
edgets {
node {
displayName
logoUrl
tagline
}
}
}
}

//response
{
"data": {
"products": {
"edges": [
{
"node": {
"displayName": "Dumper",
"logoUrl": "https://cdn.manifold.co/providers/dumper/logos/512x512_2.png",
"tagline": "Off-site backup-as-a-service for MySQL, PostgreSQL, MongoDB and Redis."
}
},
{
"node": {
"displayName": "Blitline",
"logoUrl": "https://cdn.manifold.co/providers/blitline/logos/blitline.png",
"tagline": "Premium image processing and rasterization API for enterprise systems"
}
},
...
]
}
}
}

如果我们只需要三个字段,我们的 GraphQL 终端只返回我们所需要的,并且只有 9.4 KB,比 REST 要小 95%。

此外,很多时候我们需要通过后续的 REST 请求来获取一个产品的计划数据(我们将在接下来谈到链式)。对于我们查询的每个产品,我们有时候也需要查询它的计划。这是一个示例,关于如何将这些多重查询结合成一个 GraphQL 查询(以及一些其他用于比较的场景):

场景 REST 数据量 GraphQL 数据量 降低
所有产品 + 所有计划 562.4 KB 15.4 KB 97%
所有产品 141 KB 9.4 KB 95%
单个产品 4.1 KB 0.2 KB 95%

并且思考一下:这节约的只是针对一个用户的。想象一下大规模应用后它将带来什么:技能降低加载时间,又能降低带宽占用。

优势 2:组合请求

GraphQL 另外一个重要的优势即是其组合多个请求的能力。如果你之前使用过 REST,你可能常常经历链式调用的痛苦:

  1. 我们需要展示一个团队,先来调用 /team/:id 请求。
  2. 每个 team 拥有一系列的 userIDs。对于每个团队用户,我们需要调用 /user/:id 请求对于每个这些 ID。
  3. 我们还想要展示有哪些其他的队伍上也包含了这个 user。此时我们针对每个团队、每个用户再次调用 /team/:id

让我们把它加起来:

1
2
3
/team/:id  1
/user/:id n (n: 团队里成员的数量)
/team/:id n × t (t: 每个用户的团队数量)

如果这是一个拥有 20 个用户的团队