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

[xylophone21]

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

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

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

[kiracyan]

业务上肯定分开好

[frandy]

聚合接口

[xuanbg]

原则上只提供领域接口，特殊情况可以酌情提供少量的聚合接口。

[ChanKc]

1 更接近 restful 2 更接近 graphql ？我猜的

[ppphp]

都提供 1 接近 restful 和 graphql 2 接近 rpc 不给聚合接口调用的人唧唧歪歪巨烦

[maemual]

前端在服务器上起个 node server 做接口聚合，皆大欢喜。😂

[qwerthhusn]

取决于前端硬不硬

[qq1340691923]

php 作为胶水层聚合后端 api

[xylophone21]

能简单说一下原因吗？
在服务的最底层，肯定是基于领域来开发的，但聚合这件事本身逃不掉，要么在后端做，要么在前端做，所有这里仅讨论放到哪里做合理。

>> 小插曲：顺便写到这里想到一个问题，大家对前后端的理解，会不会不一致？比如 H5 端、App 端肯定算前端，那么 node 端呢？我理解严格来说 node 端是不严谨的说法，但为了交流方便这里借用一下这个概念。或者严谨一点，如果用一个 nodejs （获取其它技术） 把业务接口进行了聚合，那么这个 nodejs 算前端还是后端？（我后面的描述把这一部分仍算作后端，如果大家定义不一致可以探讨）

继续探讨放哪里合理的事，我个人认为放到后端因为：
1. Android 、iOS 绝大多数情况下，只需要做一次聚合逻辑
2. API 形式的对接，更容易做测试。（不是说不能做，但更容易，可以探讨，我也没有在查到太多在 App 内做“单元”测试的成功案例，注意这里“单元”打了引号，因为严格来说，直接测 API 不属于单元测试范畴）
3. 调整业务逻辑不需要用户升级（仅限 APP ）
4. 日志更容易获取，方便解决问题。（同样是相对来说，我了解 App 有各种日志上传的方案，但这个因为比较敏感，网上资料不多）

另 @ChanKc @ppphp 提供的 graphql，之前了解不多，需要去细看一下，感谢

[suyuyu]

我被逼着做了聚合，面向页面接口

[ybonfire]

前后端之间做一层聚合层不就行了？

[Tokiomi]

@xylophone21 我愿称之为防腐层

[wangritian]

如果能上 h2 协议，觉得聚合的优势不大，反而增加维护成本

[zzx0403]

我愿称之为胶水层

[1107139144]

领域接口

[xylophone21]

@ybonfire 对，那么这一层应该放在哪里？ App 里？云上的某个模块，比如 node ？后端的某个模块里？


@wangritian 如果不上 HTTP/2.0 的化，性能会是另外一个问题，如果上了的话，你怎么看我前面提到的几个问题？

[kkeiko]

前端调后端是走公网 API 什么协议无所谓，API 肯定服务于当前页面交互的业务逻辑。有的公司 API 层用 PHP 或 Python 写，就归到后端里。有的公司用 Node 写，也可以归到前端里。API 层就是你说的聚合接口，这是必要的。API 层要走内网 rpc 调用多个后端 service，这才是真正的后端，也是你说的领域接口。

[kkeiko]

真正的后端一定是你所谓的领域接口，后端是要抽象业务逻辑越做越通用的，而不是越做越定制的。API 层也叫胶水层也是一定要有的，至于胶水层是后端写还是前端写，取决于大环境和当下团队配置，无优劣之分。

[Mithril]

GraphQL 一把梭
梭完了发现你得写一堆 Loader

[angryfish]

我作为一个友好的后端开发。给前端提供页面级别数据接口