GraphQL 数据查询语言

01 它是干嘛的

GraphQL 是一套让客户端「按需点菜」的数据查询方式。它把过去需要很多个不同地址的接口，收拢成唯一一个入口：客户端在一份声明里写清楚自己需要哪些字段，服务端照着这份声明把数据取好返回。它解决的是接口太多、数据要得太多或太少的尴尬。

过去前后端约定接口用的是 REST 风格：每种数据各有一个地址，要用户信息问一个地址，要他的文章再问另一个地址。结果手机端打开一个页面，可能要连着发十几个请求，把几份数据拼起来才能显示，网络一慢，页面就一直在转圈。

更麻烦的是「要多了或要少了」。同一个接口服务着手机和网页，手机只想要姓名和头像，接口却把整个用户档案全返回，白白浪费流量；反过来当页面临时需要一个新字段，后端不改接口就取不到，前端只能干等。这种尴尬在移动网络下尤其致命。

Meta 在 2012 年前后为自家移动应用造了 GraphQL 来治这个病：把接口收成一个总入口，客户端像填点菜单一样写明要哪些字段，服务端照着单子取。2015 年它被开源，随后成为很多公司在 REST 之外的另一种主流选择。

客户端不再记一堆接口地址，只对着唯一端点提交一份结构化的声明，服务端解析这份声明，按字段逐一取数，再把形状完全对上的数据返回。

这张图原本描述统一入口的网关结构，GraphQL 用同一结构表达：客户端一个端点、按需声明要哪些字段、服务端按声明取数返回。看图时抓住「一个入口、一份声明、一次返回」这三处，再对比 REST 里一个页面要分别打十几个地址的忙碌景象。

移动端弱网优化

手机流量宝贵，一次只取需要的字段，少发请求也少传数据，页面更快打开。

前端与多个后端服务对接

前端面对一个入口，背后由它去汇总多个服务的数据，前端不必关心数据来自哪里。

需求快速变化的业务

页面临时要加个字段，前端改一改声明即可，不必等后端专门开新接口。

多端共用一套接口

网页、手机、手表各自的界面不同，用同一入口各取所需，服务端不用为每端单独定制。

门槛中等：看懂声明语法很快，真正的工作量在服务端那一侧的定义与实现。

一份客户端声明：只取需要的字段graphql

# 服务端照着这份声明返回，结构一模一样，不多也不少
query {
  user(id: "42") {
    name
    avatar
    posts(last: 3) {
      title
    }
  }
}

REST按资源分地址、用法直白、缓存成熟，但一个页面常要多次请求，且容易多拿或少拿数据。

gRPC服务之间高性能通信的另一种方案，强类型、传输紧凑，更适合内部服务调用而非浏览器直接使用。