今天听前端同事说, 现在流行把业务放后端做,前端越简单越好. 大前端是两三年前比较流行?
js 坑吗?
不是把逻辑放到浏览器加载,这样服务端开销更小吗?
如果只是鸡毛蒜皮的逻辑,随意。剪刀石头布都可以。
另外,对原生客户端来说,不用说,肯定要把逻辑重心放在服务端,起码后端改逻辑不需要用户升级 app 。
以上是我公司内部某个应用整改前的真实情况,这个应用后端开发总是想着只把数据给到前端就行,业务逻辑能让前端做的都让前端做,前端实在做不了的才会放到后端。
整改前,没人觉得几 mb 的 bundle.js 有什么问题,用开发的用的电脑测试没觉得慢,直到有一天领导打开一个页面加载需要 30 多秒,领导强制要求整改。在没有专业前端技术主管的情况下,没有人知道应该怎么改、往哪个方向改,前端代码写得太自由,都揉在一起了,拆分也需要重新梳理需求,整个过程异常痛苦。
相对来说,后端主要是用 Java 开发,强类型保证了代码不能乱写,逻辑至少是可读的,springboot 框架和 mvc 的代码结构深入 curd boy 心,结构清楚逻辑好梳理,光看代码就能看个大概,相比前端一个 ajax 如果不真正执行,返回什么数据我都不太清楚的情况好太多了。
考虑到团队成员的能力差异、异常排查的难度、可能出现的坑的大小、帮别人填坑的难易程度等因素,如果我是项目管理,我也会要求逻辑代码放后端。
对于服务端的开销问题,一般业务逻辑不太容易影响服务器性能,如果真的到了由业务逻辑影响服务器性能的时候,也应该好好审查一下后端代码或者逻辑是不是有问题,一般这种代码或者逻辑放到前端也不一定能顶得住(比如对大量数据做聚合)。
其实说白了,不管后端有多么瞧不起前端,即使你把前端看作切图仔,不配称为程序员,你也不得不承认,大多数情况下,一个业务,前端的工作量永远大于后端。
听他们吹牛逼永远很精彩 。
因此,你的这个看待整体选型的“方式”,其实已经是过时的!
首先要做技术选型,在确定有哪些技术问题要攻克,有哪些业务状态和业务前景,做好技术架构后,再看待这个问题。
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
类似这种
是这个意思不?
还是自己全干来的靠谱。。。。
如果前端只是改所调用接口的 url,不增加调用次数的情况,我赞成前端改,因为有别的接口满足业务需要。
但是需要前端改成调用多次接口并封装部分业务逻辑,我认为应该后端改,以我的开发习惯我会避免在前端写这种包含部分业务逻辑的代码。
理由是今天这个业务从调用一次改成调用两次,可能过段时间业务需求又变了,就会变成调用三次,或者有其他的前端接口调用由一次也变成调用多次,这样出现什么问题到底是前端的问题还是后端的问题说不清楚,也不好排查,出现问题需要前端后端一起看数据和逻辑,浪费人力和时间。前后端职责模糊,也容易前后端互相推诿。
说得难听点,如果后端只想做数据库中间件,不处理业务,那前端整一套 SSR 框架直连数据库就行了,要后端干什么。
最好还是服务端统一做处理更好。一端处理,多端舒适。
另外,对于图片的处理(比如生成、编辑图片)这种只能客户端做,服务端做成本会很高(带宽、CPU 等)。
我并没有站在一个纯前端的角度来讨论这个问题,我也是做了多年的后端,我很讨厌写前端,就是因为前端相对于后端来说,太杂了,没有像后端那么多年积累起来的标准库(近几年稍微好那么一点),同样的业务,前端的选择更多,工作量也更多.
处理纯数据,和写用户交互的东西相比,还是纯数据处理起来更简单明了
以前后端鄙视前端,那是因为前端真没啥技术含量,”切图仔”们只知道填数据,画页面,对数据来源以及数据的处理根本不用关心. 我不能说现在前端多有技术含量(也可能没有),但就事论事的话,工作量是特别大的.
打个比方,写个修改用户资料的业务,后端只需要处理字段,校验字段,校验不通过返回什么,通过又是什么,然后更新 DB.
前端首先要完成这个页面,然后再处理数据,例如头像要用什么组件东西展示,是否可修改,修改的话,得用哪个接口去上传图片,上传状态,各种提示,表单的校验等等,不说复杂不复杂,至少比起纯数据处理来说,是复杂的.
就好比 V2EX 的回帖时间,后端只返回时间戳,前端要去判断: 大于 24 小时,展示完整年月日时分秒,小于 24 小时,展示 xx 小时前,这时候,后端要是直接返回这个时间,前端就能省很大一部分事,毕竟大多时候,前端也只是拿时间戳来做 format 成字符串,而不是做条件查询
并不是所有用户都会喜欢升级的. 如果很多业务要依靠前端升级版本来解决.
为什么不尽可能多的功能可扩展, 而不必用户升级来解决呢.
exp: 日期. 后台传时间戳 & 后台传日期字符串.
万一哪天要展示逻辑改变, 是不是还要更新前端版本来解决这个问题?
btw: 改不改都看产品心情. 前端后端要佛系. 手动狗头