对接后端接口被挑战能力不行（吐槽贴，不会因为这个问题去挑战什么）

@ZGame 对于加工时他们还有一个说法，“不就加个按钮”，“不就显示个列表”

说破天也是后端偷懒，要是我就直接在业务群 @后端 leader 开喷了，什么鸟玩意。对方还是不妥协就加 bff 层，然后每次需求都提一嘴「因为后端偷懒，我们前端会延长排期」。然后摸鱼时间++，哈哈。
干他妈的就完事了

你如果只是想说服他，可以从原子性的缺点出发。
如果你想你自己爽一点，是不是可以从设计模式出发，例如用外观模式封装一层，就好像和楼上说的一样，别人不愿意改，你可以改。
刚好最近在梳理设计模式，外观模式如下：
https://hi.hyakutake.site/posts/design/Facade

其实如果我是后端，会乐意做这种事情，扩大领域一可以多一些排期，二可以有理由招人加影响力

图片那个不合理，详情类的应该把图片信息带过来。

我觉得后端没问题，从最少知道原则来说，我这个页面明明没用到的数据，后端就不应该返回

如果你的 app 是设计成处理这种大而全的借口的，我怀疑你的 app 架构设计都有问题

之前项目也有类似的场景，一个页面好几个接口取获取数据，后来来了一个大佬，给整合了一下，一次把所有数据都返回了

除非你写的东西一辈子都不会改，否则学会模块化。不管是后端业务还是前端渲染或者两者交互的接口。
使用一个大接口，以后改一次就欲仙欲死。页面出问题，排查过程也太过复杂。
以一个典型的商品展示页举例，展示图、库存、价格、详情、退货条款，你确定要把这些东西全部放一个接口？
怎么有些前端的还想争话语权？我知道这里前端多，可是前端又不需要承担业务责任和架构设计，你们怎么争话语权？能不能做，怎么做是后端说了算。

@Peikon 如果前端在请求你所谓的聚合接口由于各种原因网络波动呢，直接四个模块全没

还是得看具体情况分析，有些情况是绝对不能接受的，比如用户信息明明可以一个接口全给，非得做成用 ID 遍历去查，这种完全就是后端偷懒了，包括你这个图片的请求方式

真是一堆大佬，前端需要管你后端什么原子性，什么架构设计吗，那是前端需要关心的事情吗？业务接口就是业务接口，你见过谁家提供的服务会让你加载张图片还要请求几次才能拿到图片 url 的，居然还有让前端来写 bff 的。。。。 还有啥一个接口 50ms ，四个一起查就要 200ms ？？？我直接？？？？？
也就这些年终端的网速带宽都明显快了， 不然一个请求来回几百 ms ， 加载一个东西你要请求好几个接口那不得慢死了

@qwertyzzz #40 #40 后端更方便， 但是有的数据量大，有的数据量小，分开接口查询是正确的， 否则数据量大的接口卡死了，小的 一个接口跟着遭殃

我觉得模块化是没问题的,大而全的接口应该尽量避免,这样不管排查问题,还是后期改动都会方便很多

这后端不行，只要在接口层在包装一个 Facade 接口不就好了，细粒度的接口依然可以保留

说破天也是前端该去整合数据。。。。

上面还有说让后端整好数据吐给你，后端怎么知道你要什么数据？后端还得去看设计图不成？前端就当个切图仔？

业务代码是业务代码，数据整合是数据整合。总有懒前端试图想混为一谈想让后端全搞了。

你的方案和后端的方案都可以实现需求，看场景和情况选择。我自己的经验来说，我支持后端的方案，后续的升级更方便，前端在不同业务上也许可以复用更多的接口。
对前后端都好，调用接口数量多不一定性能差，还是要看运行环境和场景，有时候可维护性也挺重要的，调用一个接口表面上是一个，实际上响应时常不一定更快，场景不同的情况下效果也不同。

@vacuitym 你觉得请求四个接口遇到网络波动的概率大还是一个接口遇到波动概率大啊，简单查询接口的请求时间绝大部分不是消耗在网络延迟上的吗，服务器查询一个和查询四个的时间哪怕你一个个查那可能也就是 5ms 和 20ms 的差距， 一个网络请求和四个的时间差那就完全取决于网络了。
网络波动请求一个成功概率如果是 70%， 我只需要成功一次就能显示完全， 请求四个那我全部请求成功的概率直接降到只有 3 成不到了

爱改不改，不改的话大不了多写两行代码循环请求一下，又不是不能用，日报还能多写点工时「联调了 xxx 接口」。反正扯皮的功夫都写完了

就你举的例子来看，我站后端

现在是 4 个模块，加一个、减一个怎么办呢

我只能先获取 id ，再用 id 去请求接口。这种也很常见，先返回摘要列表，再按需查详情。

但我了解你的意思，有时候设计的很好，但就几个用户，几个开发，过度设计了。说不定几个月后产品都下线了。但怎么说呢，看公司规模和氛围吧。就相同功能来说，大厂和小厂开发时间能差几倍，是大厂效率低嘛，可能是吧，但个人感觉是精细活多了短平快不太会了

首先最细颗粒度的接口肯定是要存在的，不管是否暴露给前端用。这是后端不能避免的工作量

然后业务数据的组合，就看是谁来做了。从技术上前后端都可以做。就看开发资源的比重了，如果后端看法资源比较多，那就后端做，不然就前端做，因为整体的开发量会相对更低。

但有一种例外，就是业务数据本身有原子性（不是单表的原子性），譬如多张表的数据变动是联动的，且受到其他请求的影响，那就应该后端来出一个包含所有请求的业务原子性接口。

就 op 给的那个图片的例子，其实这个例子举的很抽象。因为不可能有人把图片 id 存一个表，再建一个存 id 和链接映射的表，如果是这样的设计，第一个表完全不需要存在。所以第一个表更大可能本身放的是其他数据，例如用户数据，有个字段是关联用户头像的，存了一个头像图片的 id ，然后单独把头像图片存了一个表 。这种设计是有可能的，这种就属于前端和后端谁做都可以。

一般这种事，整个公司应该有技术方案的设计规范来确实，大部分的业务数据组合是谁做，有什么特例情况等等。不是两个研发自己争辩一下就可以确定的，确定了这一次，后面还有无数次，还是要指定规范。