写过前端的都知道，REST 风格的 API 适合简单的增删改查。对于稍微复杂的关联查询，就显得不太合适：如果设计一个 REST 接口，一般情况下会返回关联表的全部字段，以满足更多类似的查询需求，如果设计多个细粒度接口，前端就需要查询很多次，自己拼装数据。粗粒度的接口导致不必要的数据传输，细粒度的接口导致函数爆炸，你见过 JavaScript 的 Promise 满天飞吧。
在此情景下 Facebook 的工程师于 2015 年开源了 GraphQL 规范，让前端自己描述自己希望的数据形式，服务端则返回前端所描述的数据结构。简单的来说，前端要啥，后端就返回啥，非常灵活。
什么是 GraphQL?
简单来说，GraphQL 是一种面向数据的 API 查询风格，把所有数据都视为已连接的图形，客户端能够准确地获得它需要的数据，没有任何冗余，也让 API 更容易地随着时间推移而演进，还能用于构建强大的开发者工具。
再比如：前端需要显示作者的帖子信息，作者本人的信息，作者的关注者列表，假如是 REST，前端需要请求这三个接口，再组装：
-
/user/
获取用户(作者)详细信息，可能是名称。 -
/user/
/posts 获取该用户发布的帖子列表。 -
/user/
/followers 获取用户的关注者列表。
现在我们可以通过 GraphQL 的一次查询拿到全部信息，无需从好几个异步 API 里面来回找：
- query {
- User(id: '123') {
- name
- posts {
- title
- }
- followers {
- name
- }
- }
- }
简洁明了，不是吗?
GraphQL 带来的改变
目前应用开发的主流就是前后端分离，前后端只通过 API 来交流，结构大概如下图
