讨论：做 API 聚合大家有什么想法没？

最近我们 team 计划做相关的事情，大致调查了一下业内的解决方案，无外乎如下几种：

1. 在服务端聚合，也就是我们现在的模式：通过人工的方式写代码来处理，这样虽然可以解决问题但是会耗费比较大的人力，而且做这件事情的人可能会感觉没有挑战，基本是重复劳作。

2. 在客户端聚合，通常见到的实现有 graphQL，这样的好处是服务端可以保持简单精简，但工作量其实下放到了客户端，而且版本控制变得不太好处理了（比如兼容多个客户端版本）

我目前可以想到的自己觉得还可以的方法，就是结合如上两种方式：客户端请求服务端时带参数和 graphql 的 id，服务端根据 id 可以获取到 graphql 的查询体，这样其实就是将接口聚合的工作放到了 graphql 查询的维护上面，类似的实现可以看下 instagram 的接口。但是同样也有问题，那就是 graphql 查询 的维护这个工作应该谁来做？

小弟第一次发帖，希望大佬们多多给点建议~ 没有建议的对我想的这个方法提一些意见，或者可能会有什么坑之类的都可以说说看~