最后来总结一下这个解决方案吧，其实这个方案你说是不是最佳解呢？也未必，还是要看具体的业务场景的，在我遇到的场景中各种数据的关系是明确的，或者说是可以抽象成模型的，我认为这是能否使用 Graphql 的关键，从上面的实例中我们其实可以发现通过 Graphql 我们把每个数据都规范了起来，指定了类型，确定了嵌套关系，这在以 JavaScript 为基础的 node 环境中显得那么格格不入，本身 JavaScript 是弱类型的，基于此我们可以在 node 服务中灵活的修改数据，从而不需要关心返回值和参数值，但是 Graphql 用一种强类型的观念来强制我们设计每个数据，也许会有些前端的同学接受不了，但是我个人认为这种思路其实是非常合理的，并且 Graphql 这种还支持嵌套查询，只需要 fields 属性中有这个对象就行了，因此我们可以把每个数据类型尽可能的抽象和分离出来，举个例子，店长这个角色不就是用户对象加上商户对象的组合嘛，这不仅从关系上明确了逻辑，也方便了更多可能性的组合条件。

对应我一开始遇到的那几个问题，Graphql 看上去似乎完美的解决了我的问题，但是对于更加复杂的场景呢？或者说对于老项目的改造成本是否划算呢？虽然我没有遇到，但是我觉得只要认真梳理数据结构，最终都可以的，但那个时候是否还需要 Graphql 呢？那就不知道了，这篇博客不是介绍 Graphql 如何使用的中文文档，我想表达的是这种思路对于这种场景下的一个解决思路，现在它只是解决了我的这些问题，那么从这个思路的身上能不能挖掘出更多的惊喜呢？它还是太新了，也许过几年回头再看，它说不定就和 restful 一样是 API 的标配了也说不定呢，毕竟 GitHub 今年也推出了他们的 Graphql API 了呢。

posted @