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

查看 468|回复 48
liumao   
一个耗时 200ms 的接口 包含所有,
4 个每次耗时 20ms 的接口 , 你怎么选??
除了前端外, 后端、leader 基本都会选后者
NessajCN   
@angenin 是我就直接在业务表里面存路径了,还存个 p 的 id
htxy1985   
@qwertyzzz 你看,你也同意是「已经提供的数据」。那你自己整合一下呗。前端写肯定比后端写简单啊。毕竟前端弄不崩服务器,后端可以。
BiChengfei   
图片分成两个表是为什么? id 和 url 的关系还留着扩展成一对多,多对多的可能?
lazyfighter   
你是客户端,他是服务端,大致属于 B/S 模式,服务端皆苦应该符合外观模式,对客户端隐藏系统的复杂度。应该针对不同的客户端封装不同的接口
angenin   
需要一个聚合层, 面向 C 端的一般都不是原子性的接口, 聚合服务支持业务逻辑面向不同端的定制, 此时你只需要反驳一句,如果 web 跟小程序逻辑不一样,那你后端接口是否还是原子性的, 原子性没有问题但是更多的是面向自己的服务领域做到高内聚低耦合,当真正的面向 C 端业务场景的时候,我们应该做的是聚合多个原子能力,对外输出业务场景能力。
dongtingyue   
@htxy1985 对,有可能是一对多,如果金融行业,用户的实名认证信息,过期了要补充新的,但不能删除以往的图片,在图片表里记录用户 id 和图片类型,必要时可以查出所有以往的材料,也不叫图片表应该叫文件表。
angenin   
图片那个例子不合理吧,原子性不是这样定义的。
一个请求变两个请求,前端并发量也成备。
wangritian   
@liumao #31 如果文件不能删,并且必要时需要查出用户以往上传过的文件,阁下应该如何处理

qwertyzzz   
后端这样设计是合理的,上面有提到 BFF 层,还可以在前端封装一个并发请求,合并拿返回数据的通用方法
这要求后端需要支持 h2 协议,必须支持
您需要登录后才可以回帖 登录 | 立即注册

返回顶部