https://github.com/sysulq/graphql-grpc-gateway

所以我试着做了一个 graphql 转 grpc 的网关，各个模块提供 grpc 接口即可，在网管层合并为 graphql ，端上可以根据需求自行选择接口聚合

我就是因为和你碰到一样的问题，自己学 Node 写了聚合 ，挺方便的，求人不如靠自己。

如果你的前端是 web ，那么尽量保持单一职责；如果你的前端是 app ，那么尽量合并接口（ bff ）。
说来说去，还是看前后端谁能说服谁。

所以一个项目需要一个技术负责人去平衡技术实现的一些细节。 不然前后端分离导致的前后端经常撕逼的问题基本无解。  毕竟但凡有点老资格或者工作久点的程序员都想装逼。

这里还是初级程序员多啊

这无所谓吧，不是你拼就是他拼，我更倾向于 API 解耦。在前端封装一个函数调用多个 API 不就行了。

因为要处理性能问题，计算机里有大量违反原则的事情，比如 CDN 、Cache/Buff 、各种冗余比如表字段冗余等等。

楼主要多思考。

当有话语权时，坚持接口单一职责；当只是个 curd boy 时，大佬们需要什么数据我返什么数据，复制粘贴多大点事。

技术从来不是单纯的技术，要保持灵活性，因人而异。

后端一个 API 对应只有一个项目一个功能的场景随意

可是真实场景哪有这么简单，一般都是对应几个服务或者几个前端依赖这个 API

某个前端偷懒说这不合理要求改动 API  这不是疯了

除非有重大性能问题或者业务破坏性变更，前端能自己处理就自己处理

处理不了的再和后端商量专门写一个新接口

下线一个 API 都要看过去七天甚至一个月半年有没有请求记录才敢下线。

已经部署到生产环境的 API 轻易不要妄动

作为前后端都写的研发，从我个人思考和实践出发而言

先说做法：

- 后端 Controller 层：原先两个 Controller 保留，此外我会新增一个聚合的 Controller ，然后新的 Controller 基于原先两个 Controller 的具体实现。

原因：
1. 如果我们的前端是多端多服务的，我写一次，各个前端（ Web 、APP ）其实不用做多次重复的工作
2. 假设一个 http 网络请求在联通中只有 99% 的成功率，这个聚合 API 是 3 个 API 组合而成的。那么成功率一个是 99%，一个是 0.99 * 0.99 * 0.99 =  97%