由 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 | //request |
如果我们只需要三个字段,我们的 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,你可能常常经历链式调用的痛苦:
- 我们需要展示一个团队,先来调用
/team/:id
请求。 - 每个
team
拥有一系列的userIDs
。对于每个团队用户,我们需要调用/user/:id
请求对于每个这些 ID。 - 我们还想要展示有哪些其他的队伍上也包含了这个
user
。此时我们针对每个团队、每个用户再次调用/team/:id
。
让我们把它加起来:
1 | /team/:id 1 |
如果这是一个拥有 20 个用户的团队