GraphQL API 设计 思考
对于 GraphQL API 的设计，我个人觉得要遵守两条重要的准则：
- 向后兼容旧版本
- 向前考虑拓展性
向后兼容旧版本
向后兼容旧版本是非常重要的，在平时的开发中，大家还是得遵守这一准则。
接口的兼容性，我觉得是一个开发在每次开发的时候一定要考虑到的，因为很多用户还在使用着旧版本，一定要把他们考虑进来。虽然说想要做到这一点，会增加开发成本，但我觉得这是非常有必要的，总不能等到上线了，出现了旧版本的问题，再一个一个去解决吧，那效率就非常低了。
如果不兼容旧版本，那么用户使用旧版本的时候会出现查询失败等报错，导致老用户流失，所以原则上，新功能不能影响原有的功能，所以需要去兼容它。
向前考虑拓展性
无论是接口还是函数，拓展性一直是一个基本的原则，拓展性是一个函数好不好的重要判定标准。在 GraphQL 的查询中，我觉得要实行 ORM 那种对象配置的查询方式，这样的话方便后面查询的拓展，增加这个 API 的可能性。
不使用自定义的对象类型，还会使得参数列表随着迭代变得越来越长，而一个长的参数列表，又是另一种代码坏味道。
GraphQL API 设计细节
命名
命名采用 动词+名词 的形式，比如：
- 新增用户：addUser
- 删除用户：removeUser
- 修改用户：editUser
传参
我们需要考虑兼容性，以及拓展性。所以需要我们要保证传参的基本结构是不变的，这样才能兼容旧版本，同时，也可以往这个对象中去新增属性，保证了后续的传参拓展。
返回结果
需要将涉及到的 Response 都进行返回，这样一次性返回的数据多，就不需要多几次请求了，能降低前端请求频率，大大提高前端请求的效率。
单一端点
我们在使用 REST，可能十个请求会有十个 URL ，但是再 GraphQL 中不要这么做，这么做的话就违反了 GraphQL 本身的规范了。我们可以只用一个 URL ，通过传递不同的查询条件，去得到不同的结果。市面上很多 GraphQL 的库也是遵循了这个规则。
gzip 压缩 JSON
在响应头中加上：
Accept-Encoding: gzip
就可以对返回的响应进行压缩，减少返回的体积，提高获取数据的速度。
可空性
在传递 GraphQL 参数的时候，有些字段要允许可空，这样做的理由是，不能因为查不到某一个字段，就影响了整体的数据查询，这样的话我们的查询会变得寸步难行，效率极低。
分页
由于 GraphQL 不能对未知深度的数据进行全量查询，所以我们在设计 GraphQL 列表接口的时候，需要做好分页这一工作。
Apifox 测试 GraphQL 接口
GraphQL API 还有一个重要的环节，那就是当你编写完一个 GraphQL 接口后，需要去进行调试，看看这个接口返回的数据是否符合你的预期
给大家推荐一款超级好用、支持中文、免费的 API 工具 —— Apifox。
新建 GraphQL 请求
我们调试之前，需要新建一个 GraphQL 请求，这是前置条件。
设置断言
我们需要判断查询的数据是不是符合我们的预期，我们可以使用 Apifox 提供的可视化断言功能，不需要你写脚本，直接用就完事了。
填入断言的信息：
- 断言名称
- JSON PATH 表达式
- 断言条件
这个断言意思就是，返回数据的 data->questionById->id 是否等于后面那串数字。
设置完，点击 保存 按钮。
运行 查看校验结果
我们到运行也，点击 发送按钮，我们发现断言成功了，也就是返回的数据是我们预期的：
这就完成了 Apifox 对于一个 GraphQL 接口的调试。
关于Apifox
- 集成了API 文档、API 调试、API Mock、API 自动化测试 API 一体化协作平台
- 拥有更先进的 API 设计/开发/测试工具
- Apifox = Postman + Swagger + Mock + JMeter
欢迎体验一下，完全免费的哦：在线使用 Apifox