这是一个创建于 1923 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家一起探讨一下，顺便做个小调查
- 领域接口，即接口按领域、业务模块划分，用户、订单、商品等。前端需要多次访问，聚合，逻辑。
- 聚合接口，即后端根据页面把这些模块按一定逻辑聚合到一起，前端少量几次请求即可
举例： 通过商品信息获取评论信息，通过评论信息中的用户 id 获取用户信息
 | 1 kiracyan 2020-07-31 12:05:38 +08:00 业务上肯定分开好 |
 | 2 frandy 2020-07-31 12:11:59 +08:00 聚合接口 |
 | 3 xuanbg 2020-07-31 13:15:17 +08:00 原则上只提供领域接口，特殊情况可以酌情提供少量的聚合接口。 |
 | 4 ChanKc 2020-07-31 13:20:03 +08:00 via Android 1 更接近 restful 2 更接近 graphql ？我猜的 |
 | 5 ppphp 2020-07-31 13:38:34 +08:00 都提供 1 接近 restful 和 graphql 2 接近 rpc 不给聚合接口调用的人唧唧歪歪巨烦 |
 | 6 maemual 2020-07-31 13:47:12 +08:00 via iPhone 前端在服务器上起个 node server 做接口聚合，皆大欢喜。 |
 | 7 qwerthhusn 2020-07-31 13:50:53 +08:00 取决于前端硬不硬 |
 | 8 qq1340691923 2020-07-31 13:53:06 +08:00 php 作为胶水层聚合后端 api |
 | 9 xylophone21 OP 能简单说一下原因吗？ 在服务的最底层，肯定是基于领域来开发的，但聚合这件事本身逃不掉，要么在后端做，要么在前端做，所有这里仅讨论放到哪里做合理。 >> 小插曲：顺便写到这里想到一个问题，大家对前后端的理解，会不会不一致？比如 H5 端、App 端肯定算前端，那么 node 端呢？我理解严格来说 node 端是不严谨的说法，但为了交流方便这里借用一下这个概念。或者严谨一点，如果用一个 nodejs （获取其它技术） 把业务接口进行了聚合，那么这个 nodejs 算前端还是后端？（我后面的描述把这一部分仍算作后端，如果大家定义不一致可以探讨） 继续探讨放哪里合理的事，我个人认为放到后端因为： 1. Android 、iOS 绝大多数情况下，只需要做一次聚合逻辑 2. API 形式的对接，更容易做测试。（不是说不能做，但更容易，可以探讨，我也没有在查到太多在 App 内做“单元”测试的成功案例，注意这里“单元”打了引号，因为严格来说，直接测 API 不属于单元测试范畴） 3. 调整业务逻辑不需要用户升级（仅限 APP ） 4. 日志更容易获取，方便解决问题。（同样是相对来说，我了解 App 有各种日志上传的方案，但这个因为比较敏感，网上资料不多） 另 @ChanKc @ppphp 提供的 graphql，之前了解不多，需要去细看一下，感谢 |
 | 10 suyuyu 2020-07-31 13:55:32 +08:00 via Android 我被逼着做了聚合，面向页面接口 |
 | 11 ybonfire 2020-07-31 14:25:21 +08:00 前后端之间做一层聚合层不就行了？ |
 | 12 Tokiomi 2020-07-31 15:05:37 +08:00 @xylophone21 我愿称之为防腐层 |
 | 13 wangritian 2020-07-31 15:18:48 +08:00 如果能上 h2 协议，觉得聚合的优势不大，反而增加维护成本 |
 | 14 zzx0403 2020-07-31 15:18:48 +08:00 我愿称之为胶水层 |
 | 15 1107139144 2020-07-31 15:41:29 +08:00 领域接口 |
| 16 xylophone21 OP @ybonfire 对，那么这一层应该放在哪里？ App 里？云上的某个模块，比如 node ？后端的某个模块里？ @wangritian 如果不上 HTTP/2.0 的化，性能会是另外一个问题，如果上了的话，你怎么看我前面提到的几个问题？ |
 | 17 kkeiko 2020-07-31 15:58:48 +08:00 前端调后端是走公网 API 什么协议无所谓，API 肯定服务于当前页面交互的业务逻辑。有的公司 API 层用 PHP 或 Python 写，就归到后端里。有的公司用 Node 写，也可以归到前端里。API 层就是你说的聚合接口，这是必要的。API 层要走内网 rpc 调用多个后端 service，这才是真正的后端，也是你说的领域接口。 |
| 18 kkeiko 2020-07-31 16:03:08 +08:00 真正的后端一定是你所谓的领域接口，后端是要抽象业务逻辑越做越通用的，而不是越做越定制的。API 层也叫胶水层也是一定要有的，至于胶水层是后端写还是前端写，取决于大环境和当下团队配置，无优劣之分。 |
 | 19 Mithril 2020-07-31 16:03:44 +08:00 GraphQL 一把梭 梭完了发现你得写一堆 Loader |
 | 20 GBdG6clg2Jy17ua5 2020-07-31 16:19:08 +08:00 我作为一个友好的后端开发。给前端提供页面级别数据接口 |
 | 21 woodensail 2020-07-31 16:22:58 +08:00 看场景，我这边前端核心业务是有自己的专属后端开发进行接口封装的。 很简单的一个情况，前端首屏展示就涉及几十个接口，需要根据数据内容去有选择的查询其中一部分。而且各接口互相依赖，完整的一遍走下来需要三四个来回。所以前端直接请求在性能上是不可接受的。这时候就需要后端来做接口菊科了。 相反有些列表页基本上一个接口搞定首屏的，就不需要专门的接口聚合了，直接请求业务接口就行。 |
 | 22 wc951 2020-07-31 18:00:47 +08:00 via Android 显然应该是领域接口，聚合应该交给中间件来做 |
 | 23 powerfj 2020-07-31 18:04:20 +08:00 领域接口 + 聚合接口都存在的方式 聚合可以用 graphql 来解决? |
| 24 wangritian 2020-07-31 18:09:11 +08:00 @xylophone21 我更倾向于在 APP 聚合，让后端接口层更原子化，尤其是产品快速迭代时期，减小前后俩部门的沟通成本和联调复杂度。UI 变化时，前端仅需改变组装方式，只有业务逻辑变动时需要后端针对某个模块做修改。两个数据有交叉的页面，也只用维护一个接口。不太了解 APP，是不是原子接口也更容易封装组件。如果某个模块发生异常，其他数据可以正常显示。当然讨论前提必须是 h2，1.1 要么阻塞排队要么创建新连接，肯定无法接受 |
 | 25 itbeihe 2020-07-31 18:10:23 +08:00 BFF （ Backends For Frontends ）架构了解下，后端现在是不想写接口聚合服务的，多数成了前端用 node 搞这一层。 |
| 26 xylophone21 OP @itbeihe 跟聚合接口有点类似，有什么好的框架吗？ |
 | 27 panlatent 2020-07-31 20:32:18 +08:00 聚合可以使用 GraphQL 来做更轻松点，此外后端应该还有一层应用层，其中可以包含一个数据转换层，当然最好别强为聚合而聚合，合理的拆分和搭配可能会更好一些。 |
 | 28 redford42 2020-07-31 23:17:42 +08:00 领域接口 |
 | 29 realpg PRO @xylophone21 这个场景下，这个端归谁管视为啥端。 如果是后端团队不影响既有后端另开了一个聚合层，跟后端配合紧密，算后端 前端为了方便另开个层聚合后端接口，不能影响后端，也不能与后端高度配合本团队调试，视为前端 |
 | 30 changwei 2020-08-01 19:03:49 +08:00 via Android 建议对外的系统用聚合接口，防止被黑客恶意请求部分接口，导致出现数据不一致问题。（例如电商购买商品后要通知财务系统扣款或者物流系统扣库存，但是可能黑客会只请求其中一个领域接口，其他不请求，导致数据不一致。） |
 | 31 luozic 2020-08-01 21:24:17 +08:00 via iPhone 内部领域接口，中间搞个胶水层包装成聚合接口 |
Select Language