问老开发一个前后端矛盾的问题

[ainyyy]

我是 java 后端。新到一个公司，前端所有接口都希望后端返回的数据能直接使用，不进行任何数据处理。比如状态返回 01 他们要 truefalse ，两个需要拼接的字段都返回了，还要增加一个汇总字段。 理由是组件不好复用。我也会写点简单 vue ，完全理解不了组件不能复用是什么意思。

甚至前端渲染图表，list 数据已经返回了，他们要我转换成图表需要的多维数组。

我早上和前端吵起来了，他们竟然说所有前端都是这样的。去找领导也说数据处理是后端该做的工作。

工作 8 年了，我现在也有点懵，是我以前遇到的前端都太好了？

[Suaxi]

看领导怎么安排了

第一家公司带我的老组长要求的是能后台处理好的就尽量后台处理，前端 res.data 放进去直接渲染（比如 table 约定好结构和格式，前端同事直接 res.tableHead 、res.tableData 取就行），实在不好处理的就商量着来

[esee]

按照现有的开发规范进行，你不能要求现有公司的开发习惯为了你一个人改。尤其是这种前端做也行后端做也行的时候。我前后都写，对于这个问题我支持后端返回什么前端就展示什么，因为后端我随时可以改，前端提交上去还要审核，比如小程序各大应用商店 app ，这些审核的时效是我无法控制的，但是后端我可以控制，所以能在后端做的尽量后端做。

[Chuckle]

就好比，前端也直接把“可复用的”表单值扔给后端，问就是传了，对象里找找，或者明明需要传很多个业务 id ，这些 id 有关联，就传一个，后端自己查表、调其它服务拿剩下的，还有传个嵌套的数组，后端还得遍历几遍打平拼东西上去等等。数据格式、业务上这种，就看需求开发谁做主了，领导都这么说了，一直这么搞，那肯定有它的理由，虽然现在只是两个字段拼接，但有时候像数组这种数据量大的，特别还是用 react 的话，deep 对比、数据转换，性能会有比较大问题，可能就是不想开这个口子，所以再简单的数据处理也要后端做，前端一般来说数据结构不会经常改的，特别是封装好的业务组件，顶多随着需求加东西。

[sublime8]

这个东西，完全是个人喜好，甚至是一些比较执拗的喜好，我也见过这样的例子，理由就是不让前端去碰业务逻辑。
但我自己又是另一个极端，我自己的项目又写前端又写后端，我喜欢后端给最原始的数据，大量的业务都是前端去处理

[DOLLOR]

看到 0 1 都要后端转成 true false 的，我感觉问题可能出在前端更多，按道理，这本应是由前端处理的事情。
多维数组转换，对熟练的前端开发者来说，本应不是什么难事，甚至 AI 都能轻松搞定。
抱有“后端返回的数据能直接使用”心态的前端，未来也不会有多少好日子了。

但也可能是公司有什么特殊规定，划分了前后端的边界，导致这事需要在后端处理。
所以我建议先参考已有的接口、旧的代码，看原有的习惯是怎么处理的，尽量保持跟原有的代码相同的风格吧。

[isbase]

要求后端返回的数据和前端组件的格式 100% 完全一致，其实并不现实——哪怕是自己给自己写接口也未必能做到这一点。

一般来说，后端还是需要提供基本的 VO （ Value Object ），这是合理的。

从前端角度来看，当然是希望后端返回的数据能直接“无脑”传给组件使用，不需要再做额外处理。

但现实中，只要结构大致匹配、字段齐全、依赖关系合理且符合直觉，就已经可以满足大部分需求了。

[wunonglin]

我是全栈，我很明确的表态，你们前端 90%是在偷懒

[beidounanxizi]

0 1 这种枚举设计 如果没有大小比较 后端 ddl 就用 varchar 也挺好的
app 开发 当然是 后端给什么 app 端就用什么
web 端 看谁话语权
一句 ChatGPT 的事情
0 1 这种字典表的破事 前端也能处理

[DefoliationM]

国内好多都这样，不然你以为为啥好多人叫前端切图仔，多一点都不会干，组件都是直接复制，不会组合复用。
本来很多数据是需要前端调用多个接口自己去组合的，没拿到的就转圈。
现在就是一个接口有的没的全返回，前端死等，用户体验极差，老板还觉得挺好。

[xzour]

按公司规则来，不然你不好“混“。
但是以通用来说，前端的业务需求是多变的，不可能因为业务变更而叫后端调整结构。后端主要是提供规范标准的接口，前端或者中间层进行组合。如果因为性能问题，后端再介入组合接口。
而且规范接口有个好处，现在 AI 工具很强，就如 @hamsterbase 所说，这些根本都不是争论点。把接口文档给 AI ，前端开发基本就完成的 7788 了。只能说你司开发还在路径依赖，出来后就比较惨。

[alwaysol]

我们公司一个刚毕业的前端就是这样的,她以为前端就是把后端返回的数据渲染出来就行了,前端不需要做任何计算逻辑.比如折线图,她希望后台能拼接好数据格式图表控件直接绑定数据源就行了

[cat]

加个 BFF 层就行了

[viweei]

有时候前端确实不好处理像汇总，清洗一类的数据处理。把这些工作放前端 Chrome CPU 和内存占用飙升的太快，你不能保证每一个客户的机器都很强，碰到弱一点的客户机，等待的时间长，用户体验相当糟糕。
而且有些数据处理，后端可以一次算好利用缓存效率提升的不是一点半点。 很多后端以为搞完 CRUD ，觉得他的工作就完成了。我部份赞同 @humbass 的说法，前端主要关心应该是人机交互，操作逻辑这些。

[yosoroAida]

我是全栈+1 ，你们前端确实是偷懒

[visper]

按理说，越低层的东西变动越少，越靠前端层的变动越多。后端返回的数据灵活一点前端组装会更好，否则如果前端稍微一变化一下展示方式又叫你后端改。

[zzjun]

以前写安卓端，后端偷懒，把表建完，每个表写个增删改查的接口，业务安卓端写，丢

[bianzhifu]

前端组装用的内存和 cpu 是用户的，后端组装用的是公司的

[kapaseker]

二楼说法是对的，这个其实没有绝对的对与错。就看公司是怎么规定或者规划的，按照公司的要求来就好了。你觉得你做的多，工作量你要多报呀，对不。

我把现在的后端接口分成了两种，一个是提供能力，一个是提供业务逻辑（就像你说的拼接字段，这个有可能只是产品设计上的业务逻辑）

对于提供能力的接口，大部分产品逻辑工作都是前端做，这样灵活性高，也就是说，如果你有跨端的业务，跨移动端，桌面，网页的画，这种接口比较合适。以为不同的端产品展现上是有差异的。

对于提供逻辑的接口。虽然没有上面的看起来灵活，但是有个很大的好处，就是如果你后端升级了，想更改产品的显示方式了，那么前端是不需要动的（网页可能没有什么问题，但是对于桌面端和移动端，这个是巨大优势）。


我们公司比较奇怪，我作为移动端的开发者，我希望提供能力的接口，但是我们后端却喜欢给我提供逻辑的接口，哈哈哈，还是挺搞笑的。

[chobitssp]

我们巴不得后端只给原料 全部由前端进行加工 毕竟变了需求 修改前端更快

[CodersZzz]

这让我想起了我们公司的现状，只要出问题全是后端开发的事情，哪怕是显示，因为所有数据都是后端给的。哪怕是页面逻辑出问题，第一时间怀疑的也是后端开发的问题。在我们公司做后端开发真的是苦不堪言。