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

[svip0dd]

原因：App 开发的时候，首页有 4 个相同的模块，在了解到数据是同一个服务提供的，所以希望后端在提供接口的时候能够一次将这个这四个模块的数据整体返回给我。

结论：服务端的大佬说为了保证接口的原子性，不要做太多业务上的事，他们会开发一个通用的接口，有几个模块让我调用几次。其次服务端考虑到后面可能其他的服务也会调用，所以希望能尽可能通用。

以上结论在前后端对接时他们时常用这个说法对我进行 pua ，我觉得我已经无法接受了，请问各位大佬，这种情况如何反驳？为了保证他们接口的原子性，我大部分页面通常都要 2-5 个接口，甚至更多，比如之前获取图片，因为他们的图片是两张表，一张是图片 id ，一张是 id 对应的图片地址。我只能先获取 id ，再用 id 去请求接口。但服务的通用性在这个说法我在长期对接中发现纯属扯淡，几乎只有我在对接且因为接口调用的多了增加各种复杂场景，如果没有处理好也会影响用户体验。

[yuzhet]

上 BaaS ，自己写

[sampeng]

graphql 解忧愁

[dcdlove]

@0x1247c15 说好听点叫懒说难听点就是蠢货，基本的数据集合，结构设计，宽进严出准则都驾驭不了，这种人就是被淘汰的底层搬运工

[hauibojek]

一般给啥用啥，首页这个 我觉得还好没啥问题。
不过获取图片还要分两步有点离谱了

[dcdlove]

@lscho #95 你这种只会偷懒的流水线搬运工，有时间看看大厂页面接口如何返回数据结构的，不然你这辈子也就是一个底层，30 岁被裁员别抱怨😁

[bugerbig]

同

[loux]

你举得图片的问题是后端在偷懒，后端应该在读取图片的时候把 url 一起返回。但是把前端页面模块数据聚合到一个接口，对后端来说是不合理的，业务无变化的情况下，前端界面改版，后端还得新增一个新版页面的接口？

[xu455255849]

想的都没错，大厂以前解决方案 就是 BFF 模式 前端 nodejs 直接自己封装接口，加一层，后端不考虑接口聚合的事
不过你们多少人啊？如果小公司几个开发，扯这扯那的不是蛋疼， 一把梭完事

[Cyron]

后端这种做法适合于 Open API ，比如 V 站、微博、GitHub 的 Open API ，BFF 层都是第三方集成才需要做的

如果你们是一个业务整体，后端有义务去做聚合接口，SQL 层面的查询优化才是真优化

[me1onsoda]

@helone #13 你说的有道理，但这是后端自己该考虑的问题。天天简历上设计模式吹的飞起怎么解耦，关键时候倒是用上啊，而不是把问题抛给别人

[janus77]

面向工资编程，你说的两种极端都各有优劣，实际业务中不存在谁就一定是正确的。他应该没说你能力不行而是你臆想的吧？
优劣都列出来，锅扔给产品，用什么不是你能决定的。

[dreamHigh]

@ilovegaojianfore 那比如说一个视频播放的功能，在需要 present AlertViewController 的情况下，又到了需要 push 另一个 VC 的情况，希望 present AlertViewController 回来 dismiss 的时候再去 push 这个 VC 的情况，老哥会如何处理

[thingingWoods]

拿数据看下，四个接口和一个接口的用户首屏时间对比下？实在不行拉着产品一起推？

[sunjiayao]

原子性没毛病啊 但是图片 id 和 url 一起返回不巧好是原子性吗。 而且后端暴露了通过 id 获取 url 的接口，被人遍历数据库怎么办？

[clue]

如果是为了可维护性, 后端说的没错, 前端也完全可以把一些接口封装到组件内(比如传入图片 ID 自动展示)
现在 http2 之类的协议也在发展, 减少并发请求其实没那么重要了, 更大的影响是串行请求
只有性能有问题时, 才考虑建 BFF 层用来减少网络通信延时, 但这个会增加系统复杂度

[gitdoit]

我想知道他所谓的原子性 体现在了哪里? 有没有数据支撑?? 还是全凭一张嘴

[me1onsoda]

确实挺乐的🤣那后端存在的意义是什么？代码生成一下 crud 接口，前端自己组合起来做业务算了，那后端确实很优雅，扩展性很强，前端的就业问题也解决了🤣

[vacuitym]

@mcluyu 你开心就好

[learnshare]

有时候都不用理性讨论，当笑话看就行：

1. 后段要通用性、原子化
2. 前端自己解决业务需求

为何前端不直接 SQL 呢

[1252603486]

面向对象里有一个经典的说法就是少用继承，多用组合，就是这个组合该交由后端去组合还是前端组合？如果是考虑到 CS 架构的兼容性的话还是前端去组合这个东西，要不然版本升级会恶心的不行，功能有变化了，后端就需要去做兼容，比如第一个版本是 get(a,b),第二个版本是 get(a,b,c),后端还不能删第一个方法。当然如果是 BS 架构还好，大家一起升级就是了，后端也不用考虑之前的兼容性，直接再写一个组合给前端用就是了。
还有一个和这个很像的就是应该写小方法，然后组合成大方法，而不是直接写一个非常大的方法，复用性很低，和那个算法很像，如果你是全写大方法，数量级是指数级的，写小方法，数量级是线性的

[RogerL]

你这个确实加个 BFF 层就解决了，我遇到这种情况通常就这么干，封装一个 getUserInfo 方法，里面可能会调几个接口，一个 userInfo ，返回 userId ，通过 userId 查询 userAccount ，userAvatar ，userCouponList 等等，然后组合起来返回。
如果后端以后想整合成一个，对我而言也只需要将其他几个多余的接口删除。

[iweus]

其实就是懒，从图片调两次接口就能看出，根本不想给你好好搞

[jones2000]

聚合网管， 网管里面配一个新的接口，直接返回你需要的后台多个接口数据不就可以了。

[wengang285]

让他们提供一个组合接口的接口，你一次性传多个接口和参数，返回结果

[qingyingwan]

在三个大厂干了六年，遇到这种后端，我直接拉他领导。业务接口就不存在原子性的说法

[mengdodo]

你的代码量不是蹭蹭蹭的涨吗，kpi 高得狠

[elevioux]

op 想法和我们公司的前端一样，都希望后端给一个大而全的接口，最好一个页面一个接口，前端组件填数据完事。

但这样后期会增加很多维护成本的。前端稍微调整下页面，后端也要跟着改。甚至为了兼容旧版，又新增一个差不多的接口，前后端都不好受。

[way2create]

我之前有个很小的项目 用户跟并发都很低 但很多页面都有相同的模块 我就按模块去分接口了 前端非要我按页面给他整合 一个页面一个接口 还跟我说这样性能好 一个页面一个接口 我寻思现在也没几个网站这样子搞的吧 不仅感觉没必要而且要我多干活 俺活又部门最多 工资又不高 他天天搞外包 我是不想搞 甚至是不是性能好都待定

[way2create]

你这个确实是后端有点懒了，图片这个，我那个是前端太懒了 什么都想我给他弄的好好的 时间戳都懒得转 不管什么模块都扔一个接口就好 最好还能给他页面按顺序排好不用动脑 只想自己上班时间搞外包

[way2create]

图片地址都要你去单独查接口不太正常，但如果是列表->id->获取详情 这种情况很常见 不可能列表什么都给你返回了

[fregie]

说实话吧,确实是你能力不太行..

[hillwall]

你说的图片这个就是偷懒

[cedoo22]

@darkengine 举个例子

[solangm]

怪不得后端喜欢整高并发的八股文

[lscho]

@dcdlove 大厂都是前端自己 BFF 的你能看到什么？嘲笑别人之前先想想自己的实力，9 年前我就在大厂拿 20k 了，6 年前开始创业到现在，我需要 30 岁去找工作？我 30 岁已经过了哦

[lscho]

@dcdlove 说话之前自己先扒扒大厂页面是不是一个接口返回的，你要能找到一个页面就一个接口数据算我输（极其简单的状态、结果页除外）

[treblex]

1, state:1,2,3,4,5,6 没有 stateName ，你有枚举你直接一起丢回来不完了嘛 / 这里还有那种状态和设计图不一样，前端要组合多个状态字段才能判断是已发货还是已付款，
2 ，传 1 表示某某业务，传 2 表示 xxx 🤮
3 ，json 字段，前端读，前端写，前端自己处理业务逻辑，这个项目甚至价格 折扣 优惠都是在前端计算的😭
4 ，还有不愿意写详情接口的我都不知道为什么(ο´･д･)??
5 ，还有一个不知道某个 java 框架这么设计的，分页超出永远返回最后一页，尽管改起来不难，但是这个思路就很难懂

[to2false]

前半段没毛病，聚合就成了后端输出视图型接口了，需求调整改视图大家一起忙活，如果分拆，可能存在只需要前端调整的情况

后半段，这后端偷懒了整合一下又不费劲，大概率自己就是个写接口不调用过的，完全不考虑易用性的问题

[juzisang]

哪有那么多原子性，又不是写什么通用设计有行业标准，大部分人都是写业务的。
业务稀奇古怪的，接口拆分太多后续迭代前端要改一堆，后端也要改一堆。
楼上学设计不都是按业务模块拆分需求再来写功能，你一个业务接口拆得七零八碎得，后面不会自己都看不懂，还要反过来找前端问业务逻辑吧。

[Outshine]

我想问楼里说聚合的，如果下一次页面改版了，是完全新写一个聚合接口吗？

[juzisang]

楼里是不是很多人原子性和模块化两个概念分不清啊，先查查维基百科这两啥意思吧😂

[HubOwO]

我是客户端，我以我的角度分析：

哪那么多原因，还是因为你们前端不够硬，你们要是够硬，服务端专门有个 mapi ，帮你们聚合接口，服务端之间接口调接口也是家常便饭，还原子性，还分析技术，还搞垮服务器，客户端嘎了，修都是 6 个小时起步的。客户端尽量只做 UI 渲染的工作，光渲染就糟心的了，还跟你聚合数据。我只见过，明显会拖慢首帧渲染的接口，会放到二次请求里。还是你们业务不够重要，不够硬，还有说一个页面十几个接口的，那十几接口很有可能是不同业务做的，或者和当前页面无关的，跟冷起动拉配置相关的。

[rabbbit]

你想，加载图片要调 4 次，浪费了大量带宽，这需要优化。
怎么优化？加中间层，nodejs 聚合接口（）。
既然是 nodejs ，那就需要申请服务器。
接口数量多，是不是可以专人维护中间层的代码？
中间层多了，是不是需要开发配置服务，发布服务？
人手不足，就需要增加 nodejs 开发人员。
随便啥语言都行，举个例子，用 Java 的话岗位多出去了还能找后端工作。

[rabbbit]

一个页面上有 20 张图片，先调一次接口 a 获取 20 个 id ，然后分别调 20 次接口 b （每次传一个 id ）获取 20 个图片地址？还是调用一次接口 b （同时传 20 个 id ）获取 20 个图片地址？
如果是 1 ，谁家 app 是这样做的，自己 DDOS 自己吗？能说下名字发出来给大家看看吗？

[FarmerChillax]

你需要一个 BFF https://imgur.com/VUWFktU

[rabbbit]

补充一下，一个页面调多个接口是很正常的。
你可以单独把 api 放在一个文件夹下，常用的、需要聚合的接口可以封装成一个通用的函数。

[monologue520]

BFF? 原子性? 简直离谱! 要知道薪水是面向业务和同事合作编程达到良好用户体验获取,不是随心所欲活在自己世界中自由发挥的.
我觉得你应该向你的 leader 反映这种情况,不能惯着这个臭毛病

[ZoR]

谁嗓门大就听谁的

[pyKane]

感觉把接口当成了数据库“代理” 的功能了。把一件事情变的过于复杂了。
前端（客户端） 是恨不得直接去操作数据库得了。API 存的意义是啥呢？
架构不应是这么设计的，API 的任务应是完成业务的原始设计，和一些数据上的业务逻辑。
像把图片放在两个表，没什么问题，但，拿图片也要走两个 API 接口这就是有一些蛋疼了。把架构变的过于复杂和“灵活“了。

[Hopetree]

如果你说多个接口会影响你的开发，那这个事情多半没人会管，但是如果多个接口会导致页面性能受到影响，那这个事情就会有人去推动了，所以，你懂吧

[ChefIsAwesome]

后端又菜又懒。
例如我做个 10 个条目的列表页。先取一遍 id 。完了每个列表项有 5 个数据，我是不是再从 5 个接口去取？我是按顺序请求还是并行的请求？这么多请求，中间有一个请求失败了，我是重试这个请求，直到成功，还是先放着不管，最后再来请求？最后还是失败了，我怎么办，就那一个字段的内容空白？就算我写了个完美无缺的队列出来了，让用户看着菊花转两分钟吗？
现在还有人知道雪碧图吗？费老大劲把好多图片拼在一起，就为了省几个请求，让用户感觉快一点。

[ShuWei]

你说的第一个场景，四个模块，如果数据类型都差不多，并且只是简单的查询，我可能会倾向于提供一个聚合接口，允许前端传递参数决定要同时拉取哪些模块的数据，但是如果有一些复杂的筛选、排序之类的参数，可能就不会考虑提供聚合接口了，毕竟逻辑太复杂不灵活也容易出错。而第二个场景，就很奇怪了，我肯定会包装之后再提供给前端，要先查 id ，再查图片地址，有点坑了，直接返回图片地址比较好

[cookgiao]

可以来我们群 https://t.me/web3cq 互相交流一下经验，里面有很多行业的大佬。学习一些技术。说不定能解决你面临的问题。！

[asuraa]

op 应该经验不够丰富，其实你后端的做法是没错的，这种问题我以前也纠结过。

[gitrebase]

后端在 service 层一定要做到很好的原子性、模块化，至于数据聚合是在后端的 controller/handler 层、或是 bff 层、或是在前端的数据层，还是看前后端的“地位”/“经验”吧

[tcper]

对于后端来说，整合接口确实增加了复杂度

不过如果每个服务都是一个接口，我们之前的页面一上来可能调 20 个接口，最后性能绝对肉眼可见受影响

你可以申请自己做一个前端的接口合并，然后吹牛逼升职加薪，怎么看都是好事情

[dayeye2006199]

朋友你是不是在找 graphql

[GoogleQi]

没必要纠结，我觉得可以看看大厂的一些类似的网站，看他们是怎么请求的，看他是按页面全部塞给你还是拆了很多次请求，多找几个看看

[version]

习惯就好.大部分 crud 后端是不会听..
如果后端是部门老大.前端还是忍忍吧.大不了 await Promise.all
或者自己聚合一层 dto 也是可以的.当后端接口是单表数据库就好
如果是懂点全栈开发会很理解的你需求.接口拿到基本渲染就好.逻辑都少写

[livin2]

BFF 层正解，不过我看 OP 这情况，盲猜贵司前端没法申请生产服务器哈哈。

[LitterGopher]

请问写一个“大接口”除了前后端对接方便还是其他的好处么？

[LitterGopher]

@LitterGopher #161 感觉自己这说法有问题，我补充一下，因为自己写后端，同时也比较认同贵公司把接口拆分为多个的做法。但有时候也会想我直接一次把所有数据都返回给前端难道不好么？但是自己思考之后认为总的来说拆分开会更好一些（说是一些，其实是太多）——但这是我作为后端开发的个人看法，难免局限，所以也想了解一下前端开发者对此的看法。

[RightHand]

就移动网那破比环境，拆分接请求就是是给用户找不自在，app 的环境网络请求延迟都是 50ms 起步的，你一个接口服务 50ms ？还有说成功率的，拆分请求，基本都是所有的请求一起死，然后一起重试。后端做的是没错，但不符合移动网的环境，最不济也要做个接口聚合。

[afxcn]

自己把后端代码干了，前端想要什么接口就自己搞。

我们公司的 gskctl 正在内部测试阶段，想要玩的可以 @ 我。

https://gostartkit.com/docs/getting-started/

我们通过这样的标签来描述类之间的关系。

// Entity model
// @Entity tableName="entities"
type Entity struct {
// @PrimaryKey
ID uint64 `json:"id"`
// @Ref Application.ID
ApplicationID uint64 `json:"applicationID"`
// @DataType mysql=varchar(127)
EntityName string `json:"entityName"`
// @Comment "-1 deleted 0 pendding 1 valid"
Status int `json:"status"`
CreatedAt *time.Time `json:"createdAt"`
UpdatedAt *time.Time `json:"updatedAt"`
}

[Promtheus]

接口原子性没毛病 不过我们这边的移动开发也是想要大而全的接口。。我一般都顺手给了。实在没心思和他们 battle 反正项目也不是我的

[dj721xHiAvbL11n0]

@NessajCN #32 你一定是后端，App 开发又不是网页，后面要变，你觉得是变后端方便，还是 App 重新打包发布方便。还有谁跟你说的前端弄不奔服务器的，如果没有代码缺陷，那服务器奔溃一定是前端导致的

[timelessg]

正常来讲，后端业务到 native 还得有一层专门去做这些业务无关的工作，但小公司嘛没这个精力。。

[NessajCN]

@x2420390517 我是全栈，接口和前端都我自己写。
产品发布前我肯定哪个改起来方便改哪个，
但是发布后的更新我一般不去动服务端，因为每次重启 production 服务我都提心吊胆的。
客户端打个包传个新版我就从来没心理负担，大不了撤回了再发一版。
当然这是个人观点，你觉得后端改起来容易那你说的都对

[shunia]

这后端不会防御性编程啊，就他这 CRUD 的搞法，哪天你硬气点去砸人家后端场子，第一个开的就得是他，一点不可替代性都没有。

技术深度用于提升项目上限，但是实际工作中，99%的工作是处理业务流程，谁得流程谁才能站得住脚。既然他主动放弃了流程，那你完全可以弄一个 nodejs 的 BFF ，让他失业。而你还可以额外获得一身新技能，何乐而不为呢。

[Arguments]

@Hilong 说的太对了，凭什么要让前端做接口整合，干后端的活

[accelerator1]

自己写呗，这种数据聚合处理又不难，写个 BFF 层。
再说，都上 BFF 了，再搞个 SSR ，绩效这不就上去了。

[suyuyu]

不就是几个页面。不就是几个接口

[nuonuojump]

我搞过一个模块，是个大列表， 主题页面有点赞数量，评论数量，评论前三条（包含头像昵称状态），多种条目类型（图片(多张)/音频/视频/文本内容），创建者，创建者头像，在线状态.....。然后前端需要的是，先去拉一个接口，接口有列表的条目的 id ，然后拿 id 去查条目的内容，如果是图片 还得去拼接图片链接，然后拿条目 id ， 去查点赞数量，，去查评论前三条的 id ，然后拿评论 id 去查对应条目的回复人头像，昵称 状态......然后拼接组合。当时还叫微服务，然后一套下来，一个列表能转圈半天， 但是就是不给聚合接口，开局就给一个 id 剩下自己拼，查。完成后，直接去了其他项目组，爱谁维护维护。

[frzh]

原子个屁，首页除了一些通用配置或广告位，其它哪个不是个性化业务，碰到这种就直接硬刚，刚不过就上升，再加个指标统计首页数据时延，下次直接把数据甩他们脸上。

[FakerLeung]

我现在也是这样的，我们是一个个的画图 canvas ，然后要初始化，一个 canvas 初始化需要请求 22 个接口（你没看错，就是 22 个接口），打开 5 个 canvas 就是 110 个接口，还要考虑时序，真的人都疯了。还好我们是本地应用，每个接口基本都是 100ms 以内

[MuscleOf2016]

前端学 node 就是干这些聚合数据的活的。

[palfortime]

id 和 url 分离有没有可能是两个服务，有个专门负责管理图片的服务？

[SyncWorld]

看了一圈就我躺平了？遇见这种事，我都不带管的，你说怎么接我就怎么接，绝不说多说一句话，需求绝不过脑子。你建议了人家只会觉得你有问题。
你只是个小开发，拿着小开发的钱就别操架构，产品的心，只能是自己给自己徒增烦恼罢了！

[zzl22100048]

> 图片是两张表，一张是图片 id ，一张是 id 对应的图片地址。我只能先获取 id ，再用 id 去请求接口
这个是你们后端有问题
常规做法是 GET {SERVICE}/id -> 302 真实地址，而不是返回 url

[yrzs]

这是让你自建 BFF

[skyqiao]

照你们这么说要啥后端啊，直接用云端数据库不就好了
很多后端就直接用框架把整张表返回了，要多恶心有多恶心。

[cccssss]

每个 TCP 链接 3 次握手
前端 N 个请求=用户到你们服务器的网络延迟*N*3 次
加一层 BFF=用户到你们服务器的网络延迟*3 次+服务器内部*N*3 次
哪个用户体验好让你们后端的领导自己去算
你们要都是长链接啥的另算

[nenseso]

我觉得这种接口融合调用的层应该放在后台做。因为前端每多调一个接口，失败的概率就会叠乘，假设一个接口的调用成功率在网络影响下是 99%,一个页面要调 5 个接口才能完整正常显示，那么实际成功率是 95%，这就已经损失了 5%了。在产品看来是不可接受的。

[MoYi123]

@nenseso 成功率还能这么算的? 你是在用纯 udp 协议吗?

[qwertyzzz]

@Rehtt 4 个会>=200 吧

[duan602728596]

所以说嘛，饭碗都是自己扔掉的。

[nenseso]

@MoYi123 就普通的 HTTP 请求啊，也不可能每个 HTTP 都是 100%吧

[ccfly]

我前后端都写 看到楼上说 说破天也是前端来整合数据 我都无语了 数据稍微大一点 前端处理起来和后端处理起来哪个更好？ 浏览器本来就应该尽量减少请求和计算 数据都处理好发给前端 用户体验更好

[ccfly]

越是复杂的业务 本身就应该提供业务接口 你只提供所谓的数据接口 那后端是干啥的 数据库的中间商？ 那前端直接自己写 sql 去查不好吗

[sayitagain]

@htxy1985 #33 估计就是个平台通用的上传模块，所有文件上传都走这里，业务只存返回的 id 。

[mmdsun]

RESTful x
GraphQL ✔

[mnhkahn]

这不就是大前端场景么，搞起来。
另外，这种谁做都一样的东西，往前走一步开阔天空的

[cnoder]

@nenseso #183 这个说法比较合理，但前端一个接口也应当只展示当前页面上一部分的内容，如果前端需要查 x 个接口来展示一个图表，我是不介意融合的。

[siweipancc]

遇到这种我只会支持楼主，你要部门树？我整个树 load 给你，什么懒加载，不存在的，开发效率第一。然后某大佬整天抱怨内存回收寄了

[xd666888]

一次性返回 App 首页 4 个模块的数据，除了前端对接方便点，我想不到其他的任何好处。

[xd666888]

@RightHand 加个请求失败重试机制不就行了，为什么要一起请求一起重试？

[RightHand]

@xd666888 肯定是要最快第一屏显示啊，你就这么喜欢打开新页面就等 1 分钟啊

[Campanula]

后端其实应该把 html string 拼好直接返回？

[sidyhe]

后端人员从业者说下看法
在功能实现上颗粒度越小越好, 但这种接口不太可能直接给前端用
纯粹的 crud 需要加工, 向前端提供相对上层的接口, 以功能为单位而不是数据
以图片为例, 需要显示的应当向前端提供图片 ID 以及数据, 单纯让前端调用两次接口毫无意义, 还会增加调用时长
当然接口需要权衡, 不能照着数据写, 也不能照着 UI 写, 这需要经验的积累

[KgM4gLtF0shViDH3]

@lscho #94 原来你写的东西都是一个图片请求一次接口🤣