GraphQL是什么

GraphQL 是一种面向数据的API 查询风格。 传统的API 拿到的是前后端约定好的数据格式，GraphQL 对API 中的数据提供了一套易于理解的完整描述，客户端能够准确地获得它需要的数据，没有任何冗余，也让API 更容易地随着时间推移而演进，还能用于构建强大的开发者工具。

目前公司开发接口的困境

1： 目前惠农网的前端存在多个不同的前端，不同的端在某一些业务层面的展示形式还是有所区别的 。
2: 目前一些业务在一些复杂的页面存在调用10+个接口的问题，导致前端开发起来难度较大。
3: 后端为了复用接口，存在一些接口返回了过多的数据给前端，让前端自己去选择，从而一些页面对于很多返回的字段不会进行使用
4: 前端如果想要后端进行部分业务的聚合，需要进行和多个服务端的开发进行沟通，服务端开发人员进行聚合也要内部进行沟通和协调，导致沟通成本越来越高
5: 目前服务端从在近100个微服务，可能在不同的地方进行了聚合大同小异功能的接口，这种开发无疑是难以维护和增加负担的

针对上面的问题，我们想通过一些技术手段或者约定来减少以上 说的问题。

后面经过 评估，最终选择了GraphQL来完成这个事情。

GraphQL所处的地位

目前我们使用GraphQL不是为了完全替代restful，而是对于在微服务体系中作为一个互补的能力。能搞把微服务进行业务梳理出不同的业务领域，然后通过GraphQL进行聚合。

这样做的好处：
1: 前端针对需要大量不同业务域的接口聚合可以按照自己的需要来进行数据获取，从而不需要在麻烦后端人员去开发
2: 前端调用接口也可以把之前的多个接口调用减少到1一次调用，减少了前后端的调用开销
3: 前端根据页面要展示的数据，自行获取，不会获取到多余的字段 ，对于网络层面的开销也有一定的提升
4: 后端人员只需要把稳定的业务域的数据一次性全量开发，就可以进行很多不同的业务和终端，真正的做到一次开发，多处使用，减少了业务重复开发的工作
5: 后端和前端通过schema进行沟通，可以有明确的记录领域的内容和字段，减少接口的维护成本

具体落地中的问题

因为我们的项目不是从头开发，已经有非常多的设施了，所以需要根据现在的技术基础做一些决策

1: 聚合的服务到底是前端团队负责还是后端团队？ 针对这个问题在网上查了一些资料，感觉网上大部分都是前端团队进行负责的，都是基于nodejs进行开发的。但是基于现在所在团队的规模和技术能力，我们还是决定服务端放在后端团队，用java语言进行开发，基础框架也是基于springboot。

2: 聚合网关所处的位置，因为我们现在有基础网关，做了一些安全方面和鉴权方面的工作，所以业务聚合必然是放在基础网关之后，在业务逻辑层之前。

3: 哪些部分需要放到聚合网关，就需要根据设计的schema来进行确定，并不是所有的字段都是通过这个聚合网关进行返回到的。

4: 聚合网关graphql的定位，graphql不是为了替代现在的 restful，而是起到一个互补的作用，所以到底是走之前的restful模式还是走新的graphql的模式，这个选择权基本交给了前端，业务内聚高的页面，还是走之前模式，只有当一个页面汇聚了多个不同域的内容，才走graphql的聚合网关。另外，虽然graphql除开query之外，还有另外两种模式，但是在我们现在的场景中，暂时我们只考虑做接口query请求的聚合。

5: 因为聚合网关只有一个接口，那么这个接口突出的数据就会是巨大的，所以也需要考虑数据安全性的问题。

6: graphql入口只有一个，如何做好细粒度的监控也是一个需要考虑的问题，并且能够结合到现在的微服务的整个监控体系。

7: 因为聚合网关主要还是调用业务服务来拿到具体的数据，所以会牵涉到调用众多的底层服务，graphql如何高性能的调用底层服务，也是需要考虑的，暂时是通过 springboot+webflux+reactivefeign来进行底层调用，来提高接口的性能。

8: 对于graphql服务的异常处理，也需要进行确定。

9: 前端如何有效的根据要选择的字段来快速构造出前端请求query，也需要根据schema来确定，那么schema如何和服务端编写的保持一致。

10: 服务端的schema如何设计以及如何更新，也是长久迭代之前需要进行考虑和讨论的。

最后

因为这种模式的尝试也是一次技术的升级，所以难免在落地的过程中会遇到问题， 但是从现在业界的使用情况来看，我觉得我们现在对GraphQL的技术引入，针对聚合业务的特定领域还是利大于弊的。也希望有想法交流的也可以来进行沟通和交流