今天听前端同事说, 现在流行把业务放后端做,前端越简单越好. 大前端是两三年前比较流行?

2020-08-27 18:03:37 +08:00
 chaleaoch
我比较好奇为啥?
js 坑吗?
不是把逻辑放到浏览器加载,这样服务端开销更小吗?
17460 次点击
所在节点    程序员
121 条回复
dengjunwen
2020-08-28 18:41:59 +08:00
前后端都可以,视业务需求来定。没有一概而论。但是尽可能的让客户端轻,同时客户端存在很大危险性。这里只是例举了一点点。
charten
2020-08-28 19:48:45 +08:00
当我不想加班的时候我就这样跟我们后端说....
594duck
2020-08-28 20:07:23 +08:00
我预估有很多划胖的,果然有很多过来掼浪头,划胖的。
vishun
2020-08-28 20:13:54 +08:00
@ETO 当然是你分页啊,你都从数据库查出来了,你不分页,然后让 java 每次全部获取再分页?这种能从根源上优化的你不做,反而推给 java 和前端?怎么想的?
thtznet
2020-08-28 20:15:30 +08:00
所以软件开发领域有个专门的职位:架构师。这种问题不需要编写生产代码的工程师考虑,在架构设计的时候就已经是确定的事。
taowen
2020-08-28 21:16:31 +08:00
所有的读操作都是前端业务,后端接口也应该是前端来写。后端人员只负责写,保证业务规则不被破坏。
IssacTomatoTan
2020-08-28 21:22:57 +08:00
支持业务逻辑不应该前端兼容,要是逻辑有问题你后端换了个人维护,他绝对想 4 的心都有
chaleaoch
2020-08-28 23:10:12 +08:00
@jake361 是,所以这个 api 应该如何设计?
chaleaoch
2020-08-28 23:11:53 +08:00
@KuroNekoFan 感谢回复, 所以这种情况应该如何处理?

那只能请求两次 api 了?
或者, 把逻辑隐藏在后端, 导致 实际执行逻辑和 api 的 filter 看起来不一致.

还是有第三种解决方案.

我不是很清楚,真心请教.
chaleaoch
2020-08-28 23:22:20 +08:00
@gdtdpt #70 你给的两个解决方案好像和我说的一样.

"说得难听点,如果后端只想做数据库中间件,不处理业务,那前端整一套 SSR 框架直连数据库就行了,要后端干什么。"
这个我现在也有这个疑问, 后端的精力应该是处理高并发,不过哪有那么过高并发的场景. 作为一个后端我还很担心将来是否会失业. 现在看来不太会了~
chaleaoch
2020-08-28 23:32:13 +08:00
@jake361 #67

举个例子吧.
之前的逻辑是过滤职业是学生,年龄大于 10 的人.
people/?job=student&age_gt=10
现在的逻辑是,下面这个 api 表示过滤职业是学生,年龄大于 10, 或者 职业是老师, 年龄等于 20 的人
people/?job=student&age_gt=10

我的建议是
1. 要么 两个 api 前端做合并
people/?job=student&age_gt=10
people/?job=teacher&age=20
2. 要么 加一个参数类型 type == 1 表示上面这两种情况.

其实还有第三种方案, 让 url 支持复杂过滤.譬如...这个我没想好 url 要如何表示..

希望我解释清楚了.
jatai
2020-08-29 00:12:58 +08:00
左侧菜单树,
要统计每个菜单下的数据总数,
放在前端调用 80 多个接口,
每个接口的格式还各种各样不统一,
心里一万匹草泥马奔腾而过,
嘴上还得说:嗯,好的。
这就是前端狗的悲哀。
mkdir
2020-08-29 01:25:30 +08:00
@zpxshl 好处是可以兼容不同的客户端
KuroNekoFan
2020-08-29 05:13:03 +08:00
@chaleaoch 你讲的这种情况属于需求方有病
thtznet
2020-08-29 11:44:47 +08:00
问一下问题,这个不是软件架构划分的问题,我个人认为是后端工程师技能水平不足以实践这种级别的项目。
这是很典型的 查询对象模式,将前端需要的任意的参数请求到查询对象,后端返回 queryid,前端携带 queryid 二次请求,可以封装任意的查询条件,能应用设计模式应该是后端工程师的基本任职条件,除非招的后端真的只会 CRUD 。
-----------------------------------------------------------------------------------------------------------------------------
举个例子吧.
之前的逻辑是过滤职业是学生,年龄大于 10 的人.
people/?job=student&age_gt=10
现在的逻辑是,下面这个 api 表示过滤职业是学生,年龄大于 10, 或者 职业是老师, 年龄等于 20 的人
people/?job=student&age_gt=10

我的建议是
1. 要么 两个 api 前端做合并
people/?job=student&age_gt=10
people/?job=teacher&age=20
2. 要么 加一个参数类型 type == 1 表示上面这两种情况.

其实还有第三种方案, 让 url 支持复杂过滤.譬如...这个我没想好 url 要如何表示..
-------------------------------------------------------------------------------------------------------------------------------
chaleaoch
2020-08-29 16:41:24 +08:00
@thtznet 如果能根据问题 给出可执行的解决方案就更好了...

前端需要的任意的参数 这个 api 应该如何设计呀?
queryid = 1 是将一个 query 放到数据库中或者缓存中吗? 我觉得肯定是要存起来的. 两次 http 交互是独立的.
tesguest123
2020-08-29 18:46:28 +08:00
让前端滚蛋,你前后一把梭
zzl22100048
2020-08-29 19:07:36 +08:00
你想要的方案三可以参考 jhipster
okampfer
2020-08-29 22:15:27 +08:00
@w88975 #19
同意。尤其是当遇到图表(折线图、柱状图、饼状图),或者其它需要用到 canvas 甚至是 WebGL 这些技术的时候,复杂度还会更上一个台阶。

就算是只有表格和表单(尤其是表单),也可以很复杂。比如大型表单里的字段显隐互相关联,某些字段的可选项、格式要求等等互相关联,业务需求复杂的时候绝对写到想吐。
jake361
2020-08-31 14:13:00 +08:00
@chaleaoch 首先这种需求比较少吧。。不管怎么样,质疑一下产品...
你的第一个建议,就算前端请求两次,万一两个数据有重叠呢.. 前端还要去重,如果涉及到翻页呢? 就更不好处理了。所以这也是最不推荐的一种方案。
第二个是可以,但是这种语义化不是很强,如果这种特殊情况的需求比较少,那么我认为可以这样处理 type=sdu_age10ortea_age20 这样
第三个如果这个 10 和 20 是变化的,那么可能还是需要做 url 特殊取值,因为一般来说 url 的语义都是&&的关系,可以加一个关系说明字段,其实类似于第二种方案,只不过数据可变 type=sdu_age.10,or,tea_age.20 这个就看怎么定义吧。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/701987

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX