这是一个创建于 382 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人：前端
对方：后端(外包)
情况：电商项目首页商品列表
问题 1：在多维数组内某些字段含有多个数据的情况下，后端返回的数据格式为字符串，多个则用逗号隔开比如"http://123,http://456,http://789"，然后让我前端去做逻辑处理，也就是说让我将字符串转换为数组再处理。
问题 2：部分类型判断采用中文，比如某个商品类型，name === '类型一号' ，然后根据这个相等的类型去展示对应的内容。
我的前端理解：这也太不规范了吧，很多地方逻辑数据处理全部扔到了前端,而且是在商品首页数据量这么大的地方，难道不会导致页面渲染缓慢吗，并且说：“客户端处理逻辑是用户体验感最好的表现”，偷懒也不能这样吧
结果：浪费时间，我懒得扯了，前端写就写吧
虚心请教，各位后端大牛的看法，
对方：后端(外包)
情况：电商项目首页商品列表
问题 1：在多维数组内某些字段含有多个数据的情况下，后端返回的数据格式为字符串，多个则用逗号隔开比如"http://123,http://456,http://789"，然后让我前端去做逻辑处理，也就是说让我将字符串转换为数组再处理。
问题 2：部分类型判断采用中文，比如某个商品类型，name === '类型一号' ，然后根据这个相等的类型去展示对应的内容。
我的前端理解：这也太不规范了吧，很多地方逻辑数据处理全部扔到了前端,而且是在商品首页数据量这么大的地方，难道不会导致页面渲染缓慢吗，并且说：“客户端处理逻辑是用户体验感最好的表现”，偷懒也不能这样吧
结果：浪费时间，我懒得扯了，前端写就写吧
虚心请教，各位后端大牛的看法，
 |
1
wu67 2023-12-11 16:39:11 +08:00  1
第一个问题, 其实谁干都行, 典型的用 mysql 存字符串, 只是他懒得分割而已 (换 pg 存数组就简单粗暴了, pg 大法好). 前端分割其实没太大问题, 累点而已, 你的商城是小程序那就另说, 那玩意的性能和屎一样.
第二个问题, 一言难尽, 很多老旧系统都有, php 的各种商城就是重灾区, 大概是从他的旧代码库里面 c v 了... |
 |
2
xuelu520 2023-12-11 16:41:25 +08:00
部分简单的拆装拼接逻辑给前端，可以降低后端压力。(前端性能都这么强了，这点不算啥)
一般列表都是分页来的，如果数据量大，应该要考虑需求是不是有问题。 总之看你们有没接口规范，没有就怎么合作舒服怎么来 |
 |
3
cat 2023-12-11 16:49:00 +08:00 1
特别讨厌用逗号 , 来隔开的，一旦值本身包含逗号，一分割就乱了
|
 |
4
gxy2825 2023-12-11 16:52:26 +08:00
你们公司前端也太好说话了吧，换我们给前端这样的数据早就炸了
op 或许可以问问前端/后端组长的意见？或者其他老员工 |
 |
5
awalkingman 2023-12-11 16:52:41 +08:00
@cat 我是特别害怕
|
 |
6
gitrebase 2023-12-11 16:53:58 +08:00
问题 1：就像 #1 说的，很有可能是在存“一对多”的数据的时候不想新建一张表，按我的习惯我是会在后端把数据转为数组再传递给前端的
问题 2：用中文 emm 我也不知道行不行，但是用 code 会更好吧 |
 |
7
brader 2023-12-11 16:58:30 +08:00
还算正常，我理解是都可以。
还有你说性能的问题，其实影响不大，如果你非要比较个高低，我觉得放服务端转化影响大，因为服务端要面对所有客户端。 |
 |
8
Bingchunmoli 2023-12-11 17:03:50 +08:00 via Android
@brader 赞同，1. 是需不需要单独处理，前后端都能做的事 看分工，2. 一般用 int ， 不排除一些政企或者老系统喜欢中文需要兼容或者什么的， 数据的一些逻辑处理是可以后端和可以前端的，从性能考虑 优先前端，前端性能“无限”, 还有一种考虑是 后端一个接口支持多端，不同端对应自己业务自己处理， 如果单端，服务器并发不高，前后端都行
|
 |
9
lDqe4OE6iOEUQNM7 2023-12-11 17:08:33 +08:00
我也遇到过，筛选 list 列表都让我自己前端写死，还有分页前端来做，还有返回的数据格式，也要我分割，明明穿一个对象就能解决
|
 |
10
1016 2023-12-11 17:14:10 +08:00
你这算啥... 我这边后端返回的数据像 tmd 一坨屎... 明明他自己能处理的数据 非要丢给我来处理 自己坐在那里玩手机 刷推特 我真的 C™D
主要他也玩 v2 也不好把数据粘贴出来。 |
 |
11
k9982874 2023-12-11 17:15:17 +08:00 1
这。。外包你不干他，留着他过年？
|
 |
12
wdf 2023-12-11 17:26:10 +08:00
那你是没遇到我们的后端，前端用的级联组件，按道理后端返回正常的树结构就没啥问题，结果他返回的数据每层的数据格式不一样，层级也不确定 说最多 5 层，最多返回 5 千多条数据，沟通让改下数据格式，后端回怼句：我返回的数据格式是有意义的，我修改的话不太好。我现在有点质疑自己 不知道问题出在哪了
|
 |
13
sanmaozhao 2023-12-11 17:32:36 +08:00 2
1 、既然是多值，那就以数组返回
这个没什么好商量的，后端你爱咋存咋存，不要暴漏给前端。更别说值里面有逗号咋办的事儿了 2 、逻辑判断用中文不太好，或者说不要用“会显示到界面上的值” 因为会显示出来的，后续很大可能就要修改，文案啥的谁都没法保证不变 如果这个中文永远不显示给用户，那就还行吧，你就当它是个 key 好了 |
 |
14
nothingistrue 2023-12-11 17:46:44 +08:00
如果单纯从技术层面讲：
问题 1 ，前后端谁做都可以，后端的视图层，前端的 Model 层都是干这事的，至于具体谁做，首先要看以前谁做，其次要看现在谁愿意做，最后才是看谁有时间做。 问题 2 ，不与代码同步的文档不如没有文档，没有管理的编码不如直接用名称。尤其是经过大数据分析的发展之后，那种没用的编码，还是让他步入坟墓吧。 实际上你不要扣技术，没意义。 |
 |
15
davin 2023-12-11 17:49:35 +08:00
感觉第二个问题可以用 enum 枚举映射， 用的时候，name === ItemTypes.Category1 这样判断。之后维护这个 ItemTypes 就好，减少传说中的魔法值。其他比如订单状态，衣服的尺码 (M 、L 、XL 、XXL 、XXXL 等)，订单审核状态也适合用枚举。
|
 |
16
MoYi123 2023-12-11 17:49:56 +08:00 1
喷点只有
1. 不规范 2. 逗号不在 url 转义的表里, 一定要这样搞用个分号, 保证不切错(包括后端的存储) 硬要说性能, 我猜这样 split 性能会比解 json 更好. |
 |
17
43n5Z6GyW39943pj 2023-12-11 17:56:33 +08:00
上嘴脸
|
 |
18
FawkesV 2023-12-11 17:58:34 +08:00
问题 1 偷懒了. 也确实很丑.
问题 2 看业务场景,有没有 code 实在没办法只能这样子处理了 |
 |
19
coderzhangsan 2023-12-11 18:07:51 +08:00
1 谁做都行，只是看谁懒得强势些，你来提问，就应说明问题了；至于性能，你说得太夸张，你一页要显示多少商品数据？几百条以下，字符串转换为数组能耗损什么性能。
2 用中文可能是前期设计遗留的问题，加状态枚举估计要改造库表，能跑就行，不必过多关注，真有问题，推给后端就好了。 总结： 1 你有代码洁癖 2 贵司后端比较强势 3 后端外包，你们的项目估计也好不到哪去，所以程序和程序员只要有一个能跑就行 |
 |
20
fkdog 2023-12-11 18:40:05 +08:00
后端水平太次了，英文半角逗号是 url 无需转义的字符，但凡哪天 url 需要存一个云厂商处理过的带参数图片、视频（往往 url 里带半角逗号的），就会出问题。
|
 |
21
nice2cu 2023-12-11 19:19:25 +08:00
估计数据库里就是这么存的，不存成 json 格式迟早要炸
|
 |
22
kristofer 2023-12-11 19:24:05 +08:00
第一个问题，后端菜，不过你都说他是外包了，菜很正常。谁来解析都跟性能没关，一个分页列表，有啥性能问题。
第二个问题，历史遗留的不算，新代码且不是非这样不可的情况下，采用中文判断我不认可。 |
 |
23
zjyl1994 2023-12-11 21:47:53 +08:00
1 的话，确实应该后端处理，存储层的细节不应该暴露出来给到前端。
2 的话和业务有关，有些上古系统就是这么设计的，你不兼容搞两套维护成本更高。而且很有可能接口已经被其他部门拿去用了，只能将错就错继续用下来，等接口重构才有机会改。 |
 |
24
ntedshen 2023-12-11 22:22:32 +08:00
逗号拆数组的逻辑中间件写就完了吧，哪端都一样。。。
“很多地方逻辑数据处理全部扔到了前端,而且是在商品首页数据量这么大的地方，难道不会导致页面渲染缓慢吗” 讲道理前端苛求性能然后让后端做处理才更不符合现实逻辑。。。 尤其国服硬件性能本来就卷的很，一个电商客户端/网页还能有两位马老板的全家桶费性能？ |
 |
25
Shosuke 2023-12-12 07:53:05 +08:00
我也碰到過這樣的後端，開發體驗糟糕的不行。
很多的事情邏輯上都扔到了客戶端，還有前端總要因爲後端的數據無規範，寫出一大堆自己看了都想吐的代碼。 不管怎麽溝通都會出現同樣的問題，最後自己選擇辭職。 |
|
26
Shosuke 2023-12-12 08:00:03 +08:00
問題 1 ）數據不是很多的話，可以接受，但是這種傳 string + ',' 方式真的不太好。
問題 2 ）專案是因爲太老了要維持字典還是什麽原因，好想吐槽... |
 |
27
bthulu 2023-12-12 08:48:59 +08:00
部分类型判断采用中文有什么问题? 我这边工业领域, 大部分专业名词都没有英文, 难道你还去生造一个英文单词出来?
|
 |
28
snarkprayer 2023-12-12 08:53:53 +08:00
歪个楼，针对页面渲染缓慢这个，前端大部分项目其实摸不到性能瓶颈，看着不流畅一是动画不够，二是 HTML 历史包袱太重，抛弃掉各种兼容的话性能翻个一两倍轻轻松松
|
 |
29
looo 2023-12-12 09:03:02 +08:00
我看前排好多人觉得这种逻辑后端没必要去写，都前后端分离了，那是不是先出文档，根据文档要求只做展示，前端不做任何业务处理。
一句话：前端只做展示，不做任何业务处理。 |
 |
30
IvanLi127 2023-12-12 09:09:49 +08:00 via Android
问题一，绝对是后端偷懒，这都不转换回多维数组，要前端再处理，那要这后端有啥用？要我就直接拉他项目改代码了。
问题二，不好说合理不合理，如果是类似字典表做动态类型的话，中文就中文吧。 |
 |
31
bianhui 2023-12-12 09:16:59 +08:00
针对问题 1：可能数据库存的就是字符串。后端拿到之后直接吐了，就没有处理。站在后端角度看，split 是要损失性能的，而这些性能是公司的服务器提供，都是要公司花钱的，如果 split 在客户端，用的是用户资源。其次众所周知处理成 json 会包含大量的无效字符，比如说引号逗号，在高并发常见会造成带宽的更多占用。
在前端角度看，确实破坏了整个项目统一性和规范性。让项目维护起来困难。同时如果后端数据格式发生变动，前端必须要跟随修改。 总结：如果公司不是你的，你自己分一下得了。 针对问题 2：这个不用说后端问题，可以让对方规定一套枚举或编号用于判断，中文在不同环境下编码有问题是毋庸置疑的。 总结：你可以让后端试试表单提交的 field name 全是中文的感觉 |
 |
32
wangtian2020 2023-12-12 09:21:14 +08:00
其实逗号分隔的结果和 ['http://123','http://456','http://789'].join() 的执行结果一致
不能说完全没有关系，但是还是在返回体里面用 json 比较好 更坑的后端是直接返回个破字符串要求你 JSON.parse 几下 |
 |
33
duanxianze 2023-12-12 09:34:31 +08:00
刚开始工作的时候我还会争辩两句，现在没必要，小公司，一来领导是看你工作时间给钱，二来你费劲心思写的代码说不定坚持不到 1 年就没用了，尤其是前端代码，说什么可维护都是扯淡
|
 |
34
wolfie 2023-12-12 09:38:40 +08:00
经历不同，我们公司前端要求逗号更多，后端给数组时 老让后端改。
|
 |
35
i8086 2023-12-12 09:42:10 +08:00
不排除就是直接从数据库读取出来，也不转换，直接返回给前端了。
|
 |
36
luliumytime 2023-12-12 10:05:15 +08:00 via iPhone
能用就行
|
 |
37
SleepyRaven 2023-12-12 10:10:19 +08:00
前后端都写一点的说下个人看法：
1 、这个存储的时候，避开值本身包含逗号或者转义的情况下，用逗号隔开存整个字符串也是可以的，问题在于返回给前端的时候肯定要 split 成数组的。 2 、这肯定不行啊，枚举值要么接口返回要么前后端统一写到常量 map 里。 |
 |
39
darkengine 2023-12-12 10:18:50 +08:00 1
@Shosuke 是的，为了展示数据要做转换，特别是 web 转一遍，Android/iOS 又要转一遍。
|
 |
40
dj721xHiAvbL11n0 2023-12-12 10:38:51 +08:00
既然是外包的，那肯定是你说了算
|
|
42
brader 2023-12-12 10:53:45 +08:00
|
|
43
cat 2023-12-12 10:59:15 +08:00
@brader 我说的特别讨厌用逗号分隔，不限于楼主的例子，而且就如楼上说的，这是后端存储的方法，不应该暴露给前端处理，至少我自己写的接口都是用 [ ... ]
|
|
44
brader 2023-12-12 11:06:25 +08:00
@cat 这个存储方式我认为各有优劣，还有此种存储方式也没什么敏感点，所以无所谓暴露不暴露存储方式的问题。
还是回到类似数据场景，应该前端还是后端处理的问题，这种问题如果在公司没有明确指导方向，我觉得就是都可以，这个对前后端都不难。技术不要过于恪守教条，代码也有交流的人情世故吧。 |
 |
45
supuwoerc 2023-12-12 11:54:36 +08:00
对面是个懒狗，直接让他改，强硬点。
|
 |
46
youngwen 2023-12-12 12:28:58 +08:00
第一个问题，自定义的分隔符应当由后端处理，前端应当无感，将这个分隔符的影响最小化。
第二个问题，本质上是没有找到合适的抽象定义 |
 |
47
sankooc 2023-12-12 13:37:50 +08:00
第一个问题需要跟他们说好风险点比如字符串本身有分隔符的情况 第二个其实没有办法 毕竟是外包不好追求完美
|
 |
48
cfancc 2023-12-12 13:44:13 +08:00
第一个问题后端处理
第二个问题，定义一套枚举值，而不是用 name |
 |
49
ma836323493 2023-12-12 13:47:06 +08:00
@wangtian2020 #32 所以返回 json 字符串有什么问题，你存的什么我返回什么， 这种存多个链接不至于再建表
|
 |
50
passon 2023-12-12 13:48:47 +08:00
感觉 1 ，2 都不是什么问题
|
 |
51
konakona 2023-12-12 14:27:05 +08:00
问题 1：问题倒不是特别大，要看你们团队对于“前后端数据通信”有没有约定的文档，很难说一个前端去要求后端提供什么样的数据是合理的。因为只有后端自己知道加领域去处理回传数据为数组的开销是多少，并不完全是偷懒的问题。
问题 2：取决于公司团队规模，如果是小规模，为了快速交付，那建议是后端提供字典接口，方便前端枚举；如果是小规模以上，那就应该规范做事，可以由前端跟后端约定好字典后，在前端维护本地字典。好处是经过大家敲定拍板的东西，如果一方改动造成迭代问题，可以通过字典追溯出是后端私自改了还是前端私自改了。 |
|
52
wangtian2020 2023-12-12 14:33:47 +08:00
@ma836323493 对对对，数据不用处理，把整个数据库都返回给前端。后端开了吧
|
|
53
wangtian2020 2023-12-12 14:43:03 +08:00
@ma836323493 见过前端请求时 json 是一个字符串的吗，水平低数据不会处理找那么多理由。怎么处理需不需要建表不是前端要考虑的事情。接触过有些后端是真的过分，接口设计到处搞些技术倒退的莫名其妙的地方，最后一整个系统都是一坨。我提交数据的时候还是好好的一个 json ，返回一个字符串什么意思“Json 序列化与反序列化”不会就去学一个
|
 |
54
hongjijun233 2023-12-12 15:55:40 +08:00
@1016 #10
在网上挂我？好，我记住你了。 |
 |
55
romisanic 2023-12-12 16:30:49 +08:00
1 看数据提交的时候谁拼接的，如果是后端拼接的，那就后端去解，如果是前端拼接的，前端去解。
2 有历史包袱的话也常见，但是新功能新枚举的话不应该，改。 |
|
56
ma836323493 2023-12-12 17:00:08 +08:00
@wangtian2020 #53 一个表单提交，n 个附件，但是这些附件没有业务逻辑查询是可以 json 字符串存储的，如果单独建个附件表的话，修改，删除都需要删除关联附件表来重新新增。而且 新增的时候前端可能传[url], 后端查询详情的 返回不处理的话就是 list 对象 [{url,id}]
|
|
57
brader 2023-12-12 17:17:01 +08:00
@wangtian2020 阿里云和腾讯云的 API 一样出现很多图片字段，通过逗号或者分号分隔的字符串返回，json 字符串直接返回。
按你说的，他们的工程师也是低水平的，可以开掉了 |
 |
58
kamilic 2023-12-12 17:46:47 +08:00
多年工作的体会，关于前后端对接格式这些东西，我觉得这是话语权的问题，没有规范约束的情况下就看谁能说服谁，也可以说谁先妥协。
遇到赖皮的前/后端，如 OP 举的例子，好说话的一方总会妥协地处理掉了。 除非你直接摆烂说不按照需要的返回我就不干了，把问题往上反馈也是一样看主管方的话语权大。 说到底还是要有规范，而且还要不断根据不同对接场景迭代的规范。 |
|
59
kamilic 2023-12-12 17:49:40 +08:00
前端在研发链条末端，往往话语权更低，毕竟一般概念上都是没有后端接口不行。
但链条反过来也不是不行，只要前端写的屎山够大，改不动了也能翻转驱动后端对接前端（狗头 |
 |
60
xingdaorong 2023-12-12 17:55:02 +08:00
第一个问题前端和后端处理都是一样的，后端返回这种类型字符串，直接说没有语义化，数组就是数组，字符串是字符串，除非给一个特别理由，比如接口会慢几秒，其它不接受
|
 |
61
evam 2023-12-12 17:55:07 +08:00
找前端组长/后段组长/架构师
这种事情其实看编码规范 |
|
63
lDqe4OE6iOEUQNM7 2023-12-13 10:15:45 +08:00
@2324 对的
|
|
64
wangtian2020 2023-12-13 10:21:08 +08:00
@brader 确实是水平不高，也就 java boy 老是搞这种接口了，要是 nodejs 当后端绝对不可能有 json 字符串出现在接口里面。存可以存 json 字符串，处理成 json 对象再传出来可以吗
|
 |
65
OrionParker 2023-12-13 10:25:29 +08:00
@1016 在网上挂我？好，我记住你了。
|
|
66
brader 2023-12-13 10:26:39 +08:00
@wangtian2020 别人这么搞自然是有道理的，这些字符串存在一个数组记录里面，服务端反序列化需要成本，对于一个请求来说微不足道，但是成千上万个请求就有的算了，把这部分算力下放到客户端也没什么不妥。
另外像微信之类，近些年他们也把很多服务端可完成的算力成本下放到客户端了，很多计算都在客户端做。 |
|
67
wangtian2020 2023-12-13 10:32:21 +08:00
@brader 我作为对接方是不是还得夸他几句？
主题里是普通的前端和后端对接接口，反正我遇到的后端给出这种接口我肯定要骂。哪怕真是去对接阿里腾讯 api ，他好意思给这种接口我作为对接方难道得夸他几句？ |
|
68
brader 2023-12-13 10:38:46 +08:00
这本身就是不同角度看法产生的矛盾点，如果你能夸对方的话，矛盾也就不存在了。
我只是说从技术上讲这种做法我认为没什么问题。 非要解决这个争议也很简单，有决定权的人提前把规范定下来就是了，开发遵照执行。 |
 |
69
way2create 2023-12-13 11:07:02 +08:00
我说句实话，哪怕就算是他不规范他菜但你没话语权有啥用呢？很多事实际工作中是商量着来的，只要不会太离谱就行，而且很多规范遵守不遵守说实话也看公司看项目看工期，不是谁都是搞得高大上的。
|
 |
70
F7TsdQL45E0jmoiG 2023-12-13 11:21:42 +08:00
通常不都是前端外包，后端自己搞
|
|
71
way2create 2023-12-13 11:22:46 +08:00
补充一句：
1 这个非要说规范肯定是不太推荐这样存的 但有些实在是小项目没要求的或者历史遗留问题也懒得去动 其次这种数据一般只会考虑本身没有逗号的数据 2 这个我不喜欢用中文判断 我实际工作中一般都跟前端商量着来，我多做点事也无所谓，只要不会太离谱工期允许，鄙人也是底层 CURD BOY 不是什么大牛，个别前端(仅针对我遇到的来说)真的是又菜又爱偷懒，你要是说帮我处理下我也 OK ，还非要把人当傻子扯 7 扯 8 装 X ，实际上规范也不是他那样的，项目也是个极小的项目，真的就啥逻辑验证都不乐意写只管发送接收就好。 |
Select Language