干货分享 | GraphQL 数据聚合层

[LeungGeorge]

http://www.sohu.com/a/235978606_205771

业务鉴权这块可以借鉴下

[LeungGeorge]

我们理想中的 GraphQL 接入方式，是跟网关同层嵌入在里面做一个管道，但是现在我们的实现方式呢，考虑到快速跑通，暂时把它放在网关的下面，是为它的鉴权跟安全不想占太多开发成本，把它交给网关去做了，所以它就只做数据聚合这么一件事情。

[LeungGeorge]

最后做一个总结，当宋小菜在使用 GraphQL 的时候，概括起来有以下六个特点：

1、单一入口，单端的入口方便前端做工程管理，避免后端做烦琐的API 版本管理。

2、文档，这个文档可能在一定程度上能够解决文档同步的问题和前端开发阅读的问题。

3、数据冗余比较方便，减少前后端交流成本。

4、数据聚合。GraphQL 天生支持数据聚合。因为每一个类型绑定resolver，所以定义不同的 resolver，就可以拿到不同服务上的数据，可以做到不同类型数据源的数据拼装。

5、MOCK，适当将 MOCK 的职责交到前端，或者前后端一起维护，而且维护起来比较简单。所以说 MOCK 方便我们开发。

6、动态编辑做到实时部署，敏捷开发。实时部署很快做到线上数据的响应。

[LeungGeorge]

对于宋小菜的前后端合作工作流，直观上可以看到这几个变化：

前端从接口设计环节，向前介入到服务端的系统设计中的库表结构评审环节，此时不仅能了解到库表的字段分布和业务含义，也能在库表设计上就提出一些建议，帮助服务端输出更友好的字段类型和结构给前端，比如 精度和维度，这两个是分开存，还是用逗号隔开，存一个 String，是有分别的； 服务端省去 Mock，省去胶水 API 的设计和维护，省去 Mock，专心做底层基于业务的系统拆分，提供更稳定的数据服务； 前端在接口评审之前，就可以在 GraphQL 的类型 Mock 上抽象大部分的字段出来（服务端一定确定库表结构，后续改动服务就会很小了），此时就可以把 DOM 页面实现后，把占位符的字段就填进去了大部分，结构上在接口评审中双方再核对调整一遍就好了； 前端由于有服务端领域边界的支撑，可以针对特定领域及领域的组合，来封装更有弹性的组件，组件的扩展性可以由配置决定，而不是某一个 API 决定，这个配置向下就是 GraphQL 的聚合能力。 关于第 4 点，我们仍然在探索尝试，最终想要表达下我们团队的工作理念，这一点很重要，无论事情是谁的，最终事情一定是公司的，无论一个技术推广影响到谁或者撼动了谁的所谓原来立场所代表的利益，只要对公司研发团队效率有利，而且有利于技术演进，有利于推动业务更快的走，那么就要果断尝试。最终，为我们所有人的行为买单的是公司，但最最终，依然是我们自己。