尽量将逻辑在后台去实现,却不是在前台实现这种逻辑正确吗？

Question

尽量，不较真，就是那种前台后台实现起来复杂度差不多，或者前台实现起来可能稍微简单一点的，都放在后台去实现比如刚才我要查询一个 所有人，假如我之前有两个接口，查询男人，查询女人，两个接口返回的数据结构一致，举个例子，不抬杠在前台就可以调一遍男人接口，再调一遍女人接口，然后将两个数组组合起来在后台就是新建一个查询所有人接口，然后在这个接口里面调用男人接口，女人接口，将数据组合，返回给前台我觉得这种事情在后台做比较好，因为前台代码规范不好，代码多显得比较乱，而且放在前台会发起两次请求，对性能也不好；在后台将它合并成一个请求更加简洁优雅，我觉得

Answer 1

前端少写逻辑，一来后面不好维护，二来如果哪天需求变了，改前端代码还需要重新发布太麻烦。

Answer 2

没有什么标准答案，你说你两次请求，他说他设计目的不仅仅是支持你一个web，可能还要支持app或者提供服务给第三方，然后大家都不想改就出现了中间层。
但就这个例子而言，个人觉得是应该由后端实现类似于/person/?:gender的查询接口，或者实现两个接口，查询性别和查询所有，而查询男人和女人没什么逻辑差异的话大概是一个接口。

Answer 3

不是为什么是这个逻辑
不应该是男女某个标识 0 1/ 所有人 2
然后后台一个接口去跑SQL查表2的数据然后返给前端麽
其实你这个案例来说的话,前后端都可以 不涉及某些安全信息,性能方面也没多大影响 俩个请求和一个请求的区别
而且整合在后端也不一定说性能多快

Answer 4

正确。但是有时候，后台不愿意做，你们前端又没人给你说话的时候，就只好妥协了。。

Answer 5

其实应该是有后端来做的, 毕竟少发一次接口.
实际呢 后端应该是不愿意去做的. 也正常. 前端也好做 用peomise all 也挺完美的 没啥大区别

Answer 6

尽量在后台写逻辑，后台非要你前端写，你还没他资历高，那就自己写喽

Answer 7

楼主没有了解过SinglePage单页应用吗？做好团队规范后，无论是重后端还是重前端都可以。相对来说，重前端的模式有助于减少服务器的开销，可以有效地降低成本。

Answer 8

我以前的时候就遇到过这种。一心只想着增删改查，一点逻辑都不愿意做的后端
个人觉得还是要去看实现逻辑。比如这个接口。
难道不应该是男人女人都在一个表里面吗。。如果他们只有性别不同得话
然后
传一个参数 -1男人
0所有人
1女人
这个样子进行获取数据不是会更好一点吗？