我是后端,前端工程师这个要求是否合理?[修改了示例]

161次阅读

共计 2500 个字符,预计需要花费 7 分钟才能阅读完成。

先前举的例子涉及隐私,导致大家误解,下面改一下例子:
我做的接口返回的数据:
user_sex: 男
user_age: 19
user_name: 张三
user_photo: http://xxx.com/xxx.jpg
需求:
前端需要根据年龄和性别显示 成年男性,成年女性,未成年男性,未成年女性
前端工程师:
我又要判断性别又要判断年龄,太麻烦了,你能不能给接口加一个字段 user_type=1/2/3/4(1/2/3/ 4 分别代表成年男性,成年女性,未成年男性,未成年女性)
上面的例子简化过了,实际上前端可能需要根据更多条件判断

典型前端思维,根本不知道动接口的影响范围会更大我全栈,后端都给源数据了,前端加个判断不就行了,能有多麻烦。后端返回类型到时候要改就麻烦了。接口有给年龄当然前端判断
还有 加毛线的 user_type?接口当然是希望能多业务复用,任何特殊定制全部拒绝。
这种前端要是非得要后端加 user_type 不愿意前端判断我直接开了他很河里啊,你后端判断一下再返回就行,前端后端总有一个得判断一下,这个是不可避免的。哈哈哈,不太合理,实际前端和后端实现的代码是差不多的,就是想偷懒,除非是用户信息保护的情况。还有一种情况,就是你们还在用 jquery。。。做不了,得加钱我们后端就是没数据就不返回 key 他这样做我会要求他加上 就算是空 value 值涉及到隐私的正常情况应该由后端实现保障,不过这需求本身也没啥难度从 and 改成了 or 前端这理由站不住脚啊。。前端判断不是比后端更灵活吗?
如果是基于用户隐私的考虑,那倒确实应该在后端处理。后端判断,前端判断别人直接从接口取 user_photo
当然,严格地讲应该是前后端都判断

yousihai 发表于 2022-5-2 14:06
涉及到隐私的正常情况应该由后端实现保障,不过这需求本身也没啥难度

假设不涉及隐私。

flyqie 发表于 2022-5-2 14:06
前端这理由站不住脚啊。。前端判断不是比后端更灵活吗?
如果是基于用户隐私的考虑,那倒确实应该在后端处 …

只是随便举了个例子。假设不涉及隐私。我们这里是要求前后端都要做判断的,不依赖于前端处理数据看是否为内部系统或者公开的
内部系统对信息隐私没那么重要的话 基本都是前端判定
公开网站啥的 最好还是后端尽量少的返回数据虽然前后端都能做,但是我更倾向后端做。很多时候前端做,涉及到需求变更更改上架审核很麻烦,数据驱动 UI 更合适这种涉及到隐私的必须后端判断
前端被人逆向直接加请求上去导致隐私数据泄露看你工作保不保的住

gdtv 发表于 2022-5-2 14:08
只是随便举了个例子。假设不涉及隐私。

不涉及隐私的话,前端判断呗。
将来需求变动,后端不太好改吧。不管前後端,要處理這些判斷都很簡單,但這種功能前端提後端處理很合理,永遠不要相信使用者不會抓 api

喵酱暗恋我 发表于 2022-5-2 14:12
这种涉及到隐私的必须后端判断
前端被人逆向直接加请求上去导致隐私数据泄露看你工作保不保的住 …

例子改了一下,请帮忙再看看

gdtv 发表于 2022-5-2 14:15
例子改了一下,请帮忙再看看

原则上不给他加字段 除非新需求里的字段无法根据已有数据推演出来

喵酱暗恋我 发表于 2022-5-2 14:17
原则上不给他加字段 除非新需求里的字段无法根据已有数据推演出来

是的,接口这边应该尽量少做更改。我们这边这种倾向于后端直接返实际数据,少部分简单接口可以由前端逻辑实现 — 少部分
即:前端不要涉及过多逻辑 – Boss 的建议不合理不合理,返回基本信息即可。
问他是猪吗这需求,前端或者后端都能做,不过如果后端做了,前端就省事了。后端判断快 得加钱我是后端,前端工程师这个要求是否合理?[修改了示例]这吊毛估计没写过后台合理,这是最基本的需求
假设由前端来处理,那么涉及到分页怎么解决?这种需求明显是前端处理. 原因是:
前端目前有这个需求, 今后会不会砍掉呢? 砍掉后, 后端是不是又要去删除这个字段?
就算后端返回了处理后的字段, 前端也要进行适配后再次提交审核, 一样没有什么灵活性可言
能用客户端的算力, 就要尽量少用服务端的这不应该是项目负责人决定的嘛,不然你们平时前后端扯皮玩啊。我全栈,后端都给源数据了,前端加个判断不就行了,能有多麻烦。后端返回类型到时候要改就麻烦了。

flyqie 发表于 2022-5-2 14:21
是的,接口这边应该尽量少做更改。

建议再搞一个新接口返回 1234 就行,前端爱调用不调用前端自己连接字符串简单。。接口有给年龄当然前端判断
还有 加毛线的 user_type?接口当然是希望能多业务复用,任何特殊定制全部拒绝。
这种前端要是非得要后端加 user_type 不愿意前端判断我直接开了他前段又不是不能调用出来,不要随便加一堆字段,容易出错

xuliliang 发表于 2022-5-2 14:45
合理,这是最基本的需求

看帖主描述,这貌似也不涉及到分页吧?
给了 user_type,无非就是将前端工作量降下来了而已。
好像没说这个 user_type 会往回传做查询条件?搞个新接口,就返回个 1234,爱用不用,想用就另外调用,不用就自己判断,已有接口不去加逻辑这前端实现很简单吧。都比较懒,扯的功夫都做完了,更倾向后端做,前端不要涉及太多业务逻辑不能加,滚

flyqie 发表于 2022-5-2 15:42
看帖主描述,这貌似也不涉及到分页吧?
给了 user_type,无非就是将前端工作量降下来了而已。

如果只是查询详情,基本上都不会涉及到过滤这一说,指定 id 就行。
需要用到过滤的,大多数都是列表。前端修改比后端容易很多
逻辑和字段能不改就不改如果这 user_sex,user_age 两条数据接口有输出的话,那么前端做,第一:性能,虽然现在 cpu 性能都比较高,且这个计算也不消耗什么,但是前端处理比会服务器处理来的快。第二:灵活,后期维护方便,如果这个的调整,那么前端修改即可,api 不需要动。
一家之言,仅供参考。前端根据你提供的数据就可以判断了,不需要重复劳动。很明显前端用了三大框架之一,做这种判断非常麻烦,所以才找你干活,然后他直接绑定字段就可以了。

正文完
 0