GraphQL + Space Cloud 简化你的API设计

服务端API的设计与开发，为客户端提供产品业务所需要的各种功能和数据接口。随着APP产品的迭代更新，APP Server提供的接口往往也会进行多个版本的迭代更新。如何优雅的维护接口的稳定性，设计扩展性满足将来一定的业务需求变更，一直是从事服务端接口开发工程师需要不断思考的问题。

特别的，当你同一个服务的接口需要服务于多个需求不尽相同的客户端时，你的接口设计工作会变得尤其重要：

• 你可能会开始为接口提供各种option，以支持不同的客户端接入使用不同的option满足不同的需求；

• 你可能会将数据接口粒度拆分得更小，以支持不同客户端组合不同的API得到自己需要的数据；

• 你可能还需要提供通用的batch批量请求接口，以解决客户端通过蜂窝网络远程调用多个数据接口延时增大的问题，又或者为某个客户端接入量身定制满足需要的接口；

之所以会产生这样的接口维护成本，一个原因在于这里API接口的设计承担了数据表示的职责：为前端的UI/UX提供展现所需要的数据。比如APP上的个人中心页面，UI/UX需要展现昵称，头像，性别的数据，这是一个来自UI/UX对数据接口返回的需求。

有没有可能将来自UI/UX的需求尽量控制在UI/UX的实现端（客户端）从而减少UI展示层的逻辑变化的复杂度对后端接口的影响呢？

GraphQL 专注于数据建模

2012年Facebook移动端从H5改用IOS原生应用重新开发时遇到了类似的问题，新的APP产品设计使得原来的很多REST API不再适用或者使用过滤繁琐。解决这一问题，Facebook在接入层添加了一层称为GraphQL的查询语言。并于2015年，发布了GraphQL的规范及其javascript版本的参考实现。

如果说传统的REST接口类似一个售货机，每次按一个按钮获得一个对应的货物，需要5个不同货物你需要按5下，那么GraphQL仿佛一个智能按钮，可以让你通过表达你的需求一次获得需要的所有货物。GraphQL让服务的设计者可以专注于数据建模，而非接口的数据表示和组织。服务的设计者完成数据建模定义好服务的数据能力，服务使用者可以通过GraphQL表达自己的需求来按需得到自己需