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

[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 架构还好，大家一起升级就是了，后端也不用考虑之前的兼容性，直接再写一个组合给前端用就是了。
还有一个和这个很像的就是应该写小方法，然后组合成大方法，而不是直接写一个非常大的方法，复用性很低，和那个算法很像，如果你是全写大方法，数量级是指数级的，写小方法，数量级是线性的