请教后端同学这种写接口的方式对不对?

2022-01-14 11:44:15 +08:00
 firhome

如:请求一本 book 的订单信息

[以前] 1.请求后端 bookinfo 接口,bookinfo 返回 data:{}, 包含了 book 的基本信息,book 的订单信息和订单状态(出售中,下架 等)

2.前端直接渲染数据即可。

[现在] 1.请求后端 bookinfo 接口 返回 book 基本信息 2.根据 bookinfo 接口获取 book 的 id ,再去请求 bookOrderInfo 获取订单信息 3.根据 book id 和 bookOrderInfo 里面订单 id ,再去请求个接口获取订单状态。

导致我初始化页面要发 3 个请求。

想问下 [现在] 这是个什么情况。是后端不愿意给我们包吗?喊他加数据感觉很艰难。很多东西得前端做。如果是这样的话,是不是后面前端可以写 node 来包一层?

13197 次点击
所在节点    程序员
154 条回复
hun2008hun
2022-01-14 14:49:54 +08:00
没搞懂逻辑,为什么订单是根据 bookid 查;
查询 book 的信息很明显是个基础接口。
chtcrack
2022-01-14 14:51:57 +08:00
前端恐怕不好理解后端为啥要搞这么细化,弄得前端这么麻烦.
按降低服务器负载来说,你一次性拿这本书的所有数据下来,服务器查询数据库假设要 0.1 秒,cpu 占用 0.1%.用户耗费流量 500K.
而细分后,如果客户只是想看看这本书的详情,不看订单,服务器查询数据库只需要查询详情和这点数据,只需要 0.01 秒,cpu 占用 0.01%.用户耗费流量 10K.
意思服务器查询时间和占用 cpu 只是假设值.
一个用户就可以有这么大的区别,如果很多用户一起查询呢?
所以按前端的想法,第一种一次性就拿全部数据的,假设服务器能同时承载 1000 人而不爆炸,那么第二种细分的可能就能承载 3000 人不爆炸,所以你说哪种好?
tabrye
2022-01-14 14:53:13 +08:00
看场景:
1.如果只是 book 单独展示,比如 book 卡片什么的 那当然是以前的方式好
2.如果 book 信息和订单信息要分多个页面分开展示 那还是拆分的好

另外怼后端的时候 建议拉上测试 (..•˘_˘•..)
Hilong
2022-01-14 14:53:19 +08:00
我们后端也是微服务,分了很多个域,但是与前端通信的接口还是有一个聚合域的。这个肯定得后端整合啊。查询数据库肯定比 http 传输快啊
Jackeriss
2022-01-14 15:03:17 +08:00
少个业务聚合层,一般后端做
c6h6benzene
2022-01-14 15:07:06 +08:00
我可能会写三个细粒度接口,再写一个聚合的接口吧,然后丢给前端去处理🤣
sunrain
2022-01-14 15:17:32 +08:00
还好,我遇到过一个更奇葩,会让你请求 bookinfo 参数传 1 ,返回基本信息,在请求传 2 ,返回订单状态,传 3 ,返回.....
1018ji
2022-01-14 15:26:57 +08:00
BFF
NCZkevin
2022-01-14 15:37:41 +08:00
当服务规模比较大的时候,这么拆分没问题,但是拆完之后,中间得有个聚合层,聚合层一般也是后端来弄。
hay313955795
2022-01-14 15:45:59 +08:00
我站后端
chevalier
2022-01-14 15:51:10 +08:00
让后端学习一下,什么叫 接入层
lujiaosama
2022-01-14 15:59:54 +08:00
前两个没问题, 拆成三个就有点毛病了.前端加载就刷一堆接口很好玩么,你们前端组长没有意见?胶水聚合层这活如果还要前端写 node, 那还要后端做什么,crud 让前端来写也没差. 不考虑数据获取是否友好的后端嘛玩意.
manyfish
2022-01-14 16:02:41 +08:00
小项目可以按你说的面向页面开发. 拆细粒度更好维护和扩展, 项目规模变大后,管你什么页面拼接就完事了,剩下的时间来摸鱼:)
lujiaosama
2022-01-14 16:12:26 +08:00
前端后端打架没什么卵用, 真正有效的解决方案是让前端去写后端理解某些场景下拆分接口的必要性, 让后端去写前端感受下接口不做聚合多恶心. 只有前后端一起写的时候才会知道哪里怎么调整才最合适, 而不是前后端各自扯皮.
weipt
2022-01-14 16:15:53 +08:00
回帖的多数时前端吧,一般接口都是按第二种写的,没毛病。
如果按第一个写,那么再有一个 book 库存、book 借出、book 归还等等难道都要写到 data 里吗?可笑。
hhjswf
2022-01-14 16:27:19 +08:00
@hay313955795 这他妈不是搞笑吗,就为了查一个订单状态单独发一个请求,你司前端不把你头打爆?
wupher
2022-01-14 16:30:56 +08:00
即使放多表,后端级联或者 join 也是有办法一次取出的。

让你发三个请求纯粹折腾,还把性能消耗到连接握手上。

建议优化吧。

哪怕返回数据包非常大,也不是用这种方法进行优化。
xiaoyang7545
2022-01-14 16:35:32 +08:00
单纯看, 前两个 还行,毕竟维度不同,第三个纯搞人心态。
ElmerZhang
2022-01-14 16:53:08 +08:00
拆微服务不是这么拆的,应该是后端把原来一个服务拆分成聚合层+几个微服务,而不是只做微服务,让前端去改请求。
你们这个后端大佬八成是个 PPT 党。
wunonglin
2022-01-14 16:54:40 +08:00
@wupher 他这个已经是微服务架构了。不同业务直接不要直接操作,更何况在不在同一个库都不一定

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/828191

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX