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

[zhoupeng199]

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

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

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

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

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

[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 接口迫不得已不写，盲猜没有实践经验）