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

[firhome]

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

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

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

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

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

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

[wangkun025]

后端的锅。
后端不是菜鸡就是神经病。

[junnplus]

1 楼说的对

[firhome]

@wangkun025 这个后端好像以前做微服务的。是新来的大佬。现在老后端同学都笑我们是 面向微服务的前端开发

[xmumiffy]

所以才有个东西叫中间层

[zepc007]

2 楼说的对

[smy14520]

数据分开存储的,书籍是一个微服务,订单是另外一个微服务,

[Cowhitewhite]

什么辣鸡后端，你也应该反驳他

[rbe]

这种模块拆分非常细致的，很适合用上 GraphQL

[javapythongo]

你们要一个 bff 中间层作数据聚合

[hecz]

拆 12 没问题，第三个看业务场景吧

[ArthurTsang]

book 信息和订单信息分 2 接口没问题, 订单信息不含状态有点奇怪

[kylix]

我做过后端，我也觉得 2 楼说的对。

[jtwor]

微服务把业务颗粒化太细了，如果是小项目没必要，让他聚合一下也可以把

[Rwing]

其实后端这么做也没错，所以一般会有一个 bff 层来处理，而且一般前端人员可以写 bff 层

[swulling]

后端可以通过参数来控制

比如 bookinfo 接口默认只返回 book 基本信息，增加 with_order=true 就增加订单信息

[lscexpress]

其实说白了就是后端懒，多写一个接口整合已有的三个接口信息就完了的事

[AoEiuV020CN]

这后端就是真的面向数据库编程，只会 curd 了，一个表就一个 curd ，别的让你前端自己搞定，

[hahasong]

做了微服务拆分，但是应该加一层 api 层专门整合暴露前端接口。你确实成了面向微服务前端

[ragnaroks]

拆的太细了，你们打一架，谁赢了听谁的

后端赢了你就 request<getBookInfoList,getBookOrderInfo,getBookOrder>().waitAll()

你赢了后端就 return json<getBookInfoList,getBookOrderInfo,getBookOrder>()

[einq7]

那请问遇到这种情况，该如何有理有据的反驳呢，比如说这种写法有什么弊端呢