这是一个创建于 44 天前的主题，其中的信息可能已经有所发展或是发生改变。
楼主本身 技术栈是移动端(ios + flutter)，前端在学（新手）
以下是一个实际的应用场景举例:
一个普通的列表显示接口 A:
其中 styles 和 types 分别需要另外调用 接口 B 和 接口 C ，返回的数据格式类似如下:
需要匹配用第一个接口里的 styles 的数字去匹配第二个数组里的 value,一旦匹配上把当前的 label 值塞到第一个接口的自定义字段的返回值里去，最后显示
v 友的第一个观点大概是上来先把接口 2 所有类型的数据拉取下来，然后本地维护这个数组去做匹配，这个方案呢也是我一开始想到的，但是呢后台不支持所有类型数据下发，第二呢后端前面提过这个 value 和 label 的绑定是动态的，我猜大概是为了实时性的缘故吧
目前状态呢是我这边已经处理完了这部分数据，但是安卓呢不愿意处理，后端也不愿意处理 我这边就是最常规的做法，同时请求 x 个接口，然后等待都返回后 去匹配值，用哈希表稍微优化了一下匹配时间复杂度，但我觉得这对一个最基础的列表展示是不是过于繁琐了。如果风格是 100 个，返回的是 80,90,99 呢。
鉴于 V2 大佬多，想问问像这种情况有没有标准，到底应该哪边处理比较好，后端处理的话当然也要做匹配。还有个疑问就是这部分数据上传的时候难道不是上传字符串的吗，会有什么场景需要专门把这些风格还专门做成 1,2,3 ，4.在我看来这不是多此一举吗。
25 条回复 • 2024-07-26 15:30:02 +08:00
 |
1
renmu 44 天前 via Android  4
我是前端，我认为应该后端做，但是他比我壮得多，还是我来做吧
|
 |
2
sagaxu 44 天前
“数据上传的时候难道不是上传字符串的吗”
通常上传的时候已经是 ID 了，字符串仅供 UI 层面展示，存储 2/4 字节的 ID 在大部分场景比存字符串高效紧凑，修改字符串的时候，不用修改所有实例，只改字典表就行。 ID 换描述三四行代码就搞定了，很繁琐吗？ |
 |
3
paopjian 44 天前
这个是类似于表单的多选和码表吧,风格和方式是多选的,存数据库的时候就是数组转字符串了,码表是为了后端可控制,万一哪天北欧风改成北欧纯欲风直接库里一改名就完事. 哈希值匹配的速度是很快的,反而要考虑的是服务器有没有缓存,别一不小心搜错了卡死了.
看不懂什么叫安卓不愿意处理后端也不愿意处理,拿工资不干活滚蛋就是了,要么后端多写两句直接把码值对应的文本拼好一起返回来,要么前端直接请求码值自己再找, 还是个优化的理由 |
 |
4
zpfhbyx 44 天前
我一般都是后端渲染好的,前端无脑渲染就完事了,
|
 |
5
BeautifulSoap 44 天前
没看懂什么叫处理完了这部分数据，和安卓、后端不愿处理的意思
这种工作就是后端来做的，应该让后端将这三个 api 合成一个 api 。如果后端不愿意做，那就留下证据，然后发请求呗，反正到时候请求数多两倍，增加的也是后端的负载 |
 |
7
Irisxx OP @BeautifulSoap 就是我不想浪费时间，答应了后台我本地多线程处理了数据，没和安卓商量。现在可能里外不是人了。
|
 |
9
tangkikodo 44 天前
后端组合， 大概率后端自己也不喜欢拼数据所以想偷懒了。
https://github.com/allmonday/pydantic-resolve-demo 如果是 python 这边的话， 这种需求 pydantic-resolve 一把梭直接就能组合好。 |
 |
10
jaggle 44 天前 via iPhone
弄个 bbf
|
|
11
Irisxx OP 补充下:楼主想知道的其实不是怎么处理的技术问题，而是像大厂一般都是怎么分工的，有没有什么标准，还是真的全靠个体的协商和自觉。
|
 |
13
CEBBCAT 44 天前
实话实说这四段都读完了也没明白到底是怎么回事儿。至于存储，可能是因为 types 、styles 单独存成了字段，而 MySQL 5.7 （猜测使用的是它）不支持数组存储，所以用逗号间隔存成了字符串。
读不明白，所以别的问题帮忙不了了 |
 |
15
lyxxxh2 43 天前
后端做啊。
第二个请求的网络延迟等消耗,本来就是不需要的。 |
|
16
lyxxxh2 43 天前
就像前端 发个请求不照格式来,还要我特殊处理。
自定义响应格式,本来就是后端的基操。 估计数据库存的字符串,后端懒, 我同事谁做都行,随便说下就行了啊。 不过正常都是源头谁那里,谁做。 |
 |
17
dabingbing 43 天前
我的原则是，前端尽量不要搞复杂数据，前端负责渲染，后端负责数据
|
 |
18
duowb 43 天前
😋我碰到这种情况，已经不想和后端拉扯了，还不如赶紧写完,摸鱼去，假如公司要统计代码行数，那不是还赚了🤡
|
 |
20
uselessVisitor 43 天前 via Android
这个活，应该后端去拼接好做的。
一个接口能解决的为什么要本地多线程请求接口做。 |
 |
21
Jed2020 43 天前
论接口文档的必要性
|
 |
22
iidear2015 43 天前 1
目前没见过统一的标准。一般大家会根据一些不成文的原则来协商
1. C 端应用，一般用户体验优先。在前端处理的话，会多一次请求，导致用户等待时间变长，所以后端处理。 2. M 端应用，一般效率优先。看前后端开发压力，和后续维护成本。 具体到你这个问题，后端处理更好。iOS 和 android 需要重复开发，逻辑收敛到后端，维护成本更低， 用户体验也更好。 上面只是说放在哪一"端"合适，实际由前端人员还是后端人员来做就需要"讨论"了。大厂里会存在前端开发人员写后端服务，可以搜一下 BFF 层。 |
|
23
Irisxx OP @iidear2015 了解了下，确实 BFF 适用于这种场景，只是我的技术栈中没有 JAVA ，前端做 BFF 避不开多线程拉请求 。
|
 |
24
dayeye2006199 43 天前
问就是 graphQL
|
 |
25
gerefoxing 43 天前
这种字典值显示都是后端处理，后期修改的话后端直接在数据库改下同步到缓存中就行了
|
Select Language