大家的项目前后端接口是领域接口还是聚合接口？

[xylophone21]

大家一起探讨一下，顺便做个小调查

1. 领域接口，即接口按领域、业务模块划分，用户、订单、商品等。前端需要多次访问，聚合，逻辑。
2. 聚合接口，即后端根据页面把这些模块按一定逻辑聚合到一起，前端少量几次请求即可

举例： 通过商品信息获取评论信息，通过评论信息中的用户 id 获取用户信息

[woodensail]

看场景，我这边前端核心业务是有自己的专属后端开发进行接口封装的。

很简单的一个情况，前端首屏展示就涉及几十个接口，需要根据数据内容去有选择的查询其中一部分。而且各接口互相依赖，完整的一遍走下来需要三四个来回。所以前端直接请求在性能上是不可接受的。这时候就需要后端来做接口菊科了。

相反有些列表页基本上一个接口搞定首屏的，就不需要专门的接口聚合了，直接请求业务接口就行。

[wc951]

显然应该是领域接口，聚合应该交给中间件来做

[powerfj]

领域接口 + 聚合接口都存在的方式
聚合可以用 graphql 来解决?

[wangritian]

@xylophone21 我更倾向于在 APP 聚合，让后端接口层更原子化，尤其是产品快速迭代时期，减小前后俩部门的沟通成本和联调复杂度。UI 变化时，前端仅需改变组装方式，只有业务逻辑变动时需要后端针对某个模块做修改。两个数据有交叉的页面，也只用维护一个接口。不太了解 APP，是不是原子接口也更容易封装组件。如果某个模块发生异常，其他数据可以正常显示。当然讨论前提必须是 h2，1.1 要么阻塞排队要么创建新连接，肯定无法接受

[itbeihe]

BFF （ Backends For Frontends ）架构了解下，后端现在是不想写接口聚合服务的，多数成了前端用 node 搞这一层。

[xylophone21]

@itbeihe 跟聚合接口有点类似，有什么好的框架吗？

[panlatent]

聚合可以使用 GraphQL 来做更轻松点，此外后端应该还有一层应用层，其中可以包含一个数据转换层，当然最好别强为聚合而聚合，合理的拆分和搭配可能会更好一些。

[redford42]

领域接口

[realpg]

@xylophone21
这个场景下，这个端归谁管视为啥端。

如果是后端团队不影响既有后端另开了一个聚合层，跟后端配合紧密，算后端

前端为了方便另开个层聚合后端接口，不能影响后端，也不能与后端高度配合本团队调试，视为前端

[changwei]

建议对外的系统用聚合接口，防止被黑客恶意请求部分接口，导致出现数据不一致问题。（例如电商购买商品后要通知财务系统扣款或者物流系统扣库存，但是可能黑客会只请求其中一个领域接口，其他不请求，导致数据不一致。）

[luozic]

内部领域接口，中间搞个胶水层包装成聚合接口

[kgloveyou]

@ybonfire 那么问题来了，聚合层后端做，还是前端做？