写过前端的人都知道，REST风格的API适用于简单的增删改查。对于稍微复杂一点的关联查询，就不适合了：如果设计REST接口，一般会返回关联表的所有字段，满足比较相似的查询需求。如果设计多个细粒度的接口，前端需要多次Query，自己组装数据。粗粒度接口导致不必要的数据传输，细粒度接口导致功能爆炸。你见过满天飞的JavaScriptPromise吗？在这种场景下，Facebook工程师在2015年开源了GraphQL规范，让前端描述自己想要的数据格式，服务器返回前端描述的数据结构。简单的说，前端要什么，后端就返回什么，非常灵活。什么是GraphQL？简单来说，GraphQL是一种面向数据的API查询风格，将所有数据视为一个连通图，客户端可以准确获取所需的数据，没有任何冗余，使得API更容易随着时间的推移而演进，并可用于构建强大的开发者工具。比如前端只需要英雄的名字，那么后端就只返回这个名字，没有冗余：又比如：前端需要显示作者的帖子信息，作者自己的信息，作者的追随者名单。如果是REST，前端需要Request这三个接口，然后组装：/user/获取用户（作者）详情，可能是姓名。/user//posts获取该用户发布的帖子列表。/user//followers获取用户的关注者列表。现在我们可以通过一个GraphQL查询获取所有信息，而无需搜索多个异步API：query{User(id:'123'){nameposts{title}followers{name}}}简单明了，不是吗它？GraphQL带来的改变目前，应用开发的主流是前后端分离。前后端仅通过API进行通信。前端约定了一套Schema，用于生成接口文档，前端直接通过Schema或生成的接口文档发出自己想要的请求。经过几年一线开发者的填坑，已经有一些不错的awesome-graphql（https://github.com/chentsulin/awesome-graphql）用于开发和生产，很多语言也提供了对GraphQL的支持，例如JavaScript/Nodejs,Java,PHP,Ruby,Python,Go,C#等GraphQL使用趋势一些知名公司正在将RESTAPIs转换为GraphQL，例如Twitter,IBM,Coursera,Airbnb,Facebook,Github,Ctrip等，尤其是Github，其v4外部API仅使用GraphQL。据一位在Twitter工作的大佬透露，硅谷很多一二线公司都在尝试转向GraphQL，但同时他也表示，GraphQL还需要时间来发展，因为在生产环境需要大量的前端和后端繁重的工作。这无疑需要高层的动力和决心。GraphQL的局限对于简单的应用，设置类型、查询等可能会有点复杂，用REST可以更轻松地完成。对于复杂的查询，GraphQL只需要一个接口请求。虽然优化了网络层面的请求数，但是数据库层面的查询并不多。数据库查询可能会成为性能瓶颈，还有很大的优化空间。GraphQL的优势无冗余地检索准确的数据。通常情况下，当数据需求发生变化时，只需要修改查询即可，无需过多改动，提高前后端开发效率，实现产品快速迭代。最后，GraphQL已被各种规模、不同环境和不同语言的团队使用，以增强移动应用程序、网站和API。如果您厌倦了RESTAPI，现在是学习GraphQL的时候了。关注公众号《Python7号》学习更多技术干货。
