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

[zhoupeng199]

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

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

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

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

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

[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 这样就不需要独立前端。前端的出现，就是因为可以把原本在服务端的计算放到客户端，节省资源提高可用性。做为一个合格的前端，应该是去压榨客户端资源，而不是服务端资源。不然前端就失去存在的意义。