楼主本身 技术栈是移动端(ios + flutter),前端在学(新手)
以下是一个实际的应用场景举例:
一个普通的列表显示接口 A:
其中 styles 和 types 分别需要另外调用 接口 B 和 接口 C ,返回的数据格式类似如下:
需要匹配用第一个接口里的 styles 的数字去匹配第二个数组里的 value,一旦匹配上把当前的 label 值塞到第一个接口的自定义字段的返回值里去,最后显示
v 友的第一个观点大概是上来先把接口 2 所有类型的数据拉取下来,然后本地维护这个数组去做匹配,这个方案呢也是我一开始想到的,但是呢后台不支持所有类型数据下发,第二呢后端前面提过这个 value 和 label 的绑定是动态的,我猜大概是为了实时性的缘故吧
目前状态呢是我这边已经处理完了这部分数据,但是安卓呢不愿意处理,后端也不愿意处理 我这边就是最常规的做法,同时请求 x 个接口,然后等待都返回后 去匹配值,用哈希表稍微优化了一下匹配时间复杂度,但我觉得这对一个最基础的列表展示是不是过于繁琐了。如果风格是 100 个,返回的是 80,90,99 呢。
鉴于 V2 大佬多,想问问像这种情况有没有标准,到底应该哪边处理比较好,后端处理的话当然也要做匹配。还有个疑问就是这部分数据上传的时候难道不是上传字符串的吗,会有什么场景需要专门把这些风格还专门做成 1,2,3 ,4.在我看来这不是多此一举吗。
1
renmu 44 天前 via Android ![]() 我是前端,我认为应该后端做,但是他比我壮得多,还是我来做吧
|
![]() |
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. C 端应用,一般用户体验优先。在前端处理的话,会多一次请求,导致用户等待时间变长,所以后端处理。 2. M 端应用,一般效率优先。看前后端开发压力,和后续维护成本。 具体到你这个问题,后端处理更好。iOS 和 android 需要重复开发,逻辑收敛到后端,维护成本更低, 用户体验也更好。 上面只是说放在哪一"端"合适,实际由前端人员还是后端人员来做就需要"讨论"了。大厂里会存在前端开发人员写后端服务,可以搜一下 BFF 层。 |
23
Irisxx OP @iidear2015 了解了下,确实 BFF 适用于这种场景,只是我的技术栈中没有 JAVA ,前端做 BFF 避不开多线程拉请求 。
|
24
dayeye2006199 43 天前
问就是 graphQL
|
25
gerefoxing 43 天前
这种字典值显示都是后端处理,后期修改的话后端直接在数据库改下同步到缓存中就行了
|