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