V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
zhoupeng199
V2EX  ›  问与答

本人前端,对接 Java ,实在忍不住要吐槽了

  •  
  •   zhoupeng199 · 309 天前 · 4283 次点击
    这是一个创建于 309 天前的主题,其中的信息可能已经有所发展或是发生改变。

    公司之前是用 python django 开发,目前新组建的 java 团队,一起开发一个后台管理系统,java 是 spring 那一套微服务,有以下感受不得不吐槽。

    1. 后端把很多关联关系丢给前端处理,在 python 的后端开发下,明明一个关联查询就能搞定的事情,他们搞不了,导致前端得根据 id 调另一个接口拿数据,问他们能不能查询到,他们说:“我们这是微服务架构”。意思是前端能调就前端调,在业务不得已的情况下是不会写 rpc 接口的。这让我不得不怀疑是不是他们的微服务划分是否有问题,导致给前端加了不少工作量。

    举个例子,界面上一个** [树形选择器] ** 里的数据,需要一个状态判断是否展示,但是这个状态在另一个微服务里。后端表示让我调两个接口,然后根据数据再过滤一下,可特么这是一个树形数据啊,不是说做不了,但这让数据库 sql 过滤不是更简单,据理力争之下后端才妥协。

    1. 后端甚至一些业务逻辑都不写了,举个例子,一个审批流程,按业务流程来说,应该是轮到自己审批了才展示。目前是只要和自己关联统统展示,并且要前端来通过代码判断是否轮到了自己处理了,才展示对应表单,这合理?

    所以以上问题到底是人的问题还是 java spring 微服务的问题。

    第 1 条附言  ·  308 天前
    感谢各位回复,看来还是我态度不够强硬,需要和后端 battle battle.
    55 条回复    2023-05-26 17:37:06 +08:00
    zlzdbf
        1
    zlzdbf  
       309 天前
    Frank201888
        2
    Frank201888  
       309 天前   ❤️ 2
    微服务和 spring 表示不背锅
    linauror
        3
    linauror  
       309 天前
    从以上举例来看就是人的问题
    Simle100
        4
    Simle100  
       309 天前
    单纯的后台管理系统用微服务?
    daley
        5
    daley  
       309 天前
    搞管理后台还用微服务,可以好好摸一阵了
    bjzhush
        6
    bjzhush  
       309 天前
    你居然分不清这是语言的问题还是人的问题,也难怪搞不过后端了
    别说 Java 了,20 年前的 asp 都能按你的要求出接口
    你说这是谁的问题呢?
    isno
        7
    isno  
       309 天前   ❤️ 6
    人的问题,微服务用错了。微服务不是把微单元暴露给前端。

    微服务架构应该是:业务合理的拆分和解耦,并且细小单元在服务治理管理下,某个单元崩溃也不至于整体服务都不可用,而且在微服务的基础之上,后端还要增加一个层,尽可能完善业务的处理逻辑,整合微单元的资源提供给调用方。
    XSDo
        8
    XSDo  
       309 天前
    后端微服务不 rpc ,用前端来走网络调用多一次接口? 后端 rpc 可以走内网,前端调接口是走公网的啊 想想都知道那个调用更高效。
    final7genesis
        9
    final7genesis  
       309 天前
    如果真有那么多分散的微服务,架构设计是不是要来一个网关层?
    renfei
        10
    renfei  
       309 天前   ❤️ 1
    既不是 前端的问题,也不是后端的问题,更不是 java spring 技术的问题。

    我们曾经有一段时间也这样推广过,理由如下:

    1.后端的需求基本不会怎么变,也就是说数据库表不会改来改去
    2.需求变更常常发生在用户侧,今天想看 A 明天想看 B
    3.前端最贴近用户侧

    结果就是

    1.后端就是 CRUD ,跟数据库是的,傻不拉几的,成了数据查询器
    2.前端忙死,大量招聘前端程序员
    3.尝试推广 graphql

    后端只要保证服务健壮不挂,其他都由前端去折腾这种合作模式。

    但是吧,确实有些场景不方面,数据全吐给前端,有些数据会泄露,慢慢又改回来一部分,目前前后端算是平衡了吧。
    yor1g
        11
    yor1g  
       309 天前   ❤️ 1
    就是跟风 瞎几把拆服务 系统上线后就特么就那几十人在线用
    daye
        12
    daye  
       309 天前
    人的问题,结贴
    brader
        13
    brader  
       309 天前
    你慌什么,像你那个树形结构,要根据 ID 调别的接口的,如果要你循环调 N 次的话,你调呗,他服务支撑不住让他们头疼去
    huang40614676
        14
    huang40614676  
       309 天前
    @renfei #10 经典场景,太典了
    ChefIsAwesome
        15
    ChefIsAwesome  
       309 天前
    往好的方面想,后端觉得自己搞好了,高枕无忧,前端天天忙。裁员就裁后端。
    JKeita
        16
    JKeita  
       309 天前
    这明显是人的问题
    yoyolichen
        17
    yoyolichen  
       308 天前
    用了微服务却不会写 rpc 接口,他是来搞笑的么
    chenPiMeiHaoChi
        18
    chenPiMeiHaoChi  
       308 天前
    微服务不写 rpc 还微个锤子,建议直接 java -jar 。
    LLaMA2
        19
    LLaMA2  
       308 天前
    如果你 TS 写的比较溜,那就偷偷的给他写一层网关吧。预留一点自己的奇技淫巧,保证在你被优化后项目成功跑不起来。黑嘿嘿。。。
    potatowish
        20
    potatowish  
       308 天前 via iPhone   ❤️ 1
    @final7genesis 不是网关层,应该需要一个独立的聚合服务层
    Helsing
        21
    Helsing  
       308 天前 via iPhone
    现在主流做法都是尽量数据云端化了,前端基本只负责展示

    你们的后端开发很有问题
    ByZHkc3
        22
    ByZHkc3  
       308 天前
    后端懒,在我们这是会被骂死的
    superchijinpeng
        23
    superchijinpeng  
       308 天前
    人的问题
    miv
        24
    miv  
       308 天前 via Android
    这就是后端懒,想把事情交给前端做。
    做一个业务,它的逻辑不在前端就在后端。
    要么你前端搞了后端舒服,要么后端搞了你前端舒服。
    作为一个前端,那肯定是让后端出靠谱的才行。
    最好一开始要把接口规划好,需要什么给后端说,不能让他直接给你接接口自己去处理,因为太坑太大了。
    如果后端能处理,最好是后端。因为前前端有很多地方会用到后端,一个接口需要对应,很多种情况,最好是后端处理聚合起来。
    这个就是后端的问题。
    miv
        25
    miv  
       308 天前 via Android
    我前后端都搞,所以比较能中立的看待你这个问题。
    后端如果这些不帮你搞,有可能是后端懒。
    另外一个原因就是后端的抽象能力不够。
    他只站在自己的业务上想问题没往接口层上做一个抽象。
    建议你不要自己搞,因为如果其他业务很复杂的话,前端是需要处理很多工作的,你这样搞的话到时候接口很多很乱的。
    最好是后端商量一下,然后统一处理聚合。
    这样虽然后端工作量多一点,但是可以大大提高软件的健壮性。
    测出来的 bug 也会少。
    tingyunsay
        26
    tingyunsay  
       308 天前
    我跟你反过来了,我们这逻辑全给后端了,前端只有纯展示
    Quarter
        27
    Quarter  
       308 天前 via Android
    如果是这样的话我觉得可以直接上 saas 了,前端自己生成接口,后端不需要的就裁掉吧
    silentsky
        28
    silentsky  
       308 天前 via Android
    如果需要适配多个端,那肯定是后端处理好比较好,不然多端做重复的工作。我写后端接口的原则一般尽量让前端傻瓜似的调用
    darkengine
        29
    darkengine  
       308 天前
    把情况反馈给 leader ,如果 leader 觉得这是合理的,边做边准备简历吧。
    carytseng
        30
    carytseng  
       308 天前
    六年经验感觉你司后端不行
    ql562482472
        31
    ql562482472  
       308 天前   ❤️ 1
    看上面都说后端的,其实前端做也没什么问题,还是看频繁变动的在前端还是后端。还有数据的性质,界面展示的状况等等。这种小问题其实谁做都可以 只要理由充分。
    zcf0508
        32
    zcf0508  
       308 天前 via Android
    你说的是我司吧哈哈哈哈
    sunqb
        33
    sunqb  
       308 天前 via Android
    @daley 看来你也没搞过复杂的管理端
    huzhizhao
        34
    huzhizhao  
       308 天前 via iPhone
    纯粹就是人的问题,技术不背锅
    chihiro2014
        35
    chihiro2014  
       308 天前
    纯粹是后端人懒。。。
    auh
        36
    auh  
       308 天前
    权力的问题。
    iseki
        37
    iseki  
       308 天前 via Android
    微服务拆的有问题,拆的太碎了,然后缺了个 BFF 聚合层,压力就全跑到前端去了
    louisxxx
        38
    louisxxx  
       308 天前
    和 java 有啥关系,这明明是人员技术水平差
    0xsui
        39
    0xsui  
       308 天前 via Android
    咱就说,你司这种情况的后端,薪资是多少(ÒωÓױ)!
    yosoroAida
        40
    yosoroAida  
       308 天前
    人的问题,用微服务居然不用 rpc (都 2023 年了,居然还说 rpc 接口迫不得已不写,盲猜没有实践经验)
    zfy941
        41
    zfy941  
       308 天前
    这后端倒是真省事 就是把数据表读取给你呗 啥关系都让你自己来
    bhbhxy
        42
    bhbhxy  
       308 天前
    前端在很多公司是没什么地位的,就我在的公司,一个年过五旬的领导还把前端称之为美工,认知还停留在 20 年前,有些后端更是这样,觉得前端没技术含量,把工作都推给前端,接口写好测都不测,等你反馈问题后看心情自己改还是让你改。
    lei2j
        43
    lei2j  
       308 天前 via Android
    不是微服务的问题,是人的问题
    lingeo
        44
    lingeo  
       308 天前
    下次直接把办公室当八角笼跟他 battle 就是,你不会还没跟后端吵过吧。我虽然是个后端开发,但是根据你的描述,我还是站你这边。先跟他线上沟通,不服就跟负责人反馈,负责人和稀泥就直接线下开骂。
    Erroad
        45
    Erroad  
       308 天前
    你不用试图理解他的逻辑,站在你的角度很简单的,这种需求本来就应该一个接口,至于你后端为什么做不成一个接口,那不是我的问题。如果容易造成更多风险,就该上升到负责人去协调。
    passon
        46
    passon  
       308 天前
    前端自己做个 bff 层,或者后端加个 bff 层
    nothingistrue
        47
    nothingistrue  
       308 天前
    本帖前面的楼层,大多数都是美工在回复,没有做过全局的程序员,或者高级的 UI 开发。

    先指出楼主,以及楼上广大美工一个非常明显的问题:不管是主动还是被动,当你的定位是一个纯前端的时候,那么不要插手后端工作量的评估——这是后端的内部工作,不要插手让前端做还是让后端做的决策——这是架构师或者开发主管的工作。如果你插手了,那只能得到一种结果:你行你上。

    然后再来说下具体问题。很不幸的是,说不了,因为这问题分析只能是楼主团队的架构师 /开发主管来做。这里只能提供一些经验之谈。

    经验一:接口是双方的,不是单方面的。放在楼主环境中,后端可以随意定义接口,但前端没说能用,接口开发任务就不算完成。但请注意,前端只能反馈不能用,不能反馈后端没做好。

    经验二:微服务是全局的,前端也是微服务里面的一个环节,所以前端也要参与对数据分散问题的解决,该在 UI 层整合的数据,就得前端做。

    经验三:单体应用拆分成微服务之后,前端也可以有自己专用的「前端的后端服务」,像楼主所举例的 「树形选择器」,如果是组织机构数这种全局通用的数据,那么可以交给「前端的后端服务」来集中做。

    经验四:微服务拆分,或者说数据拆分,不是简单的把蛋糕切成几块的过程。拆分打散之后,是要再造出一些新的数据,来整合离散的数据的。经验三所说的「前端的后端服务」,就是一种多出来的服务 /数据。楼主的怀疑是对的,微服务拆分,确实有问题。

    经验五:即使不是微服务,前后端拆分之后,前后端就不再是一个程序,而是有关联的两个程序,应当有各自独立的数据模型,不能再用一个。简单来说,前端 MVC 、MVVM 等框架中的 Model ,是前端自己的数据层,跟后端 Model 没关系,跟后端用得数据库更没关系。这时候,前端是万万不能说出「这让数据库 sql 过滤不是更简单」这种话的,他应当说的是「没过滤的数据用不了」



    最后那个关于审批流程的问题,这个跟微服务、前后端都没关系,这特么就是个 BUG 。后端就没把接口做好,压根无需考虑是否合理,直接当成 BUG 提出去。
    TaoLoading
        48
    TaoLoading  
       308 天前
    差不多的遭遇,之前项目的子模块,所有的查询后端就一个接口是让我自己拼 sql 传过去,让我前端拼 TM 的 sql 传过去??!!!当时刚工作不久还不会跟后端刚,那段时间真痛苦啊
    noreplay
        49
    noreplay  
       308 天前 via Android
    前端的前端,前端的后端,后端的前端,后端的后端。不知道啥样的公司,啥样的业务要搞这么复杂。感觉每一个公司都是人均阿里,都去搞一个中台,数据湖。说出去可牛逼了。
    J3W4
        50
    J3W4  
       308 天前
    虽然但是,后端不就是应该处理数据的嘛,
    说白了后端就是不想干
    adoal
        51
    adoal  
       308 天前
    是从一线互联网大肠毕业出来的不懂关系数据库不懂传统 CRUD 只会在没毕业的夹狗屎指定的萎服务业务框架里填空的后端吧
    Jame00001
        52
    Jame00001  
       308 天前
    @bhbhxy 是这样的,很多后端看了眼 html 、css 就觉得前端不过如此,关键是你没法解释,天天看他们装逼
    justin2018
        53
    justin2018  
       308 天前
    遇到过这样的情况

    后端想省事儿

    1. 用 express egg.js 包一层

    2. 接口挨个插 反正服务挂了跟你没啥关系

    3. 跟组长反馈这个问题

    现在前端都是万金油了 特么啥都给前端干~~
    uyoungco
        54
    uyoungco  
       308 天前
    后端懒,有问题再返工就是
    wellerman
        55
    wellerman  
       307 天前
    > "举个例子,界面上一个** [树形选择器] ** 里的数据,需要一个状态判断是否展示,但是这个状态在另一个微服务里。后端表示让我调两个接口,然后根据数据再过滤一下,可特么这是一个树形数据啊,不是说做不了,但这让数据库 sql 过滤不是更简单,据理力争之下后端才妥协。 "

    树形数据的接口,是不是只有这一个界面调用?如果是,那按前端的显示状态返回就是合理。如果不是,那就会有多种状态的可能。下次有其它状态,就得重新出一个接口,这样接口就冗余了。当然也可以整合在在之前那个接口里,这样就耦合了。

    spring boot 里 RPC 调用很简单,也就几句话。但并不会出现“这让数据库 sql 过滤不是更简单”。微服务下,这其中的工作量并不会因为转移到哪个端实现,工作量就会变少。


    > "意思是前端能调就前端调,在业务不得已的情况下是不会写 rpc 接口的"

    微服务不但要避免 RPC 调用,还要避免 join 。

    正确的做法是,树形数据的接口不变,只负责完整数据输出。其它服务根据自身的需求出状态接口,如包含所有要显示的 id 数组。前端只是在遍历树形数据时,顺便判断一下 id 是否在显示状态接口的 id 数组中,这能有多大的工作量。这样出现其它不同的状态需求,只要换一个状态接口就可以了。目前,无非是后端妥协了,在后面用 RPC 调同样的接口,把数据处理好返回。下次呢?再妥协,一个接口里加一堆 RPC 调用。最后,这个接口的并发肯定上不去,变成系统的一个短板。

    同时,有(输出)状态接口,必然有设置状态的接口,这个也和状态接口在同一个微服务里吧。既然和“树形数据”分开了,说明树形数据只是其它业务的子项,是一个公共服务。在公共服务里强行耦合其它业务,也非常不合理。

    举个实际的例子,如地区数据服务,需要在很多业务里调用。有些要省市的,有些要到地区街道的,有的要在一个范围里的。如果在接口里做显示状态的判断,那么每次调用都得做一遍无意义的计算,还要传一坨数据。如果显示状态独立出来一个接口,用白名单或黑名单,在前端判断。地区数据只要获取一次,缓存好。这样不管是前端还是后端,性能会更好,还会节省服务器 CPU 和带宽资源。

    > "后端甚至一些业务逻辑都不写了,举个例子,一个审批流程,按业务流程来说,应该是轮到自己审批了才展示。目前是只要和自己关联统统展示,并且要前端来通过代码判断是否轮到了自己处理了,才展示对应表单,这合理?"

    都“按业务流程来说”了,就变成流转中的业务要不要展示?审批过后要不要展示?工作流不会一直向前流,还有回流,如驳回后要不要展示?驳回后,按业务流程来说,就是还没轮到自己审批,是不是不应该展示?什么叫合理?我早上上班,看一下最近和我有关的审批事项,提前熟悉一下相关事项,准备好相关资料。等到我审批时,就直接提交,这样做合不合理?比如,在电子税务局里,常会出现一些项目没到申报期,点进去也不能申报。但会提示,还有-xx 天,这样合不合理?


    最后,10 几年前,是没有前端这个职业,基本只有美工和程序员这两种。还有很多美工都是由程序员兼职的,比如 V2 就是那个时代的典型。当然了,现在后端兼职前端的也不少,像 V2 这样就不需要独立前端。前端的出现,就是因为可以把原本在服务端的计算放到客户端,节省资源提高可用性。做为一个合格的前端,应该是去压榨客户端资源,而不是服务端资源。不然前端就失去存在的意义。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5241 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 09:16 · PVG 17:16 · LAX 02:16 · JFK 05:16
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.