一个接口引发的前后端处理数据标准的思考

[Irisxx]

楼主本身 技术栈是移动端(ios + flutter)，前端在学（新手） 以下是一个实际的应用场景举例: 一个普通的列表显示接口 A:

其中 styles 和 types 分别需要另外调用 接口 B 和 接口 C ，返回的数据格式类似如下: 需要匹配用第一个接口里的 styles 的数字去匹配第二个数组里的 value,一旦匹配上把当前的 label 值塞到第一个接口的自定义字段的返回值里去，最后显示

v 友的第一个观点大概是上来先把接口 2 所有类型的数据拉取下来，然后本地维护这个数组去做匹配，这个方案呢也是我一开始想到的，但是呢后台不支持所有类型数据下发，第二呢后端前面提过这个 value 和 label 的绑定是动态的，我猜大概是为了实时性的缘故吧

目前状态呢是我这边已经处理完了这部分数据，但是安卓呢不愿意处理，后端也不愿意处理 我这边就是最常规的做法，同时请求 x 个接口，然后等待都返回后 去匹配值，用哈希表稍微优化了一下匹配时间复杂度，但我觉得这对一个最基础的列表展示是不是过于繁琐了。如果风格是 100 个，返回的是 80,90,99 呢。

鉴于 V2 大佬多，想问问像这种情况有没有标准，到底应该哪边处理比较好，后端处理的话当然也要做匹配。还有个疑问就是这部分数据上传的时候难道不是上传字符串的吗，会有什么场景需要专门把这些风格还专门做成 1,2,3 ，4.在我看来这不是多此一举吗。

[renmu]

我是前端，我认为应该后端做，但是他比我壮得多，还是我来做吧

[sagaxu]

“数据上传的时候难道不是上传字符串的吗”

通常上传的时候已经是 ID 了，字符串仅供 UI 层面展示，存储 2/4 字节的 ID 在大部分场景比存字符串高效紧凑，修改字符串的时候，不用修改所有实例，只改字典表就行。

ID 换描述三四行代码就搞定了，很繁琐吗？

[paopjian]

这个是类似于表单的多选和码表吧,风格和方式是多选的,存数据库的时候就是数组转字符串了,码表是为了后端可控制,万一哪天北欧风改成北欧纯欲风直接库里一改名就完事. 哈希值匹配的速度是很快的,反而要考虑的是服务器有没有缓存,别一不小心搜错了卡死了.
看不懂什么叫安卓不愿意处理后端也不愿意处理,拿工资不干活滚蛋就是了,要么后端多写两句直接把码值对应的文本拼好一起返回来,要么前端直接请求码值自己再找, 还是个优化的理由

[zpfhbyx]

我一般都是后端渲染好的,前端无脑渲染就完事了,

[BeautifulSoap]

没看懂什么叫处理完了这部分数据，和安卓、后端不愿处理的意思

这种工作就是后端来做的，应该让后端将这三个 api 合成一个 api 。如果后端不愿意做，那就留下证据，然后发请求呗，反正到时候请求数多两倍，增加的也是后端的负载

[Irisxx]

@paopjian 明白了，后端这样做确实也有好处，现在问题回到了还是只有一方能方便的问题了。

[Irisxx]

@BeautifulSoap 就是我不想浪费时间，答应了后台我本地多线程处理了数据，没和安卓商量。现在可能里外不是人了。

[Irisxx]

@zpfhbyx 感谢我以前公司的后台

[tangkikodo]

后端组合， 大概率后端自己也不喜欢拼数据所以想偷懒了。

https://github.com/allmonday/pydantic-resolve-demo 如果是 python 这边的话， 这种需求 pydantic-resolve 一把梭直接就能组合好。

[jaggle]

弄个 bbf

[Irisxx]

补充下:楼主想知道的其实不是怎么处理的技术问题，而是像大厂一般都是怎么分工的，有没有什么标准，还是真的全靠个体的协商和自觉。

[sagaxu]

@Irisxx 大厂某些部门，在后端和前端中间还有一层“中端”，组合内部各种 API ，加工后返回给前端。以前 PHP 常干这个事情。

[CEBBCAT]

实话实说这四段都读完了也没明白到底是怎么回事儿。至于存储，可能是因为 types 、styles 单独存成了字段，而 MySQL 5.7 （猜测使用的是它）不支持数组存储，所以用逗号间隔存成了字符串。

读不明白，所以别的问题帮忙不了了

[Irisxx]

@CEBBCAT 确实我表达有问题，其实 12 楼回复的挺好的，本质是没有中台，也就是加工数据这个人，前后端都不想干这组装数据的杂活。

[lyxxxh2]

后端做啊。
第二个请求的网络延迟等消耗,本来就是不需要的。

[lyxxxh2]

就像前端 发个请求不照格式来,还要我特殊处理。

自定义响应格式,本来就是后端的基操。
估计数据库存的字符串,后端懒,

我同事谁做都行,随便说下就行了啊。
不过正常都是源头谁那里,谁做。

[dabingbing]

我的原则是，前端尽量不要搞复杂数据，前端负责渲染，后端负责数据

[duowb]

😋我碰到这种情况，已经不想和后端拉扯了，还不如赶紧写完,摸鱼去，假如公司要统计代码行数，那不是还赚了🤡

[duowb]

@duowb 谁写都一样，拉扯来拉扯去，还把自己搞得一肚子火.

[uselessVisitor]

这个活，应该后端去拼接好做的。
一个接口能解决的为什么要本地多线程请求接口做。

[Jed2020]

论接口文档的必要性

[iidear2015]

目前没见过统一的标准。一般大家会根据一些不成文的原则来协商

1. C 端应用，一般用户体验优先。在前端处理的话，会多一次请求，导致用户等待时间变长，所以后端处理。
2. M 端应用，一般效率优先。看前后端开发压力，和后续维护成本。

具体到你这个问题，后端处理更好。iOS 和 android 需要重复开发，逻辑收敛到后端，维护成本更低， 用户体验也更好。

上面只是说放在哪一"端"合适，实际由前端人员还是后端人员来做就需要"讨论"了。大厂里会存在前端开发人员写后端服务，可以搜一下 BFF 层。

[Irisxx]

@iidear2015 了解了下，确实 BFF 适用于这种场景，只是我的技术栈中没有 JAVA ，前端做 BFF 避不开多线程拉请求 。

[dayeye2006199]

问就是 graphQL

[gerefoxing]

这种字典值显示都是后端处理，后期修改的话后端直接在数据库改下同步到缓存中就行了