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

[zhoupeng199]

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

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

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

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

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

感谢各位回复，看来还是我态度不够强硬，需要和后端 battle battle.

[zlzdbf]

人

[Frank201888]

微服务和 spring 表示不背锅

[linauror]

从以上举例来看就是人的问题

[Simle100]

单纯的后台管理系统用微服务？

[daley]

搞管理后台还用微服务，可以好好摸一阵了

[bjzhush]

你居然分不清这是语言的问题还是人的问题，也难怪搞不过后端了
别说 Java 了，20 年前的 asp 都能按你的要求出接口
你说这是谁的问题呢？

[isno]

人的问题，微服务用错了。微服务不是把微单元暴露给前端。

微服务架构应该是：业务合理的拆分和解耦，并且细小单元在服务治理管理下，某个单元崩溃也不至于整体服务都不可用，而且在微服务的基础之上，后端还要增加一个层，尽可能完善业务的处理逻辑，整合微单元的资源提供给调用方。

[XSDo]

后端微服务不 rpc ，用前端来走网络调用多一次接口？ 后端 rpc 可以走内网，前端调接口是走公网的啊 想想都知道那个调用更高效。

[final7genesis]

如果真有那么多分散的微服务，架构设计是不是要来一个网关层？

[renfei]

既不是 前端的问题，也不是后端的问题，更不是 java spring 技术的问题。

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

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

结果就是

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

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

但是吧，确实有些场景不方面，数据全吐给前端，有些数据会泄露，慢慢又改回来一部分，目前前后端算是平衡了吧。

[yor1g]

就是跟风 瞎几把拆服务 系统上线后就特么就那几十人在线用

[daye]

人的问题，结贴

[brader]

你慌什么，像你那个树形结构，要根据 ID 调别的接口的，如果要你循环调 N 次的话，你调呗，他服务支撑不住让他们头疼去

[huang40614676]

@renfei #10 经典场景，太典了

[ChefIsAwesome]

往好的方面想，后端觉得自己搞好了，高枕无忧，前端天天忙。裁员就裁后端。

[JKeita]

这明显是人的问题

[yoyolichen]

用了微服务却不会写 rpc 接口，他是来搞笑的么

[chenPiMeiHaoChi]

微服务不写 rpc 还微个锤子，建议直接 java -jar 。

[LLaMA2]

如果你 TS 写的比较溜，那就偷偷的给他写一层网关吧。预留一点自己的奇技淫巧，保证在你被优化后项目成功跑不起来。黑嘿嘿。。。

[potatowish]

@final7genesis 不是网关层，应该需要一个独立的聚合服务层

[Helsing]

现在主流做法都是尽量数据云端化了，前端基本只负责展示

你们的后端开发很有问题

[ByZHkc3]

后端懒，在我们这是会被骂死的

[superchijinpeng]

人的问题

[miv]

这就是后端懒，想把事情交给前端做。
做一个业务，它的逻辑不在前端就在后端。
要么你前端搞了后端舒服，要么后端搞了你前端舒服。
作为一个前端，那肯定是让后端出靠谱的才行。
最好一开始要把接口规划好，需要什么给后端说，不能让他直接给你接接口自己去处理，因为太坑太大了。
如果后端能处理，最好是后端。因为前前端有很多地方会用到后端，一个接口需要对应，很多种情况，最好是后端处理聚合起来。
这个就是后端的问题。

[miv]

我前后端都搞，所以比较能中立的看待你这个问题。
后端如果这些不帮你搞，有可能是后端懒。
另外一个原因就是后端的抽象能力不够。
他只站在自己的业务上想问题没往接口层上做一个抽象。
建议你不要自己搞，因为如果其他业务很复杂的话，前端是需要处理很多工作的，你这样搞的话到时候接口很多很乱的。
最好是后端商量一下，然后统一处理聚合。
这样虽然后端工作量多一点，但是可以大大提高软件的健壮性。
测出来的 bug 也会少。

[tingyunsay]

我跟你反过来了，我们这逻辑全给后端了，前端只有纯展示

[Quarter]

如果是这样的话我觉得可以直接上 saas 了，前端自己生成接口，后端不需要的就裁掉吧

[silentsky]

如果需要适配多个端，那肯定是后端处理好比较好，不然多端做重复的工作。我写后端接口的原则一般尽量让前端傻瓜似的调用

[darkengine]

把情况反馈给 leader ，如果 leader 觉得这是合理的，边做边准备简历吧。

[carytseng]

六年经验感觉你司后端不行

[ql562482472]

看上面都说后端的，其实前端做也没什么问题，还是看频繁变动的在前端还是后端。还有数据的性质，界面展示的状况等等。这种小问题其实谁做都可以 只要理由充分。

[zcf0508]

你说的是我司吧哈哈哈哈

[sunqb]

@daley 看来你也没搞过复杂的管理端

[huzhizhao]

纯粹就是人的问题，技术不背锅

[chihiro2014]

纯粹是后端人懒。。。

[auh]

权力的问题。

[iseki]

微服务拆的有问题，拆的太碎了，然后缺了个 BFF 聚合层，压力就全跑到前端去了

[louisxxx]

和 java 有啥关系，这明明是人员技术水平差

[0xsui]

咱就说，你司这种情况的后端，薪资是多少(ÒωÓױ)！

[yosoroAida]

人的问题，用微服务居然不用 rpc （都 2023 年了，居然还说 rpc 接口迫不得已不写，盲猜没有实践经验）

[zfy941]

这后端倒是真省事 就是把数据表读取给你呗 啥关系都让你自己来

[bhbhxy]

前端在很多公司是没什么地位的，就我在的公司，一个年过五旬的领导还把前端称之为美工，认知还停留在 20 年前，有些后端更是这样，觉得前端没技术含量，把工作都推给前端，接口写好测都不测，等你反馈问题后看心情自己改还是让你改。

[lei2j]

不是微服务的问题，是人的问题

[lingeo]

下次直接把办公室当八角笼跟他 battle 就是，你不会还没跟后端吵过吧。我虽然是个后端开发，但是根据你的描述，我还是站你这边。先跟他线上沟通，不服就跟负责人反馈，负责人和稀泥就直接线下开骂。

[Erroad]

你不用试图理解他的逻辑，站在你的角度很简单的，这种需求本来就应该一个接口，至于你后端为什么做不成一个接口，那不是我的问题。如果容易造成更多风险，就该上升到负责人去协调。

[passon]

前端自己做个 bff 层，或者后端加个 bff 层

[nothingistrue]

本帖前面的楼层，大多数都是美工在回复，没有做过全局的程序员，或者高级的 UI 开发。

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

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

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

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

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

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

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



最后那个关于审批流程的问题，这个跟微服务、前后端都没关系，这特么就是个 BUG 。后端就没把接口做好，压根无需考虑是否合理，直接当成 BUG 提出去。

[TaoLoading]

差不多的遭遇，之前项目的子模块，所有的查询后端就一个接口是让我自己拼 sql 传过去，让我前端拼 TM 的 sql 传过去？？！！！当时刚工作不久还不会跟后端刚，那段时间真痛苦啊

[noreplay]

前端的前端，前端的后端，后端的前端，后端的后端。不知道啥样的公司，啥样的业务要搞这么复杂。感觉每一个公司都是人均阿里，都去搞一个中台，数据湖。说出去可牛逼了。

[J3W4]

虽然但是,后端不就是应该处理数据的嘛,
说白了后端就是不想干

[adoal]

是从一线互联网大肠毕业出来的不懂关系数据库不懂传统 CRUD 只会在没毕业的夹狗屎指定的萎服务业务框架里填空的后端吧

[Jame00001]

@bhbhxy 是这样的，很多后端看了眼 html 、css 就觉得前端不过如此，关键是你没法解释，天天看他们装逼

[justin2018]

遇到过这样的情况

后端想省事儿

1. 用 express egg.js 包一层

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

3. 跟组长反馈这个问题

现在前端都是万金油了 特么啥都给前端干~~

[uyoungco]

后端懒，有问题再返工就是

[wellerman]

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

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

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


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

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

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

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

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

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

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


最后，10 几年前，是没有前端这个职业，基本只有美工和程序员这两种。还有很多美工都是由程序员兼职的，比如 V2 就是那个时代的典型。当然了，现在后端兼职前端的也不少，像 V2 这样就不需要独立前端。前端的出现，就是因为可以把原本在服务端的计算放到客户端，节省资源提高可用性。做为一个合格的前端，应该是去压榨客户端资源，而不是服务端资源。不然前端就失去存在的意义。