今天听前端同事说, 现在流行把业务放后端做,前端越简单越好. 大前端是两三年前比较流行?
chaleaoch · 2020-08-27 18:03:37 +08:00 · 17370 次点击这是一个创建于 1549 天前的主题，其中的信息可能已经有所发展或是发生改变。
我比较好奇为啥?
js 坑吗?
不是把逻辑放到浏览器加载,这样服务端开销更小吗?
js 坑吗?
不是把逻辑放到浏览器加载,这样服务端开销更小吗?
第 1 条附言 · 2020-08-28 12:31:58 +08:00
请教个具体问题.
一个 resource 两个 field : a 和 b
a = ['open','closed', 'error']
b = ['true', 'false']
api 设计成 <resource>/?a=open
现在需求改了
当 a == error
返回
a == error or (a == open & b==false) or (a == closed & b==false)
a == open or a == closed 相应的改成
a == open & b == true
像这种情况, 你打算怎么处理 我的建议是 前端请求两次 ajax 就齐活了. 前端说,不, 应该后端改.
这种属于业务逻辑吧?我觉得. 但是这接口有问题啊. 至少也得改成 <resource>/?type=a1 <resource>/?type=a2 <resource>/?type=a3 类似这种
是这个意思不?
第 2 条附言 · 2020-08-28 23:32:56 +08:00
举个例子吧.
之前的逻辑是过滤职业是学生,年龄大于 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 要如何表示..
希望我解释清楚了.
之前的逻辑是过滤职业是学生,年龄大于 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 要如何表示..
希望我解释清楚了.
 |
101
dengjunwen 2020-08-28 18:41:59 +08:00 via Android
前后端都可以，视业务需求来定。没有一概而论。但是尽可能的让客户端轻，同时客户端存在很大危险性。这里只是例举了一点点。
|
 |
102
charten 2020-08-28 19:48:45 +08:00
当我不想加班的时候我就这样跟我们后端说....
|
 |
103
594duck 2020-08-28 20:07:23 +08:00
我预估有很多划胖的，果然有很多过来掼浪头，划胖的。
|
 |
104
vishun 2020-08-28 20:13:54 +08:00
@ETO 当然是你分页啊，你都从数据库查出来了，你不分页，然后让 java 每次全部获取再分页？这种能从根源上优化的你不做，反而推给 java 和前端？怎么想的？
|
 |
105
thtznet 2020-08-28 20:15:30 +08:00  1
所以软件开发领域有个专门的职位：架构师。这种问题不需要编写生产代码的工程师考虑，在架构设计的时候就已经是确定的事。
|
 |
106
taowen 2020-08-28 21:16:31 +08:00
所有的读操作都是前端业务，后端接口也应该是前端来写。后端人员只负责写，保证业务规则不被破坏。
|
 |
107
IssacTomatoTan 2020-08-28 21:22:57 +08:00 via Android
支持业务逻辑不应该前端兼容，要是逻辑有问题你后端换了个人维护，他绝对想 4 的心都有
|
 |
109
chaleaoch OP @KuroNekoFan 感谢回复, 所以这种情况应该如何处理?
那只能请求两次 api 了? 或者, 把逻辑隐藏在后端, 导致 实际执行逻辑和 api 的 filter 看起来不一致. 还是有第三种解决方案. 我不是很清楚,真心请教. |
|
110
chaleaoch OP @gdtdpt #70 你给的两个解决方案好像和我说的一样.
"说得难听点，如果后端只想做数据库中间件，不处理业务，那前端整一套 SSR 框架直连数据库就行了，要后端干什么。" 这个我现在也有这个疑问, 后端的精力应该是处理高并发,不过哪有那么过高并发的场景. 作为一个后端我还很担心将来是否会失业. 现在看来不太会了~ |
|
111
chaleaoch OP @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 要如何表示.. 希望我解释清楚了. |
 |
112
jatai 2020-08-29 00:12:58 +08:00 via Android
左侧菜单树，
要统计每个菜单下的数据总数， 放在前端调用 80 多个接口， 每个接口的格式还各种各样不统一， 心里一万匹草泥马奔腾而过， 嘴上还得说：嗯，好的。 这就是前端狗的悲哀。 |
 |
114
KuroNekoFan 2020-08-29 05:13:03 +08:00 via iPhone
@chaleaoch 你讲的这种情况属于需求方有病
|
|
115
thtznet 2020-08-29 11:44:47 +08:00 1
问一下问题，这个不是软件架构划分的问题，我个人认为是后端工程师技能水平不足以实践这种级别的项目。
这是很典型的 查询对象模式，将前端需要的任意的参数请求到查询对象，后端返回 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 要如何表示.. ------------------------------------------------------------------------------------------------------------------------------- |
|
116
chaleaoch OP @thtznet 如果能根据问题 给出可执行的解决方案就更好了...
前端需要的任意的参数 这个 api 应该如何设计呀? queryid = 1 是将一个 query 放到数据库中或者缓存中吗? 我觉得肯定是要存起来的. 两次 http 交互是独立的. |
 |
117
tesguest123 2020-08-29 18:46:28 +08:00 via Android
让前端滚蛋，你前后一把梭
|
 |
118
zzl22100048 2020-08-29 19:07:36 +08:00 via iPhone
你想要的方案三可以参考 jhipster
|
 |
119
okampfer 2020-08-29 22:15:27 +08:00
@w88975 #19
同意。尤其是当遇到图表（折线图、柱状图、饼状图），或者其它需要用到 canvas 甚至是 WebGL 这些技术的时候，复杂度还会更上一个台阶。 就算是只有表格和表单（尤其是表单），也可以很复杂。比如大型表单里的字段显隐互相关联，某些字段的可选项、格式要求等等互相关联，业务需求复杂的时候绝对写到想吐。 |
 |
120
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 这个就看怎么定义吧。 |
Select Language