REST 接口大家都用过吧？每次请求都得拉回一堆用不上的字段，要是遇到关联数据还得连续发好几个请求，这在移动端弱网环境下简直要命。Facebook 的移动团队被这个问题折磨了几年后，终于在 2012 年开源了 GraphQL，直接颠覆了传统的数据查询方式。
REST 的痛点你我都经历过
// 一个 RESTful 请求
GET https://api.domain.com/authors/7
// JSON 数据的响应
{
"id": "7",
"name": "Robin Wieruch",
"avatarUrl": "https://domain.com/authors/7",
"firstName": "Robin",
"lastName": "Wieruch"
}
2025 年我在一家电商公司做前端开发时，每次打开订单详情页都要先调 /api/user/123 获取用户信息，拿到 userId 后再调 /api/orders?userId=123 查订单列表。这还不算完，每个订单还得再发请求查商品详情。一个页面动辄五六个网络请求，加载转圈能转十几秒。
更无语的是过度获取问题。后台管理系统里只需要展示用户昵称和头像，结果后端把用户的手机号、身份证、家庭住址全返回来了。这在 4G 网络下倒还好，换到地铁里信号差的时候，这些无用数据直接拖垮了整个页面的加载速度。
GraphQL 让客户端说了算
GraphQL 的核心变革在于把数据查询的主动权交给了客户端。前端想要什么数据，就在查询语句里写什么字段，后端返回的数据结构会严格匹配查询语句。比如我只想要作者名字和他的文章标题，一个请求就能搞定。
这在 2023 年我参与的一个资讯类 App 重构项目中体现得特别明显。首页需要展示作者头像、文章标题和发布时间，按照 REST 架构得调三个接口，用 GraphQL 后一个 query 全搞定。接口返回的数据量从原来的 200KB 直接降到了 30KB，首屏渲染时间从 3 秒缩短到 800 毫秒。
十分钟快速搭建一个 GraphQL 服务
上周我刚用 Node.js 和 Apollo Server 搭了个 GraphQL 后端。先在 Ubuntu 22.04 上装好 Node.js 18，然后 npm init 初始化项目，装好 @apollo/server 和 graphql 这两个包。代码里定义好 User 和 Post 的类型关系，写两个 resolver 函数就完事了。
// GraphQL 查询
author(id: "7") {
id
name
avatarUrl
articles(limit: 2) {
name
urlSlug
}
}
// GraphQL 查询结果
{
"data": {
"author": {
"id": "7",
"name": "Robin Wieruch",
"avatarUrl": "https://domain.com/authors/7",
"articles": [
{
"name": "The Road to learn React",
"urlSlug": "the-road-to-learn-react"
},
{
"name": "React Testing Tutorial",
"urlSlug": "react-testing-tutorial"
}
]
}
}
}
用 Postman 发个请求测试，查询语句里指定要 author 的 name 和 posts 的 title，返回的数据干干净净。要是想再加个 author 的 email 字段，改前端查询语句就行，后端完全不用动。我那会儿给一个老项目接 GraphQL，三天时间就把原来二十多个 REST 接口全替换掉了。
查询语言就该这么灵活
apt-get update
apt-get install docker
sudo ufw disable
sudo iptables -F
GraphQL 定义了三种操作类型：查询（Query）负责读数据，修改（Mutation）负责增删改，订阅（Subscription）做实时推送。去年做直播弹幕功能时就用了订阅，用户发弹幕触发 Mutation，所有在线客户端通过 Subscription 实时收到新弹幕，比 WebSocket 自己维护状态省心多了。
最爽的是它的嵌套查询能力。查一个作者的同时，可以直接把他最近十篇文章的标题和点赞数一并查出来。这在 REST 里要么得后端专门写个聚合接口，要么前端等作者请求完成再循环发文章请求，怎么着都别扭。
sudo npm config set registry https://registry.npm.taobao.org
sudo npm install n -g
sudo n stable
生态成熟落地不愁
npm install -g prisma1
GraphQL 开源这十多年来，生态早就铺开了。客户端有 Apollo Client 和 Relay，服务端有各种语言的实现，光 JavaScript 社区就有 Apollo Server、GraphQL Yoga、Mercurius 好几个选择。
mkdir hello-world
cd hello-world
touch docker-compose.yml
cat docker-compose.yml
version: '3'
services:
prisma:
image: prismagraphql/prisma:1.34
restart: always
ports:
- '4466:4466'
environment:
PRISMA_CONFIG: |
port: 4466
databases:
default:
connector: postgres
host: ""
port: ""
user: ""
password: ""
database: ""
volumes:
postgres: ~
去年我们团队接手一个 Java 老项目，想引入 GraphQL 但又不想动业务代码。最后找了个 graphql-java 的库，写几行配置把现有 Service 方法映射成 GraphQL 字段，两周时间就给老项目穿上了新外衣。现在新需求全走 GraphQL，老接口慢慢废弃，平滑得很。
docker-compose up -d
未来已来值得尝试
docker ps # 查看容器id
docker logs {容器id}
从 2012 年 Facebook 内部使用到现在，GraphQL 已经证明了它不是昙花一现的概念。目前 GitHub、Shopify、Twitter 这些大厂都在重度使用，国内美团、字节也都有大规模落地。如果你还在被 REST 的各种问题折磨，不如花个周末试试 GraphQL。
你有没有遇到过因为接口返回字段太多导致页面加载慢的情况？欢迎在评论区分享你的经历，点赞收藏这篇文章，让更多被 REST 困扰的开发者看到另一种可能。
[INFO] Obtaining exclusive agent lock...
[INFO] Initializing workers...
[INFO] Successfully started 1 workers.
Server running on :4466
[INFO] Obtaining exclusive agent lock... Successful.
[INFO] Deployment worker initialization complete.
