V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
chaleaoch
V2EX  ›  程序员

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

  •  
  •   chaleaoch · 2020-08-27 18:03:37 +08:00 · 17313 次点击
    这是一个创建于 1531 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我比较好奇为啥?
    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 要如何表示..

    希望我解释清楚了.
    121 条回复    2020-09-01 13:17:02 +08:00
    1  2  
    joyhub2140
        1
    joyhub2140  
       2020-08-27 18:19:16 +08:00 via Android   ❤️ 3
    看情况吧,前端如果计算量太大,对移动设备不友好,可能造成设备发热大,风扇呼呼叫,体验差。

    如果只是鸡毛蒜皮的逻辑,随意。剪刀石头布都可以。

    另外,对原生客户端来说,不用说,肯定要把逻辑重心放在服务端,起码后端改逻辑不需要用户升级 app 。
    pushback
        2
    pushback  
       2020-08-27 18:33:16 +08:00
    看情况吧,减少流程性的接口肯定是要后端做的,
    前端凑数据要点逻辑,现在很多逻辑都是交互性的吧?(我不是前端不清楚)
    个人认为前端逻辑(指数据方面)过多,那后端挺不负责的
    victor
        3
    victor  
       2020-08-27 18:36:01 +08:00   ❤️ 12
    看情况吧,减少后端的开发任务我一般都是这么跟领导吹的。
    把复杂计算放在前端,消耗的是用户的硬件设备和时间来做处理和计算,能给我们省服务器的成本。
    gdtdpt
        4
    gdtdpt  
       2020-08-27 18:36:26 +08:00   ❤️ 7
    现在前端 spa 框架应用如果不做好架构规划,代码审核等约束,是很容易构建出以 mb 为单位的 bundle.js ,再加上很多公司内网的客户端(电脑浏览器)性能并不高,如果再使用 IE 打开,再 ajax 请求上千条数据,是很容易直接卡死的,用户体验非常不好。

    以上是我公司内部某个应用整改前的真实情况,这个应用后端开发总是想着只把数据给到前端就行,业务逻辑能让前端做的都让前端做,前端实在做不了的才会放到后端。
    整改前,没人觉得几 mb 的 bundle.js 有什么问题,用开发的用的电脑测试没觉得慢,直到有一天领导打开一个页面加载需要 30 多秒,领导强制要求整改。在没有专业前端技术主管的情况下,没有人知道应该怎么改、往哪个方向改,前端代码写得太自由,都揉在一起了,拆分也需要重新梳理需求,整个过程异常痛苦。

    相对来说,后端主要是用 Java 开发,强类型保证了代码不能乱写,逻辑至少是可读的,springboot 框架和 mvc 的代码结构深入 curd boy 心,结构清楚逻辑好梳理,光看代码就能看个大概,相比前端一个 ajax 如果不真正执行,返回什么数据我都不太清楚的情况好太多了。

    考虑到团队成员的能力差异、异常排查的难度、可能出现的坑的大小、帮别人填坑的难易程度等因素,如果我是项目管理,我也会要求逻辑代码放后端。

    对于服务端的开销问题,一般业务逻辑不太容易影响服务器性能,如果真的到了由业务逻辑影响服务器性能的时候,也应该好好审查一下后端代码或者逻辑是不是有问题,一般这种代码或者逻辑放到前端也不一定能顶得住(比如对大量数据做聚合)。
    wuwukai007
        5
    wuwukai007  
       2020-08-27 18:37:34 +08:00   ❤️ 10
    划重点: 听前端同事说
    cassyfar
        6
    cassyfar  
       2020-08-27 18:49:02 +08:00
    大前端什么时候存在过。。。我工作 5 年没见到。
    Wincer
        7
    Wincer  
       2020-08-27 19:02:31 +08:00
    是真的,因为前端逻辑比较多的话会让客户机 CPU 运转加速,造成电脑发热量多,加剧温室效应,一点不环保。(狗
    fhsan
        8
    fhsan  
       2020-08-27 19:05:49 +08:00
    @cassyfar 都喊了五年以上了,
    mht
        9
    mht  
       2020-08-27 19:05:51 +08:00
    我自己写前后端,我感觉论维护或者开发的话,还是后端把一些计算做好最简单,前端就是拿到数据展示下就行。
    ditel
        10
    ditel  
       2020-08-27 19:08:06 +08:00 via Android
    架构师在哪?接口规范在哪?交互体验在哪?随意的组合前端真的没有问题吗
    zpxshl
        11
    zpxshl  
       2020-08-27 19:10:24 +08:00 via Android   ❤️ 1
    @joyhub2140 1 逻辑放后端有个坏处,后端要不断兼容旧版客户端
    zjp
        12
    zjp  
       2020-08-27 19:19:25 +08:00
    大前端的重点不是统一 APP 端 Web 端吗...
    前端计算非常不可信,遇到过因为页面卡住而提交错数值的
    KuroNekoFan
        13
    KuroNekoFan  
       2020-08-27 20:01:49 +08:00 via iPhone   ❤️ 3
    有的后端就是弱智,设计的傻逼接口不仅毫无意义还净给前端添麻烦,还美其名曰业务需求
    KuroNekoFan
        14
    KuroNekoFan  
       2020-08-27 20:02:59 +08:00 via iPhone   ❤️ 1
    至于主贴的问题,楼主理解交互逻辑和业务逻辑的区别吗
    murmur
        15
    murmur  
       2020-08-27 20:09:14 +08:00
    业务肯定后端的,前端那不是白送给竞争对手,放前端也得加一堆混淆反调试
    ffw5b7
        16
    ffw5b7  
       2020-08-27 20:18:53 +08:00 via Android
    大前端不是指 api 调用侠吗?面对应用开发,调底层服务接口
    ly1836
        17
    ly1836  
       2020-08-27 20:27:45 +08:00
    作为一个后端,我是非常不信任前端来处理业务逻辑的。
    shyangs
        18
    shyangs  
       2020-08-27 20:35:24 +08:00
    業務邏輯放前端, 那都被競爭對手看光了, 看你老闆覺不覺得業務邏輯是機密.
    w88975
        19
    w88975  
       2020-08-27 20:40:17 +08:00   ❤️ 24
    作为一个全栈来说,现在的软件开发,其实前端的工作量大于后端的
    说的直白一点,90%的后端,都是 crud,现有框架成熟的情况下,很容易就能产出需要的功能接口
    而前端不一样,即使同样的逻辑下,不同的业务有不同的展示方式,操作逻辑,这块虽然不难,但是是实实在在的工作量。
    当我自己一个人做完整的项目的时候,更倾向于把更多的业务放在后端去处理,前端就简单的展示,简单的交互操作,这样开发效率其实是很高的。
    当我只做前端的时候,我也更希望后端能够处理更多的东西。

    其实说白了,不管后端有多么瞧不起前端,即使你把前端看作切图仔,不配称为程序员,你也不得不承认,大多数情况下,一个业务,前端的工作量永远大于后端。
    zjsxwc
        20
    zjsxwc  
       2020-08-27 20:43:07 +08:00 via Android
    就是本来前端的活,分出来给 nodejs 做中台,处理完数据后最后给后端。
    jingcoco
        21
    jingcoco  
       2020-08-27 20:49:15 +08:00 via iPhone
    。。。。。最近刚和后端怼了一下。然后领导各打 20 大板。互相妥协了一下。
    xylophone21
        22
    xylophone21  
       2020-08-27 20:50:59 +08:00
    前端搭个 nodejs,结束
    KuroNekoFan
        23
    KuroNekoFan  
       2020-08-27 20:57:21 +08:00 via iPhone
    @w88975 实话
    u823tg
        24
    u823tg  
       2020-08-27 22:31:54 +08:00
    所以前端加了一波薪后把活又扔到后端了
    Tink
        25
    Tink  
       2020-08-27 22:35:38 +08:00 via Android
    计算绝对要放到后端,放到前段等着别人 hack 呢
    gouflv
        26
    gouflv  
       2020-08-27 23:34:58 +08:00 via iPhone
    前端说啥就是啥,你不懂有什么办法
    statement
        27
    statement  
       2020-08-27 23:44:33 +08:00 via iPhone
    后端一把梭 css 样式都给了。不给前端添麻烦。 因为前端也是我
    ffxrqyzby
        28
    ffxrqyzby  
       2020-08-28 01:13:26 +08:00
    我投后端处理一票
    ericgui
        29
    ericgui  
       2020-08-28 01:18:49 +08:00
    我们公司是后端不给力,除了给数据,啥也不会
    前端被迫当场计算很多逻辑
    所以很慢
    jones2000
        30
    jones2000  
       2020-08-28 02:03:58 +08:00
    现在 PC 和手机性能都很高( GPU 直接就可以拿来计算), 可以支持一些本地的计算,如果什么都放在后台算,就浪费了这些配置了。 只是现在大部分前端做算法的能力不行,只会一些 UI, 让前端做算法又慢又容易出错,还不如后台算好给前端。可以让后台直接把部分业务移植到js上,给前端用。我开源过一个金融图形库和策略指标引擎都都前端计算的( https://github.com/jones2000/HQChart )。只要前端能力行,一样可以做很多后台的活。
    而后台java, c++等应该做一些业务计算模块,什么读写数据库的操作的体力活都给nodejs,py的人来干,java,c++直接做计算模块,提高计算效率, 对接nodejs,py就可以。
    pabupa
        31
    pabupa  
       2020-08-28 07:30:04 +08:00 via Android
    @statement 哈哈哈哈哈哈哈哈哈哈哈哈
    594duck
        32
    594duck  
       2020-08-28 08:36:27 +08:00
    @cassyfar 吹 B 小业务的互联网公司人家就搞过的,还喊出了后端已死前端当立(就和十年前喊出测试已死,17 年开始喊运维死了一样)

    听他们吹牛逼永远很精彩 。
    H15018327040
        33
    H15018327040  
       2020-08-28 09:02:44 +08:00   ❤️ 2
    TM 的我这的后端只管查出数据,连简单的数据组合都不处理,搞得我一个页面无数个嵌套请求,通过返回的数据再次请求一次,页面加载数据就得好久。
    jzmws
        34
    jzmws  
       2020-08-28 09:14:33 +08:00
    我的原则是前端只做展示 , 科学计算 (非涉及到钱的) 允许前端计算 其他都用后端计算
    Mutoo
        35
    Mutoo  
       2020-08-28 09:17:52 +08:00
    大后端 -> 大前端 -> 大中台
    demotu
        36
    demotu  
       2020-08-28 09:21:40 +08:00
    在有前后端开发的情况下 前端还是尽可能的简单吧 因为后端是服务端 一般都是可控的的 对于暴露出去的东西要尽可能简单 避免漏洞
    vone
        37
    vone  
       2020-08-28 09:33:36 +08:00
    前端仔是说什么都贼有道理,开发什么都贼 TM 垃圾。
    tikazyq
        38
    tikazyq  
       2020-08-28 09:37:54 +08:00
    对全干工程师来说,怎么做都无所谓,给钱啥都可以
    NasirQ
        39
    NasirQ  
       2020-08-28 10:01:03 +08:00
    业务逻辑还是放后台靠谱,就现在这前端混淆加密,分分钟就抄走了..... 交互逻辑,页面展示,前端特效这些放前台来写。
    DT27
        40
    DT27  
       2020-08-28 10:06:18 +08:00
    前端还是老老实实处理交互展示吧,别再干后端的活了。。。
    hoyixi
        41
    hoyixi  
       2020-08-28 10:16:02 +08:00
    曾经流行业务都放前端吗?什么场景会把业务都放前端做呢
    我没怎么见过,前端基本都是处理交互,除了展示, 另外一个重要点就是对用户输入的过滤和验证。
    1cming
        42
    1cming  
       2020-08-28 10:23:25 +08:00
    没想到 3L 还能有这么多点赞
    yaphets666
        43
    yaphets666  
       2020-08-28 10:25:01 +08:00   ❤️ 2
    要不说你不懂呢,我现在这个项目就是后端基本就负责 CRUD,数据处理前端来做,一个页面 20 多个请求发出去,请求回来的数据做参数再发 N 个请求.这种应用用户体验是极差的.会有很多 loading 动画.什么降低后端负载都是扯淡.8 核 16 线程的服务器,性能有你们说的那么不堪吗?组合点数据,处理处理数据就累着了?
    OHyn
        44
    OHyn  
       2020-08-28 10:29:28 +08:00
    交互相关的逻辑也只能放前端。。。后端做好数据聚合就行,否则一个页面 N 个请求,PC 端还好,移动端,光 ajax 就好久。。
    jaylee4869
        45
    jaylee4869  
       2020-08-28 10:48:20 +08:00
    我司前端就这样,连 node 也不会,只会 jquery 一把梭。都 2020 年了,难以置信。工资居然还比后端高。
    zppass
        46
    zppass  
       2020-08-28 10:49:28 +08:00
    从某种意义上说的不算错,前端尤其是 APP 你给整一堆业务逻辑,到时候有问题要修改急着上线怎么整,小程序也审核,IOS 也审核,应用商店也审核,客户不升级你咋整。后台逻辑修改就好多了,不变应万变。
    大前端实际上他能把那些第三方的服务弄好就够了,后端纯做一个数据库的搬用工,甚至连数据处理都不处理一下,也实在没啥意思。
    gollwang
        47
    gollwang  
       2020-08-28 10:57:28 +08:00
    你们遇到过纯展示得前端么。。。真纯展示,数据不做任何处理,不做任何判断。。。
    fffang
        48
    fffang  
       2020-08-28 11:00:08 +08:00
    把整个架构体系抽象成 MVVM 的话,VM 这一次,也就是数据处理,最好在服务端处理。
    konakona
        49
    konakona  
       2020-08-28 11:05:15 +08:00
    你的这个看待整体选型的“方式”,其实十几年前就是这样做的,反而是 06 年左右 Reactjs 出现、Nodejs 的影响力、SPA 的市场需求逐步扩大后,才让前端圈迅速发展至今,尤其是出现 Taro 、uniapp 等全平台的框架,还有 GG 的 Flu,全面发展大前端的市场。

    因此,你的这个看待整体选型的“方式”,其实已经是过时的!

    首先要做技术选型,在确定有哪些技术问题要攻克,有哪些业务状态和业务前景,做好技术架构后,再看待这个问题。
    my1103
        50
    my1103  
       2020-08-28 11:10:13 +08:00
    @jaylee4869 还在用 jq 嘛,2020
    6IbA2bj5ip3tK49j
        51
    6IbA2bj5ip3tK49j  
       2020-08-28 11:17:16 +08:00
    前几年流行,是因为前端开始做工程化,觉得可以承担一部分业务了,顺便可以加薪。
    这几年又把业务扔给后端,是因为发现业务一堆破事,工资已经涨上去了,破事当然后端做啊。
    winglight2016
        52
    winglight2016  
       2020-08-28 11:22:19 +08:00
    @cassyfar 20 年以前,C/S 流行的年代,还是流行过类似的“大前端”,虽然这个词我也是头一次听说。。。
    ETO
        53
    ETO  
       2020-08-28 11:28:02 +08:00   ❤️ 2
    说到这个我就很生气,我是搞 PHP 的,我提供后端接口给 java 后端,我说我数据都是总好几张表里汇总出来的不好做分页,一共也就几百条数据,你自己做个分页吧。java 说 做不了内存会爆掉,我说那行吧。那就让前端直接渲染吧,java 我也不懂,前端说单线程应用 不方便操作数据,做不了。java 我不懂,可 vue 连 几百条数据也渲染不了吗?
    Mazexal2
        54
    Mazexal2  
       2020-08-28 11:31:15 +08:00
    @ETO 如果用户量少的话, 几百条数据当然没关系, 几万条数据直接返回也是有的, 不过用户量多了以后, 后端确实内存会爆掉的, 不过你们前端就是懒逼, 分页也就几行代码的事情, 也不想做
    di94sh
        55
    di94sh  
       2020-08-28 11:36:26 +08:00 via iPhone
    @w88975 你是不是只吧撸码行数看进去了,业务流程梳理抽象,api 定义,性能优化,这些都不是工作量吗
    leega0
        56
    leega0  
       2020-08-28 11:40:38 +08:00
    我也是跟公司的后端这么说的,原因很简单,页面越静态越好,前端的本质是展示,不然直接丢个代码生成器给客户用不就行了。
    zjuster
        57
    zjuster  
       2020-08-28 11:41:40 +08:00
    @victor 边缘计算!哈哈哈
    Chenamy2017
        58
    Chenamy2017  
       2020-08-28 11:51:07 +08:00
    @statement 每个公司都应该招像你一样的人才。从此社会和谐,江湖再无前后端之争
    Kusoku
        59
    Kusoku  
       2020-08-28 11:58:29 +08:00
    懒惰是程序员的美德哈哈
    iyu90
        60
    iyu90  
       2020-08-28 12:07:35 +08:00
    什么业务?你们要用前端挖矿吗?现在都 2020 年了,不知道上面有些个后端仔,那来的优越感
    bojue
        61
    bojue  
       2020-08-28 12:20:09 +08:00
    @victor 你是个人才
    ihuguowei
        62
    ihuguowei  
       2020-08-28 12:25:07 +08:00 via iPhone
    好多人对自己不了解的领域想当然,前后端都有……
    chaleaoch
        63
    chaleaoch  
    OP
       2020-08-28 12:31:26 +08:00
    @KuroNekoFan 楼主不太理解...
    请教个具体问题.
    ```
    一个 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
    类似这种

    是这个意思不?
    KuroNekoFan
        64
    KuroNekoFan  
       2020-08-28 12:47:31 +08:00 via iPhone   ❤️ 1
    @chaleaoch 我觉得你这挺典型的,既然 a 和 b 决定了 resource,那就应该 resource?a=sa&b=sb
    把状态组合影射为一种 typecode,是典型搞笑行为
    oma1989
        65
    oma1989  
       2020-08-28 12:59:11 +08:00
    然而好多快餐工,连最基本的 JS/CSS 都不懂,只会使用 VUE 或某个框架都号称是前端。。。。。。。
    (我们前端之调用 API 展示数据,null 后台处理掉, 日期格式后台处理好了, 展示小数位数后台处理好了)

    还是自己全干来的靠谱。。。。
    godgc
        66
    godgc  
       2020-08-28 14:20:29 +08:00
    我倾向于,复杂的计算逻辑放由后端处理,前端主攻用户体验层和简单的数据处理
    jake361
        67
    jake361  
       2020-08-28 14:24:55 +08:00
    举的那个例子,我是嫩是没看懂,可能是我太菜了。
    daxin01
        68
    daxin01  
       2020-08-28 14:28:59 +08:00
    @jaylee4869 货物崇拜编程
    jake361
        69
    jake361  
       2020-08-28 14:29:09 +08:00   ❤️ 1
    @KuroNekoFan 反正我觉得让前端请求两次... 我觉得这句话就暴露了水平
    gdtdpt
        70
    gdtdpt  
       2020-08-28 14:29:31 +08:00   ❤️ 1
    @chaleaoch 以我的开发习惯理解后端提供的接口是为业务服务的,不是为数据服务的,像你这里说的情况,之前这个业务是调用一个接口,但是现在业务逻辑变了,有两个解决方案
    1. 前端改为调两次不同接口,然后拼装业务需要的数据。
    2. 后端修改此接口的业务逻辑,增加参数判断逻辑。

    如果前端只是改所调用接口的 url,不增加调用次数的情况,我赞成前端改,因为有别的接口满足业务需要。
    但是需要前端改成调用多次接口并封装部分业务逻辑,我认为应该后端改,以我的开发习惯我会避免在前端写这种包含部分业务逻辑的代码。

    理由是今天这个业务从调用一次改成调用两次,可能过段时间业务需求又变了,就会变成调用三次,或者有其他的前端接口调用由一次也变成调用多次,这样出现什么问题到底是前端的问题还是后端的问题说不清楚,也不好排查,出现问题需要前端后端一起看数据和逻辑,浪费人力和时间。前后端职责模糊,也容易前后端互相推诿。

    说得难听点,如果后端只想做数据库中间件,不处理业务,那前端整一套 SSR 框架直连数据库就行了,要后端干什么。
    frankkai
        71
    frankkai  
       2020-08-28 14:29:52 +08:00
    如果服务端接口服务于多种客户端:PC 、移动端、Native

    最好还是服务端统一做处理更好。一端处理,多端舒适。
    hxy91819
        72
    hxy91819  
       2020-08-28 14:29:53 +08:00
    主业做后端,也写过一点前端,我倾向于后端把数据整理好了,前端直接拿来显示就行了。后端做数据处理更容易。前端还需要处理样式和业务交互逻辑。但是一些简单的处理,前端可以自己做,比如时间,后端给时间戳就行了,具体什么格式显示,前端自己处理。

    另外,对于图片的处理(比如生成、编辑图片)这种只能客户端做,服务端做成本会很高(带宽、CPU 等)。
    leonardyang
        73
    leonardyang  
       2020-08-28 14:30:22 +08:00
    我只想知道,业务逻辑扔在前端,咋保证不被篡改啊,现在哪怕不是干这行的都会点打开 chrome 调试,按软件安全原则来说用户所有输入都不能信任,信任用户侧的业务代码运行结果就更过分了吧?
    hxy91819
        74
    hxy91819  
       2020-08-28 14:31:48 +08:00
    另外我建议所有后端都要学点前端,所有前端都要学点后端。免得被对方忽悠,有时候真的就只是同事想偷下懒而已。
    wangyzj
        75
    wangyzj  
       2020-08-28 14:32:06 +08:00
    前后端怎么分得看具体需求
    还有后端的数据复杂程度和分散程度
    不能说都给前端
    melvin
        76
    melvin  
       2020-08-28 14:55:39 +08:00
    复杂计算 还是放在后端好,前轻后重
    jaylee4869
        77
    jaylee4869  
       2020-08-28 15:10:24 +08:00
    @daxin01 nb, 绝了,学习了。
    guanhui07
        78
    guanhui07  
       2020-08-28 15:31:44 +08:00
    觉得看情况把
    xzg1993
        79
    xzg1993  
       2020-08-28 15:43:40 +08:00
    @H15018327040 +10086 我这一个页面,六个接口请求
    H15018327040
        80
    H15018327040  
       2020-08-28 16:12:34 +08:00
    @xzg1993 最恶心的情况是有一个列表,每一项都有一个子对象,子对象上只有一个 ID,获取列表后还得循环去通过子对象的 ID 去获取子对象的数据然后组合成一条完成的数据,真 TM 日了。
    xzg1993
        81
    xzg1993  
       2020-08-28 16:22:43 +08:00
    @H15018327040 在说一个,一个请求 要给后台传一大串 json,后台在返回一大串 json,我自己去拼接自己想要的请求,有时候想要显示一个页面数据,还要请求这种垃圾接口 2 到 3 个。
    KuroNekoFan
        82
    KuroNekoFan  
       2020-08-28 16:29:27 +08:00
    @jake361 请求多少次不是关键,关键是,type${x}作为一个由 a,b 衍生出来的值,可能性随着需求会越来越多,那么这里首先不应该把这部分逻辑放在前端,
    我还见过更 sb 的,不仅要带上衍生值,还要带上原始值,即 resource?type=typex&a=sa&b=sb
    H15018327040
        83
    H15018327040  
       2020-08-28 16:40:52 +08:00
    @xzg1993 有时候我就想,什么都不做处理的数据还不如做一个接口,前端直接传 SQL
    w88975
        84
    w88975  
       2020-08-28 16:45:37 +08:00   ❤️ 1
    @di94sh
    就目前 crud 那一套,现有框架成熟的不能再成熟了,除非你自己撸一套,否则根本就是一把梭
    业务抽象我就不说了,这个跟前后端没有太大的关系,这个是整个项目的架构决定的
    api 定义这个也能拿来说吗?这个也不是工作量导向的东西,主要靠约定俗成,也是纯架构方面的
    性能优化,这个就是仁者见仁,智者见智的东西了
    你所说的这些东西,都是作为一个后端必备的,不能说没有工作量,但就目前 90%互联网公司所涉及的业务来说,拿出来说真的不值一提

    我并没有站在一个纯前端的角度来讨论这个问题,我也是做了多年的后端,我很讨厌写前端,就是因为前端相对于后端来说,太杂了,没有像后端那么多年积累起来的标准库(近几年稍微好那么一点),同样的业务,前端的选择更多,工作量也更多.
    处理纯数据,和写用户交互的东西相比,还是纯数据处理起来更简单明了

    以前后端鄙视前端,那是因为前端真没啥技术含量,"切图仔"们只知道填数据,画页面,对数据来源以及数据的处理根本不用关心. 我不能说现在前端多有技术含量(也可能没有),但就事论事的话,工作量是特别大的.

    打个比方,写个修改用户资料的业务,后端只需要处理字段,校验字段,校验不通过返回什么,通过又是什么,然后更新 DB.
    前端首先要完成这个页面,然后再处理数据,例如头像要用什么组件东西展示,是否可修改,修改的话,得用哪个接口去上传图片,上传状态,各种提示,表单的校验等等,不说复杂不复杂,至少比起纯数据处理来说,是复杂的.

    就好比 V2EX 的回帖时间,后端只返回时间戳,前端要去判断: 大于 24 小时,展示完整年月日时分秒,小于 24 小时,展示 xx 小时前,这时候,后端要是直接返回这个时间,前端就能省很大一部分事,毕竟大多时候,前端也只是拿时间戳来做 format 成字符串,而不是做条件查询
    leejaen
        85
    leejaen  
       2020-08-28 17:04:40 +08:00
    @w88975 同意,我公司做的某个大项目,前端 react,后端 java,人数分别是 6 和 40,我们前端累的要死,后端一个按钮的小功能拆 6 个人做,并且他们做完了就干等着我们,还经常告状:后端都做完了,就等前端了。技术总监那里要人不给、要时间不给,让我想办法,一帮后端天天摸鱼干吃饭。还可劲说自己这样忙那样忙,这种后端真是让人鄙视
    cco
        86
    cco  
       2020-08-28 17:09:01 +08:00
    最近多了点前端和后端搞事情的帖子。
    我觉得还是得将注意力转移到语言上。PHP 是世界上最好的语言!
    cco
        87
    cco  
       2020-08-28 17:10:03 +08:00
    @leejaen 我司曾经一群后端 996 呢。前端周末在陪妹子看电影,怎么说?
    zzzmh
        88
    zzzmh  
       2020-08-28 17:13:39 +08:00
    需要结合具体情况,例如一个表 1000 条数据,排序分页筛选,放后端做划算,如果全部给前端也能实现,但网速的开销过大,实际用到的太少,血亏。如果数据是一样多固定大小,那放在前端算,节约服务器算力,是可取的。
    littleFive
        89
    littleFive  
       2020-08-28 17:14:05 +08:00
    @cco 听你这么一说,我就感觉你们项目不会是前后端分离的
    miniwade514
        90
    miniwade514  
       2020-08-28 17:16:23 +08:00
    大前端说的是 web 和 native 融合的事情,不是“代码体积很大的前端”。业务逻辑放哪儿,跟是不是大前端没什么关系。
    daxiongz
        91
    daxiongz  
       2020-08-28 17:16:38 +08:00
    @jaylee4869 咱公司叫啥?我也想去
    hoosin
        92
    hoosin  
       2020-08-28 17:20:19 +08:00
    我觉得这个边界是,展示层面的。
    前端、中间层都可以做,反之还是后端来计算吧。
    kaiki
        93
    kaiki  
       2020-08-28 17:22:49 +08:00
    能让后端做就让后端做,后端不会相信前端的任何逻辑的
    airplayxcom
        94
    airplayxcom  
       2020-08-28 17:25:46 +08:00
    宣战贴 ,不做任何评论
    canxden
        95
    canxden  
       2020-08-28 17:50:45 +08:00
    前端后端 角度 X
    用户 角度 √

    并不是所有用户都会喜欢升级的. 如果很多业务要依靠前端升级版本来解决.
    为什么不尽可能多的功能可扩展, 而不必用户升级来解决呢.

    exp: 日期. 后台传时间戳 & 后台传日期字符串.
    万一哪天要展示逻辑改变, 是不是还要更新前端版本来解决这个问题?

    btw: 改不改都看产品心情. 前端后端要佛系. 手动狗头
    syyy
        96
    syyy  
       2020-08-28 17:55:34 +08:00
    去年让前端写个冒泡,把十个元素以内的数组排个序输出一下,然后隔天告诉我不写。我生生把返回的结果集翻到最深一层,取出属性值排序一遍丢出去。
    Sapp
        97
    Sapp  
       2020-08-28 18:02:51 +08:00   ❤️ 2
    不把逻辑放在前端不是因为计算量,这个跟计算量也没有任何关系,有几个项目能大量吃资源的?
    不放前端是因为第一没有必要,很多东西设计安全之类的前端你就算走一遍流程,后端也还是要走,等于两个人都要搞,那你何必放前端?
    第二是因为前端毕竟是个页面,有 UI 要展示,你全都扔给前端,他还要协调数据和 UI,复杂度会成倍往上走,而你在后端做好,只需要关注数据,拼好发给前端就完事了,典型的就是有些后端会把一个接口拆成 n 个让前端互相调,这简直是坑爹操作,对于后端明明拼接一下数据很简单的事情,给前端做简直就是个折磨。
    最后就是现在很多后端的客户不只是前端,往往还有客户端甚至其他公司的客户之类乱七八糟,这种情况你把东西放在前端做其实也是个浪费,你的前端做一次移动端做一次客户还要做一次,如果涉及到校验的问题那更容易出问题,你的前端校验好了移动端没校验好,整个系统全都崩了。
    Ritr
        98
    Ritr  
       2020-08-28 18:15:00 +08:00
    这种肯定是后端改啊,请求是异步的,通过两次请求来判断一个事情首先不合理,其次两次异步不方便处理,最后是增加了复杂度
    cco
        99
    cco  
       2020-08-28 18:15:52 +08:00
    @littleFive 从 17 年开始就一直是前后端分离了~~~
    Solace202
        100
    Solace202  
       2020-08-28 18:17:32 +08:00
    @victor 怪不得现在手机内存赶上电脑内存了。。。
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1770 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 16:34 · PVG 00:34 · LAX 08:34 · JFK 11:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.