V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
HeroYang811
V2EX  ›  程序员

前端请教 后端返回数据格式问题

  •  
  •   HeroYang811 · 135 天前 · 5536 次点击
    这是一个创建于 135 天前的主题,其中的信息可能已经有所发展或是发生改变。
    本人:前端
    对方:后端(外包)
    情况:电商项目首页商品列表
    问题 1:在多维数组内某些字段含有多个数据的情况下,后端返回的数据格式为字符串,多个则用逗号隔开比如"http://123,http://456,http://789",然后让我前端去做逻辑处理,也就是说让我将字符串转换为数组再处理。
    问题 2:部分类型判断采用中文,比如某个商品类型,name === '类型一号' ,然后根据这个相等的类型去展示对应的内容。
    我的前端理解:这也太不规范了吧,很多地方逻辑数据处理全部扔到了前端,而且是在商品首页数据量这么大的地方,难道不会导致页面渲染缓慢吗,并且说:“客户端处理逻辑是用户体验感最好的表现”,偷懒也不能这样吧
    结果:浪费时间,我懒得扯了,前端写就写吧

    虚心请教,各位后端大牛的看法,
    72 条回复    2023-12-13 16:50:49 +08:00
    wu67
        1
    wu67  
       135 天前   ❤️ 1
    第一个问题, 其实谁干都行, 典型的用 mysql 存字符串, 只是他懒得分割而已 (换 pg 存数组就简单粗暴了, pg 大法好). 前端分割其实没太大问题, 累点而已, 你的商城是小程序那就另说, 那玩意的性能和屎一样.

    第二个问题, 一言难尽, 很多老旧系统都有, php 的各种商城就是重灾区, 大概是从他的旧代码库里面 c v 了...
    xuelu520
        2
    xuelu520  
       135 天前
    部分简单的拆装拼接逻辑给前端,可以降低后端压力。(前端性能都这么强了,这点不算啥)
    一般列表都是分页来的,如果数据量大,应该要考虑需求是不是有问题。
    总之看你们有没接口规范,没有就怎么合作舒服怎么来
    cat
        3
    cat  
       135 天前   ❤️ 1
    特别讨厌用逗号 , 来隔开的,一旦值本身包含逗号,一分割就乱了
    gxy2825
        4
    gxy2825  
       135 天前
    你们公司前端也太好说话了吧,换我们给前端这样的数据早就炸了
    op 或许可以问问前端/后端组长的意见?或者其他老员工
    awalkingman
        5
    awalkingman  
       135 天前
    @cat 我是特别害怕
    gitrebase
        6
    gitrebase  
       135 天前
    问题 1:就像 #1 说的,很有可能是在存“一对多”的数据的时候不想新建一张表,按我的习惯我是会在后端把数据转为数组再传递给前端的

    问题 2:用中文 emm 我也不知道行不行,但是用 code 会更好吧
    brader
        7
    brader  
       135 天前
    还算正常,我理解是都可以。
    还有你说性能的问题,其实影响不大,如果你非要比较个高低,我觉得放服务端转化影响大,因为服务端要面对所有客户端。
    Bingchunmoli
        8
    Bingchunmoli  
       135 天前 via Android
    @brader 赞同,1. 是需不需要单独处理,前后端都能做的事 看分工,2. 一般用 int , 不排除一些政企或者老系统喜欢中文需要兼容或者什么的, 数据的一些逻辑处理是可以后端和可以前端的,从性能考虑 优先前端,前端性能“无限”, 还有一种考虑是 后端一个接口支持多端,不同端对应自己业务自己处理, 如果单端,服务器并发不高,前后端都行
    James2099
        9
    James2099  
       135 天前
    我也遇到过,筛选 list 列表都让我自己前端写死,还有分页前端来做,还有返回的数据格式,也要我分割,明明穿一个对象就能解决
    1016
        10
    1016  
       135 天前
    你这算啥... 我这边后端返回的数据像 tmd 一坨屎... 明明他自己能处理的数据 非要丢给我来处理 自己坐在那里玩手机 刷推特 我真的 C™D

    主要他也玩 v2 也不好把数据粘贴出来。
    k9982874
        11
    k9982874  
       135 天前   ❤️ 1
    这。。外包你不干他,留着他过年?
    wdf
        12
    wdf  
       135 天前
    那你是没遇到我们的后端,前端用的级联组件,按道理后端返回正常的树结构就没啥问题,结果他返回的数据每层的数据格式不一样,层级也不确定 说最多 5 层,最多返回 5 千多条数据,沟通让改下数据格式,后端回怼句:我返回的数据格式是有意义的,我修改的话不太好。我现在有点质疑自己 不知道问题出在哪了
    sanmaozhao
        13
    sanmaozhao  
       135 天前   ❤️ 2
    1 、既然是多值,那就以数组返回
    这个没什么好商量的,后端你爱咋存咋存,不要暴漏给前端。更别说值里面有逗号咋办的事儿了

    2 、逻辑判断用中文不太好,或者说不要用“会显示到界面上的值”
    因为会显示出来的,后续很大可能就要修改,文案啥的谁都没法保证不变
    如果这个中文永远不显示给用户,那就还行吧,你就当它是个 key 好了
    nothingistrue
        14
    nothingistrue  
       135 天前
    如果单纯从技术层面讲:
    问题 1 ,前后端谁做都可以,后端的视图层,前端的 Model 层都是干这事的,至于具体谁做,首先要看以前谁做,其次要看现在谁愿意做,最后才是看谁有时间做。
    问题 2 ,不与代码同步的文档不如没有文档,没有管理的编码不如直接用名称。尤其是经过大数据分析的发展之后,那种没用的编码,还是让他步入坟墓吧。

    实际上你不要扣技术,没意义。
    davin
        15
    davin  
       135 天前
    感觉第二个问题可以用 enum 枚举映射, 用的时候,name === ItemTypes.Category1 这样判断。之后维护这个 ItemTypes 就好,减少传说中的魔法值。其他比如订单状态,衣服的尺码 (M 、L 、XL 、XXL 、XXXL 等),订单审核状态也适合用枚举。
    MoYi123
        16
    MoYi123  
       135 天前   ❤️ 1
    喷点只有
    1. 不规范
    2. 逗号不在 url 转义的表里, 一定要这样搞用个分号, 保证不切错(包括后端的存储)

    硬要说性能, 我猜这样 split 性能会比解 json 更好.
    MorJS
        17
    MorJS  
       135 天前
    上嘴脸
    FawkesV
        18
    FawkesV  
       135 天前
    问题 1 偷懒了. 也确实很丑.
    问题 2 看业务场景,有没有 code 实在没办法只能这样子处理了
    coderzhangsan
        19
    coderzhangsan  
       135 天前
    1 谁做都行,只是看谁懒得强势些,你来提问,就应说明问题了;至于性能,你说得太夸张,你一页要显示多少商品数据?几百条以下,字符串转换为数组能耗损什么性能。
    2 用中文可能是前期设计遗留的问题,加状态枚举估计要改造库表,能跑就行,不必过多关注,真有问题,推给后端就好了。

    总结:
    1 你有代码洁癖
    2 贵司后端比较强势
    3 后端外包,你们的项目估计也好不到哪去,所以程序和程序员只要有一个能跑就行
    fkdog
        20
    fkdog  
       135 天前
    后端水平太次了,英文半角逗号是 url 无需转义的字符,但凡哪天 url 需要存一个云厂商处理过的带参数图片、视频(往往 url 里带半角逗号的),就会出问题。
    nice2cu
        21
    nice2cu  
       135 天前
    估计数据库里就是这么存的,不存成 json 格式迟早要炸
    kristofer
        22
    kristofer  
       135 天前
    第一个问题,后端菜,不过你都说他是外包了,菜很正常。谁来解析都跟性能没关,一个分页列表,有啥性能问题。
    第二个问题,历史遗留的不算,新代码且不是非这样不可的情况下,采用中文判断我不认可。
    zjyl1994
        23
    zjyl1994  
       135 天前
    1 的话,确实应该后端处理,存储层的细节不应该暴露出来给到前端。
    2 的话和业务有关,有些上古系统就是这么设计的,你不兼容搞两套维护成本更高。而且很有可能接口已经被其他部门拿去用了,只能将错就错继续用下来,等接口重构才有机会改。
    ntedshen
        24
    ntedshen  
       135 天前
    逗号拆数组的逻辑中间件写就完了吧,哪端都一样。。。

    “很多地方逻辑数据处理全部扔到了前端,而且是在商品首页数据量这么大的地方,难道不会导致页面渲染缓慢吗”
    讲道理前端苛求性能然后让后端做处理才更不符合现实逻辑。。。
    尤其国服硬件性能本来就卷的很,一个电商客户端/网页还能有两位马老板的全家桶费性能?
    Shosuke
        25
    Shosuke  
       135 天前
    我也碰到過這樣的後端,開發體驗糟糕的不行。

    很多的事情邏輯上都扔到了客戶端,還有前端總要因爲後端的數據無規範,寫出一大堆自己看了都想吐的代碼。

    不管怎麽溝通都會出現同樣的問題,最後自己選擇辭職。
    Shosuke
        26
    Shosuke  
       135 天前
    問題 1 )數據不是很多的話,可以接受,但是這種傳 string + ',' 方式真的不太好。
    問題 2 )專案是因爲太老了要維持字典還是什麽原因,好想吐槽...
    bthulu
        27
    bthulu  
       135 天前
    部分类型判断采用中文有什么问题? 我这边工业领域, 大部分专业名词都没有英文, 难道你还去生造一个英文单词出来?
    snarkprayer
        28
    snarkprayer  
       135 天前
    歪个楼,针对页面渲染缓慢这个,前端大部分项目其实摸不到性能瓶颈,看着不流畅一是动画不够,二是 HTML 历史包袱太重,抛弃掉各种兼容的话性能翻个一两倍轻轻松松
    looo
        29
    looo  
       135 天前
    我看前排好多人觉得这种逻辑后端没必要去写,都前后端分离了,那是不是先出文档,根据文档要求只做展示,前端不做任何业务处理。

    一句话:前端只做展示,不做任何业务处理。
    IvanLi127
        30
    IvanLi127  
       135 天前 via Android
    问题一,绝对是后端偷懒,这都不转换回多维数组,要前端再处理,那要这后端有啥用?要我就直接拉他项目改代码了。
    问题二,不好说合理不合理,如果是类似字典表做动态类型的话,中文就中文吧。
    bianhui
        31
    bianhui  
       135 天前
    针对问题 1:可能数据库存的就是字符串。后端拿到之后直接吐了,就没有处理。站在后端角度看,split 是要损失性能的,而这些性能是公司的服务器提供,都是要公司花钱的,如果 split 在客户端,用的是用户资源。其次众所周知处理成 json 会包含大量的无效字符,比如说引号逗号,在高并发常见会造成带宽的更多占用。
    在前端角度看,确实破坏了整个项目统一性和规范性。让项目维护起来困难。同时如果后端数据格式发生变动,前端必须要跟随修改。
    总结:如果公司不是你的,你自己分一下得了。
    针对问题 2:这个不用说后端问题,可以让对方规定一套枚举或编号用于判断,中文在不同环境下编码有问题是毋庸置疑的。
    总结:你可以让后端试试表单提交的 field name 全是中文的感觉
    wangtian2020
        32
    wangtian2020  
       135 天前
    其实逗号分隔的结果和 ['http://123','http://456','http://789'].join() 的执行结果一致
    不能说完全没有关系,但是还是在返回体里面用 json 比较好

    更坑的后端是直接返回个破字符串要求你 JSON.parse 几下
    duanxianze
        33
    duanxianze  
       135 天前
    刚开始工作的时候我还会争辩两句,现在没必要,小公司,一来领导是看你工作时间给钱,二来你费劲心思写的代码说不定坚持不到 1 年就没用了,尤其是前端代码,说什么可维护都是扯淡
    wolfie
        34
    wolfie  
       135 天前
    经历不同,我们公司前端要求逗号更多,后端给数组时 老让后端改。
    i8086
        35
    i8086  
       135 天前
    不排除就是直接从数据库读取出来,也不转换,直接返回给前端了。
    luliumytime
        36
    luliumytime  
       135 天前 via iPhone
    能用就行
    SleepyRaven
        37
    SleepyRaven  
       135 天前
    前后端都写一点的说下个人看法:
    1 、这个存储的时候,避开值本身包含逗号或者转义的情况下,用逗号隔开存整个字符串也是可以的,问题在于返回给前端的时候肯定要 split 成数组的。
    2 、这肯定不行啊,枚举值要么接口返回要么前后端统一写到常量 map 里。
    abcdexx
        38
    abcdexx  
       135 天前
    @1016 在网上挂我?好,我记住你了。
    darkengine
        39
    darkengine  
       135 天前   ❤️ 1
    @Shosuke 是的,为了展示数据要做转换,特别是 web 转一遍,Android/iOS 又要转一遍。
    x2420390517
        40
    x2420390517  
       135 天前
    既然是外包的,那肯定是你说了算
    xujiang
        41
    xujiang  
       135 天前
    @wdf 这么多数据,前端一次性渲染可能会崩掉,😄
    brader
        42
    brader  
       135 天前
    @cat
    @fkdog 按标准做的 url ,是不会有逗号问题的
    https://datatracker.ietf.org/doc/html/rfc3986
    cat
        43
    cat  
       135 天前
    @brader 我说的特别讨厌用逗号分隔,不限于楼主的例子,而且就如楼上说的,这是后端存储的方法,不应该暴露给前端处理,至少我自己写的接口都是用 [ ... ]
    brader
        44
    brader  
       135 天前
    @cat 这个存储方式我认为各有优劣,还有此种存储方式也没什么敏感点,所以无所谓暴露不暴露存储方式的问题。
    还是回到类似数据场景,应该前端还是后端处理的问题,这种问题如果在公司没有明确指导方向,我觉得就是都可以,这个对前后端都不难。技术不要过于恪守教条,代码也有交流的人情世故吧。
    supuwoerc
        45
    supuwoerc  
       134 天前
    对面是个懒狗,直接让他改,强硬点。
    youngwen
        46
    youngwen  
       134 天前
    第一个问题,自定义的分隔符应当由后端处理,前端应当无感,将这个分隔符的影响最小化。
    第二个问题,本质上是没有找到合适的抽象定义
    sankooc
        47
    sankooc  
       134 天前
    第一个问题需要跟他们说好风险点比如字符串本身有分隔符的情况 第二个其实没有办法 毕竟是外包不好追求完美
    cfancc
        48
    cfancc  
       134 天前
    第一个问题后端处理
    第二个问题,定义一套枚举值,而不是用 name
    ma836323493
        49
    ma836323493  
       134 天前
    @wangtian2020 #32 所以返回 json 字符串有什么问题,你存的什么我返回什么, 这种存多个链接不至于再建表
    passon
        50
    passon  
       134 天前
    感觉 1 ,2 都不是什么问题
    konakona
        51
    konakona  
       134 天前
    问题 1:问题倒不是特别大,要看你们团队对于“前后端数据通信”有没有约定的文档,很难说一个前端去要求后端提供什么样的数据是合理的。因为只有后端自己知道加领域去处理回传数据为数组的开销是多少,并不完全是偷懒的问题。
    问题 2:取决于公司团队规模,如果是小规模,为了快速交付,那建议是后端提供字典接口,方便前端枚举;如果是小规模以上,那就应该规范做事,可以由前端跟后端约定好字典后,在前端维护本地字典。好处是经过大家敲定拍板的东西,如果一方改动造成迭代问题,可以通过字典追溯出是后端私自改了还是前端私自改了。
    wangtian2020
        52
    wangtian2020  
       134 天前
    @ma836323493 对对对,数据不用处理,把整个数据库都返回给前端。后端开了吧
    wangtian2020
        53
    wangtian2020  
       134 天前
    @ma836323493 见过前端请求时 json 是一个字符串的吗,水平低数据不会处理找那么多理由。怎么处理需不需要建表不是前端要考虑的事情。接触过有些后端是真的过分,接口设计到处搞些技术倒退的莫名其妙的地方,最后一整个系统都是一坨。我提交数据的时候还是好好的一个 json ,返回一个字符串什么意思“Json 序列化与反序列化”不会就去学一个
    hongjijun233
        54
    hongjijun233  
       134 天前
    @1016 #10
    在网上挂我?好,我记住你了。
    romisanic
        55
    romisanic  
       134 天前
    1 看数据提交的时候谁拼接的,如果是后端拼接的,那就后端去解,如果是前端拼接的,前端去解。
    2 有历史包袱的话也常见,但是新功能新枚举的话不应该,改。
    ma836323493
        56
    ma836323493  
       134 天前
    @wangtian2020 #53 一个表单提交,n 个附件,但是这些附件没有业务逻辑查询是可以 json 字符串存储的,如果单独建个附件表的话,修改,删除都需要删除关联附件表来重新新增。而且 新增的时候前端可能传[url], 后端查询详情的 返回不处理的话就是 list 对象 [{url,id}]
    brader
        57
    brader  
       134 天前
    @wangtian2020 阿里云和腾讯云的 API 一样出现很多图片字段,通过逗号或者分号分隔的字符串返回,json 字符串直接返回。
    按你说的,他们的工程师也是低水平的,可以开掉了
    kamilic
        58
    kamilic  
       134 天前
    多年工作的体会,关于前后端对接格式这些东西,我觉得这是话语权的问题,没有规范约束的情况下就看谁能说服谁,也可以说谁先妥协。
    遇到赖皮的前/后端,如 OP 举的例子,好说话的一方总会妥协地处理掉了。
    除非你直接摆烂说不按照需要的返回我就不干了,把问题往上反馈也是一样看主管方的话语权大。

    说到底还是要有规范,而且还要不断根据不同对接场景迭代的规范。
    kamilic
        59
    kamilic  
       134 天前
    前端在研发链条末端,往往话语权更低,毕竟一般概念上都是没有后端接口不行。
    但链条反过来也不是不行,只要前端写的屎山够大,改不动了也能翻转驱动后端对接前端(狗头
    xingdaorong
        60
    xingdaorong  
       134 天前
    第一个问题前端和后端处理都是一样的,后端返回这种类型字符串,直接说没有语义化,数组就是数组,字符串是字符串,除非给一个特别理由,比如接口会慢几秒,其它不接受
    evam
        61
    evam  
       134 天前
    找前端组长/后段组长/架构师
    这种事情其实看编码规范
    2324
        62
    2324  
       134 天前
    @James2099 前端做分页是一次性传个 1 ,2M 的数据,自己拿 js 裁吗?
    James2099
        63
    James2099  
       134 天前
    @2324 对的
    wangtian2020
        64
    wangtian2020  
       134 天前
    @brader 确实是水平不高,也就 java boy 老是搞这种接口了,要是 nodejs 当后端绝对不可能有 json 字符串出现在接口里面。存可以存 json 字符串,处理成 json 对象再传出来可以吗
    OrionParker
        65
    OrionParker  
       134 天前
    @1016 在网上挂我?好,我记住你了。
    brader
        66
    brader  
       134 天前
    @wangtian2020 别人这么搞自然是有道理的,这些字符串存在一个数组记录里面,服务端反序列化需要成本,对于一个请求来说微不足道,但是成千上万个请求就有的算了,把这部分算力下放到客户端也没什么不妥。
    另外像微信之类,近些年他们也把很多服务端可完成的算力成本下放到客户端了,很多计算都在客户端做。
    wangtian2020
        67
    wangtian2020  
       134 天前
    @brader 我作为对接方是不是还得夸他几句?
    主题里是普通的前端和后端对接接口,反正我遇到的后端给出这种接口我肯定要骂。哪怕真是去对接阿里腾讯 api ,他好意思给这种接口我作为对接方难道得夸他几句?
    brader
        68
    brader  
       134 天前
    这本身就是不同角度看法产生的矛盾点,如果你能夸对方的话,矛盾也就不存在了。
    我只是说从技术上讲这种做法我认为没什么问题。
    非要解决这个争议也很简单,有决定权的人提前把规范定下来就是了,开发遵照执行。
    way2create
        69
    way2create  
       134 天前
    我说句实话,哪怕就算是他不规范他菜但你没话语权有啥用呢?很多事实际工作中是商量着来的,只要不会太离谱就行,而且很多规范遵守不遵守说实话也看公司看项目看工期,不是谁都是搞得高大上的。
    morenacl
        70
    morenacl  
       134 天前
    通常不都是前端外包,后端自己搞
    way2create
        71
    way2create  
       134 天前
    补充一句:
    1 这个非要说规范肯定是不太推荐这样存的 但有些实在是小项目没要求的或者历史遗留问题也懒得去动 其次这种数据一般只会考虑本身没有逗号的数据
    2 这个我不喜欢用中文判断
    我实际工作中一般都跟前端商量着来,我多做点事也无所谓,只要不会太离谱工期允许,鄙人也是底层 CURD BOY 不是什么大牛,个别前端(仅针对我遇到的来说)真的是又菜又爱偷懒,你要是说帮我处理下我也 OK ,还非要把人当傻子扯 7 扯 8 装 X ,实际上规范也不是他那样的,项目也是个极小的项目,真的就啥逻辑验证都不乐意写只管发送接收就好。
    soloHm
        72
    soloHm  
       133 天前
    @gitrebase 问题 2 正常要么定义成字典要么定义成枚举,但是直接用名字 确实不咋地
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5617 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 39ms · UTC 03:32 · PVG 11:32 · LAX 20:32 · JFK 23:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.