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

[ainyyy]

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

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

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

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

[hefish]

前端： 你教我做事啊？

[nickytsui1862]

客户端仔表示 公司有规范的前提下按公司规范来，没有规范就按以前的做法来（既然没人有意见那就是默认这个规则）
如果需要客户端处理，那就要做好不能随时更新内容格式的准备（需要用户更新版本、刷新缓存等，都是不可控的）

你的情况，如果对后端来说加多了工作量，那就以后评估时间就按这种可能有额外工作的来算。

[mmx12138]

我是前端， 这东西我个人认为是前端应该做的， 把数据处理成符合当前业务， 前端是简单了， 但不好复用， 类似于你说的图表的场景， 有些地方可能需要不同的图表展示同一个数据， 结构可能是不一样的， 如果后端处理了， 反而麻烦， 作为前端， 说句实话的， 你公司的这些前端太懒了， 当然这个问题是一直存在的， 所以不就很多人用 node 去做 bff ， 大家都简单~

[humbass]

我们的原则是，前端页面看到什么。后端就给什么。典型的说像商城的首页就是大杂烩，后端就给大杂烩。当然也有少数不是这样，比如地点，用户权限啊，单独给。

[lthon]

看谁话语权大咯，这种属于可逆的格式转换，谁做都行。

[panlatent]

以个人全站但前后端不同语言的我来说 在前端写

[cowcomic]

看你们有没有接口规范
有接口规范的话，就按规范走，比如基于 Rest 的资源操作，资源定义好之后如果再需要做转换，这部分就交给前端做
如果没有规范，那就是谁话语权大就听谁的
VO 层也不是不能放到后端做，就是注意做好代码的分层管理，不然接口一多就容易出问题

[Curtion]

这个不是技术问题，纯粹是规范的问题，你们谈不拢就让老大做决定，像我们系统的缓存和业务流转都是页面做的

[importmeta]

之前一个国企项目开发有规范, 代码判断用枚举, 展示的时候用后端多给的一个纯展示的字段, 前端什么也不管.
你刚刚新到一个公司, 还能吵起来, 连试用期都不一定能过, 明天看看气氛不对就跑路吧, 能吵起来估计你也干不长.

[rocmax]

让前端自己搞 bff

[sleepm]

告诉他，菜就多练

[way2create]

按理很多数据要前端处理的，但个别前端爱偷懒，只想调接口，不过我也经常帮前端处理一些数据，我觉得不麻烦的就顺手弄了，公司有要求就只能按公司规范做了，如果是那种垃圾公司老油条纯粹想偷懒又掌握不了话语权就只能忍 OR 跑了

另外想起之前有个前同事，一开始不熟，我按业务分接口，他还非要我聚合在一个接口对着页面给他，跟我说这样性能更好，减少网络请求，用户量数据量接口数量都非常小型的项目，还跟我扯这些所谓性能增加我的工作，实际上就是他自己想偷懒 文档都不想看 上班偷偷搞自己的外包项目

[lete]

谁钱多谁干嘿嘿

[onikage]

碰到过，不是啥技术问题，单纯就是前端嫌活多了。啰嗦不解决问题，唯有混成他们上级。

[shawnsh]

@importmeta 你是真多嘴，不用阴阳怪气的给人家泼冷水，国企项目就是一坨屎

[kidlj]

不合理。

1. 前端改结构后端还得跟着改接口？
2. 一个接口可能用于多个页面（前端自己处理成页面需要的结构），也是一种复用。

所以我不写业务代码，避免撕逼。

[LandCruiser]

你都干 8 年了还来问这个问题？心智太不成熟了，领导都发话了还有什么可说的？领导指鹿为马你也得听啊，你不听就走人啊，有什么好说的呢？

[ZoR]

谁嗓门大听谁的，只要不是太过分我一般后端弄了

[hamsterbase]

作为前端，现在我都不管这些了。

1. 用工具直接拉后段文档生成 ts 请求库和类型
2. 直接把设计稿，产品文档，后端技术设计发给 AI
3. 等几分钟，摸鱼一下

然后页面就开发好了。

[jones2000]

这个主要看前端的工资了， 给的高， 前端可以做做业务逻辑的计算。 给的少，后台给什么就展示什么。

[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]

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

[wangtian2020]

后端不需要处理数据，后端最好提供能转换的原始数据，例如提供带时区的时间戳/ISO8601 时间，让前端自己格式化转化，以应对任何需求。
只要文档写清楚，任何枚举值都应该前端转换。
总结就是这个公司前端人菜脾气大，没办法你就惯着吧

[hellomimi]

小问题，看项目情况呗
---如果是单个前端项目，那么前端来做数据处理。
---如果你们是多端项目，有 web 、h5 、小程序、安卓、ios...等，那么还是后端处理一下数据合理一些。

[tanszhe]

我如果是后端 我希望原样范围数据库信息 其他前端处理

我如果是前端 我希望后端处理成 看起来的样子 前端只需要 data = response 一个赋值就好了

[TimPeake]

'状态返回 01 他们要 truefalse ' 有点离谱了， 切图仔完全不考虑后期状态扩展的可能啊 。估计是 el-switch 默认的 true false 用习惯了 ？ 虽然我也是前端。

接口肯定要考虑通用性，不可能为了图表渲染就 返回 { x: XDataList, y: yDataList }。肯定是 [ {}, {} ] 数组对象合适。

[ZGeek]

@mmx12138 #3 就像你说的，还是要以业务模型为主，后端本来就不应该参与界面什么事，后端蒙着眼不知道前端界面长什么样也可以完成开发的，而不是受限于 VIEW 的展示逻辑，这是站在架构上来说的。

站在前端来说，一个页面要调用多次后端接口的确比较恶心，所以为什么会有 BFF 的层，但是这一层对于简单接口又太过于无聊（套壳转发而已）。

综合来看，我觉得还是应该坚持 1 ，如果对于前端有较大困扰，那么可以两种解决方案
1. 部分接口抽出 BFF 层，前端/后端同学写（具体谁写商量着来），这一层完全不处理任何业务
2. 前端是不是应该也可以有一些类似安卓里 RxJAVA 这样的牛逼的框架，可以任意整合数据流，这是从前端工程上来说

[zekee]

前端不能做的，后端做；
前端能做后端也能做的，后端做。

[ZGeek]

@viweei #33 前后端的分界和联系点不应该在数据，而是应该在业务模型上

[YvenChang]

技术上来说是前端处理，不过实际情况的话，看谁话语权大（

[boyzhang]

这是规范问题，要看具体情况，如果前端很忙事情很多，你后端按照他的要求组装数组返回给他，如果前端不忙，那就你们自己约定怎么返回，前端自己组装数据

[xiuming]

明显你那前端只待过小公司，你们领导也没领略过服务器费用如何压垮一家公司。强大如阿里和亚马逊都被服务器费用折服纷纷出来搞云计算。客服端现在 CPU 那么强，放着客户端强大算力不用，非去挤占服务厂商买的虚拟机那可怜的算力和带宽。

[mckincy]

不同团队和项目的习惯会有所不同。在一些团队中，后端确实承担更多的数据处理工作，尤其是在数据结构比较复杂时，以简化前端开发的工作量。这在某种程度上可以提高前端的开发效率。

[Genshin2020]

都不谈钱吗？我以前可真遇到过，前端就给开了 6000 多，后端都是过万。

我前后端都写，不过在公司主要负责前端开发，先下一个结论，你公司前端懒，如果前端工资比后端少太多，那前端也没有毛病，如果差不多，那就是前端懒。

我喜欢要原生数据，然后自己处理，会写一个中间层，异步请求都会用这个中间层处理一下，然后返回的就是页面需要的业务数据了。

如果用的是 vue / element ui 这样的组合，甚至组件需要的配置都直接写好，到页面就直接渲染。

所以这样的活给后端肯定不适合。

但是也有业务数据是需要后端处理的，虽然这样的情况比较少。

[syubo2810]

app 小程序那就后端处理，web 的话都可以

[spritecn]

这种事,每次做估时汇报的时候,加一天为前端调整数据展示逻辑不就好了? 话说我这里现在 excel 导出都是直接把数据给前端生生的...

[Genshin2020]

还有就是现在其实流行前端处理数据，客户端的电脑性能都是溢出的，哪怕是 10 年前的 CPU ，处理现在的网站业务都是溢出的，这么好的算力外设，为何不用。

[darklinden]

每一个傻逼设计背后大概率都有一个傻逼需求
之前遇到过要求不重新发布前端改表样式的，后端押着前端搓好模板填好数据后端直发，有需求了前端搓好新模板后端改（半夜改需求不再是后端一个人的事儿了

[sjhhjx0122]

其实作为前端我是喜欢纯数据的接口自己处理，如果后端接口完全跟着业务走，变业务就改死了

[seanlin5]

如果在客户端用户详情显示一个描述信息，服务端返回 sex/age/height ，前端取字段拼接。此时业务有调整说去掉性别显示成学历之类的。如果是前端处理，那需要用户端更新客户端。服务端处理就显得简单多了，组装一下，返回一个新字段 user_desc 。
总得来说：还是看业务及用户群体吧

[abolast]

@CodersZzz 像极了我，我司某些后端，一旦出问题了就是运维的事情，运维要看他屎山或者翻阅相关协议的提案标准来自证清白，我现在都不叫他 web 后端了，叫本地后端。没关系，我被逼成了全栈也不错。有一次他用来某个包然后那个包的最新版本有问题，我去那个包的 github 提交了 fix ，然后他在会上指责我菜，我直接把我在开源社区的提交记录给大家看，是谁菜。就算如此，他还是一如既往的觉得我菜各种春秋笔法，无所谓了忍急了我直接去翻他代码每次下班前就提几个 bug ，能纵览代码并且在非业务代码能力吊打这个人的运维要提 bug 不是很容易

[redbeanzzZ]

@hamsterbase 1 没什么问题，但是公司如果有开发规范组件库的话，你的 2 是不是不行啊？ ai 要很多提示词才能按你的组件库做吧？

[redbeanzzZ]

前端直接用不是很现实吧，大差不差就可以了。只要数据结构别变化，文档能及时更新，字段不要调的时候一直变，作为前端我就阿弥陀佛了。最夸张的就是数据结构变化这种破坏性更新，简直夸张

[spritecn]

@abolast 这要打起来啊

[egan0606]

别管谁做， 谁做工作量就评估上去： 不处理数据，1 天， 需要按照要求处理特定数据格式， 就 2 天 或者 3 天； 没毛病， 吃的就是这晚饭；

[Roan]

按理来说是前端做的，但是公司有规定那就没办法了，实在不行润

[kakki]

这算什么,还有 SB 公司要求后端根据网页链接生成一次性二维码的,用一次就删了.
放着前端算力不用折腾服务器,这种垃圾公司从根子上就有问题.

[einblattx]

后端处理的是业务数据,面向各个端,前端显示的是视图数据,理论上各端各自处理

[linauror]

数据组合显示之类的应该前端处理，后端只返回标准格式，这样同一个接口可以给不同的页面或者不同端使用。

[ixixi]

一般
前端可以写字符串拼接 如 {n}元
但是如果写计算 {n+m}元 应该让后端计算

[lait123]

我想问下 你们没有导出场景吗? 我的感觉理论上页面所有展示的字段都是有后端提供的. 0 1 2 3 这种枚举成中文展示也是要后端追加字段给前端的. 不然后端导出业务的时候 还不是要他写一遍?

[abolast]

@spritecn 打，cto 我都敢怼，级别低一点的他一直在对我进行刁难甚至人身攻击我倒是不能真怼，怼领导没关系的，怼他只能降低周围眼光中我的素养，那就从代码能力方面打击他吧，被一个程序员鄙视链末端的运维吊打就很难受。反正我也不会再接触有他的其他项目，我能支配自己的工作

[Nitsuya]

前端做~

[MrDevin]

看具体场景或规范吧，我们是尽可能的让数据结构保持跟 ui 一致，当然前端一点不做是不可能的，所以还是得看具体场景

[kelololy]

看前端给出的理由，没啥正当理由，就跟 lz 说的这个情况，我会 battle 的，因为不合理；

[everhythm]

这就是前端懒呀，当然放在 api 里面做也行，本质上是要你的 api 返回的数据去适配前端图表格式。

不过从开发效率角度讲无所谓，就 1 个 adapter 放哪，比如这接口就 1 个内部系统用，怎么快怎么来。

[CodeCodeStudy]

后端处理，前端展示。特别是移动端，因为移动端发布新版本比较麻烦，各种平台的审核。

[lancelock]

后端应该给通用的数据，list 要转成多维数组，他这个是用 echarts 之类的库要这样的格式吧，万一换个图表库难道后端跟着改？还有其他端呢可能要的结构都不一样，怎么可能让后端来适配

[islaohu]

这其实不算矛盾，本质是你们公司后端同学开发完业务接口的同时 BFF 层的职责也划分到了后端同学，BFF 这件事情谁做都一样。

[alleluya]

@ZGeek #45 又不是没有 rxjs 包括像 xstate 这样的状态机解决方案也有 大部分人不用也不会用而已....

[er567]

只要后端设计的数据格式字段合理就行了，不需要他们给出完全符合组件的数据，只要不变动就行了

[ddczl]

看你们公司规范，在我们公司的规范就是后端处理。但有的时候没人去计较这个

[zekee]

@CodeCodeStudy 还有一点，如果后端很顺手就能处理的一个字段值，放在前端要通过各种取值计算校验啥的最终才能得到这个值，再叠加数据量大的 buff ，可能会损失点前端的一点点点点性能（毕竟用户的设备不一定是啥配置呢）。

[sss393]

笑死，后端也有今天。

看到这么多说前端懒得，可见实际上大部分公司依旧是前端格式化数据，后端只管咔咔查库然后扔给前端。

[shintendo]

我是前端，我巴不得后端返回的数据越原始越好，你把格式拼好了要我干什么，如果我想换种格式显示反而还麻烦。

这种你直接怼回去，你说要不我给你返回 JSP 得了

[alleluya]

@abolast #70 我一直觉得运维很重要啊 也没到末端吧 要说末端 我觉得测试反而更"末端"一些

[SanjinGG]

这种一般谁吵赢听谁的，更何况领导都发话了

[YorkWong]

我是前端，我巴不得后端返回的数据越原始越好 +1

[yuwangG]

这个可以商量着来，但是有时候前端让我给个接口弹出微信小程序登录授权我是真做不到啊

[MEIerer]

都对，都能，主要是如果业务变动就只需要变后端的，复杂逻辑放后端就是这个道理

[hokori]

听老板的 管他

[Meijer]

@xiuming 这也是我想说的，客户端这么强大的计算能力，就不能让服务器端少点遍历和计算吗？前端真的不讲究，说这些，他们完全听不懂，只知道渲染后端给的数据，希望 AI 快点发展吧，把前端替换了得了

[fpure]

显然不合理，应该前端依赖后端而不是后端依赖前端

[urlpha]

考核前端最重要的指标是 100%还原 UI 。

[Hoye]

你和他对比一下工资吧，谁多谁做

[sarices]

让前端处理吧，让他写一个中间件处理

[fedfrank]

前后端都能做。。。看看有没有规范吧，有规范就按照规范来，其实也不难吧，写个数据转化的方法就行，前后端都不难，这事能吵起来我也是服气你俩。。。

[dkrao]

因为前端用的都是一些组件库，组件的结构都是有要求的，比如说图表需要多维数组，或者树级结构，你如果纸返回一级 list 数组，没有关联关系，前端肯定不好处理的，除非你返回不同数据之间的关联字段，才方便前端处理

[dcdlove]

现在的后端已经堕落到 3 不，不写单元测试，不初始数据，不请求验证，一个 crud 写一周 ，脾气大、火气高、骨头傲、嘴巴硬

[PineSongCN]

看工资

[HeyWeGo]

写代码或者扩展开来说，工作最讨厌这种扯皮的地方。比写代码恶心一百倍

[CodersZzz]

@abolast 哈哈哈 打起来打起来。不过你们代码管理有问题啊，前端还能看到后端代码仓库啊