021、GraphQL与API演进：替代REST的新思路

021、GraphQL与API演进：替代REST的新思路上周排查一个线上问题，凌晨三点被报警叫醒。前端同事紧急反馈某个管理后台页面加载缓慢，耗时超过十秒。打开监控一看，发现页面初始化时连续发了十几个REST请求，其中一个获取用户详情的接口反复被调用，每次只差一两个字段。后端数据库压力飙升，而前端还在抱怨数据拼接逻辑复杂——这种场景你是不是也遇到过？REST的隐形成本传统RESTful API设计有个经典问题：过度获取或获取不足。比如我们要开发一个博客详情页，可能需要调用：/api/posts/123获取文章基础信息/api/posts/123/comments获取评论列表/api/users/456获取作者信息（上一步返回的作者ID）/api/users/789获取最新评论者信息…前端需要串行或并行发起多个请求，然后手动拼装数据树。更麻烦的是，移动端和Web端可能需要不同的数据粒度，但后端只能提供固定的数据结构。我们团队就曾为不同客户端维护三个不同版本的/api/user接口，后期维护成了噩梦。GraphQL的核心突破第一次接触GraphQL是在2018年，当时Facebook刚开源不久。最让我震撼的是这个查询语句：