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

[chaleaoch]

我比较好奇为啥?
js 坑吗?
不是把逻辑放到浏览器加载,这样服务端开销更小吗?

请教个具体问题.

一个 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 类似这种

是这个意思不?

举个例子吧.
之前的逻辑是过滤职业是学生,年龄大于 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 要如何表示..

希望我解释清楚了.

[dengjunwen]

前后端都可以，视业务需求来定。没有一概而论。但是尽可能的让客户端轻，同时客户端存在很大危险性。这里只是例举了一点点。

[charten]

当我不想加班的时候我就这样跟我们后端说....

[594duck]

我预估有很多划胖的，果然有很多过来掼浪头，划胖的。

[vishun]

@ETO 当然是你分页啊，你都从数据库查出来了，你不分页，然后让 java 每次全部获取再分页？这种能从根源上优化的你不做，反而推给 java 和前端？怎么想的？

[thtznet]

所以软件开发领域有个专门的职位：架构师。这种问题不需要编写生产代码的工程师考虑，在架构设计的时候就已经是确定的事。

[taowen]

所有的读操作都是前端业务，后端接口也应该是前端来写。后端人员只负责写，保证业务规则不被破坏。

[IssacTomatoTan]

支持业务逻辑不应该前端兼容，要是逻辑有问题你后端换了个人维护，他绝对想 4 的心都有

[chaleaoch]

@jake361 是,所以这个 api 应该如何设计?

[chaleaoch]

@KuroNekoFan 感谢回复, 所以这种情况应该如何处理?

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

还是有第三种解决方案.

我不是很清楚,真心请教.

[chaleaoch]

@gdtdpt #70 你给的两个解决方案好像和我说的一样.

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

[chaleaoch]

@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]

左侧菜单树，
要统计每个菜单下的数据总数，
放在前端调用 80 多个接口，
每个接口的格式还各种各样不统一，
心里一万匹草泥马奔腾而过，
嘴上还得说：嗯，好的。
这就是前端狗的悲哀。

[mkdir]

@zpxshl 好处是可以兼容不同的客户端

[KuroNekoFan]

@chaleaoch 你讲的这种情况属于需求方有病

[thtznet]

问一下问题，这个不是软件架构划分的问题，我个人认为是后端工程师技能水平不足以实践这种级别的项目。
这是很典型的 查询对象模式，将前端需要的任意的参数请求到查询对象，后端返回 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]

@thtznet 如果能根据问题 给出可执行的解决方案就更好了...

前端需要的任意的参数 这个 api 应该如何设计呀?
queryid = 1 是将一个 query 放到数据库中或者缓存中吗? 我觉得肯定是要存起来的. 两次 http 交互是独立的.

[tesguest123]

让前端滚蛋，你前后一把梭

[zzl22100048]

你想要的方案三可以参考 jhipster

[okampfer]

@w88975 #19
同意。尤其是当遇到图表（折线图、柱状图、饼状图），或者其它需要用到 canvas 甚至是 WebGL 这些技术的时候，复杂度还会更上一个台阶。

就算是只有表格和表单（尤其是表单），也可以很复杂。比如大型表单里的字段显隐互相关联，某些字段的可选项、格式要求等等互相关联，业务需求复杂的时候绝对写到想吐。

[jake361]

@chaleaoch 首先这种需求比较少吧。。不管怎么样，质疑一下产品...
你的第一个建议，就算前端请求两次，万一两个数据有重叠呢.. 前端还要去重，如果涉及到翻页呢？ 就更不好处理了。所以这也是最不推荐的一种方案。
第二个是可以，但是这种语义化不是很强，如果这种特殊情况的需求比较少，那么我认为可以这样处理 type=sdu_age10ortea_age20 这样
第三个如果这个 10 和 20 是变化的，那么可能还是需要做 url 特殊取值，因为一般来说 url 的语义都是&&的关系，可以加一个关系说明字段，其实类似于第二种方案，只不过数据可变 type=sdu_age.10,or,tea_age.20 这个就看怎么定义吧。

[ETO]

@vishun 麻烦审题，我说了，我这边是统计数据，是从好几张表里统计出来的，最后统计出来数据最多不会超过 500 条。你告诉我，我分页的意义在哪里？