后端逻辑依赖前端是否正确

[mokevip]

一步操作可能涉及到多张表，而前端已经全部获取到表数据

后端为了省事 /为了避免过多的查询，操作数据全部从前端获取

导致前端重逻辑，后端发现什么问题都是前端没处理好

在我看来，这样的后端已经成为前端的数据库读取工具了

[dqzcwxb]

问你们技术老大,网友不知全貌不予置评

[Renco]

我理解的前后端，一般数据和业务逻辑操作大多数都是后端去处理。前端负责交互和展示的内容,会捎带一点逻辑。但是具体不知道你们是什么业务。同上不知全貌不予置评

[FreeEx]

后端非常不合格，连最基本的「不要相信任何来自前端的数据」这个都做不到。
什么网站？告诉网友能把你们薅的毛都不剩下，之前很多一分钱买一大堆东西的就是因为商品金额是从前端传给后端了。

[westoy]

@FreeEx

看场景， 企业内部用的系统很多都是几个表十几个表 join ， 一个查询可能半分钟， 这种情况你要生成个 excel 或者 pdf 吐给当前操作用户， 我也更倾向数据从前端拿

[28Sv0ngQfIE7Yloe]

@westoy

这种场景为啥不做 ETL 或者使用 OALP 分析型数据库 物化视图

[mokevip]

@dqzcwxb 小公司，技术老大就是后端哈哈，因为我们涉及到多端，所以一处逻辑复杂，我们要在多处重复实现。。

[dtdths1]

想起之前一个奇葩传统行业公司下的互联网部门。一个查用户订单的逻辑，后端大佬让前端先请求用户下订单 id 列表，再让前端遍历 id ，每个 id 请求一次详情。我跟他说没这么做的，你把接口合一下有那么难吗，他说合一起就不是原子化了，不符合规范，我也是醉了。提交一个请求，要先请求接口 a 获得 a1 ，在用 a1 接口请求 b 获得 b1 ，在用 b1 请求接口 c ，全让前端搞，中间有一个流程出错就完蛋。项目干完我就跑路了

[tabris233]

还是要看业务场景，研发效率，团队配置等综合因素。
但逻辑前置、无脑信任前端确实不是合理的。