关于前后端分离接口和展示层的一些问题

[lihongjie0209]

1. 排序问题

假如接口返回的数据是 3 1 2, 但是前端需要展示的是 1 2 3, 并且没有分页, 一共就 3 条数据, 那么这个排序是前端做还是后端做.

1. 数据整理问题

假如接口返回的是一个数组, 但是前端需要一个树, 那么这个数据整理是前端做还是后端做.

我的想法是后端和展示层不依赖, 数据整理和排序都应该是展示层的工作.

实际情况是前端做起来很费力, 只能我专门写一个整理好的接口.

再次说明了: 技术问题最终还是人的问题.

后端这些都可以做, 没问题. 但是因为树型接口我已经改了好几次了

刚开始我给了一个数组, 前端说组件不支持这种数据结构, 要我给一个树

我改接口, 给了一个树

测试提 BUG, 说树节点的顺序不对

前端说是我的接口问题

我又改接口, 增加了排序


上述的问题本来都可以避免的, 前端已经拿到了全量的数据, 怎么整理, 怎么排序都由前端决定.
现在, 测试给前端提 BUG, 前端再把 BUG 转给我, 大费周章值得吗

[MotherShip]

1 取决于这个接口是否有其他端调用，没有的话可以后端改

2 数据结构还是后端做吧

[akari33]

1.前端 2.后端做一个 vo 实体类返回给前端

[dongisking]

排序问题
一般是我后端做
数据整理问题
一般是我后端做（例：评论和 reply 评论）

[April5]

没说清楚前端难在哪

[LongMaoz]

目前我是用 TypeScript 写前端数据结构，NetCore 写后端接口
后端的数据返回结构可能跟前端所需要的不一样，所以我前端是把后端的 BaseModel 搬过去作为基类，
然后前端的数据结构在 BaseModel 上 Extend，后端只做数据返回，比如你的第二种情况，
我是把后端的数据丢进前端的已经 Extend 的类种的构造函数里面进行实例化，这样就可以后端只返回数据
前端的 BaseModel 用来接收数据，同时创建新 Class 用来 Extend 基类，类中再进行数据转换以及整理，这样应该是可以完美实现你的需求的

[passerbytiny]

前端 Model 层或类似层，后端视图层或者端口适配层，都可以做，谁做只取决于谁愿意和有时间干，跟技术无关。技术上可以确认的是，非常不能让后端业务层去做，不建议前端展示层去做。

[stx2012]

当数据量大的时候，前端计算很费资源和时间，还是后端做比较好

[LongMaoz]

后端返回结构👇

export interface ApiResult<T> {
code: number;
msg: string;
result: T;
}

T 里面放后端的数据结构基类
然后 T 类的 Extend 的类中定义构造器参数为 T 类
进行实例化就可以了

前端基于后端的 T 类 进行 extends 的结构（ Contact 类就是我 Group 类用到的基类，也就是后台返回的 T 类型）👇
export class Group extends Contact {

public upperlimit: number;
public creater: string;
public announcement: string;

constructor(baseGroup: BaseGroup) {
super({
key: baseGroup.id.toString(),
name: baseGroup.name,
imgSrc: baseGroup.logo
});
this.creater = baseGroup.createUserID.toString();
this.upperlimit = baseGroup.grade;
this.announcement = baseGroup.description;
}
}

[cwjokaka]

如果我是前端，我会倾向于给后端做。反之亦然

[ben1024]

加个 Formatters 层

[lneoi]

如果整理数据太耗费时间，比如又排序又对比还得重新组织结构，或者多端都需要重复这一步骤，这块就归后端处理了。

[cyndihuifei]

这种事情后端处理没什么好说的吧，我自己既是后端也是前端，很反感前端对接个接口还要处理来处理去

[liuhuansir]

你举例的两个，真的可以无所谓谁来做，完全看人的，有人觉得举手之劳，顺带就做了，有人嫌麻烦，就让对方做

[PerpetualHeng]

两种都有，前后端都可以，但是全部后端处理，会更好一些。

[bin20060407]

前端能做，不代表前端一定要做，尽量让前端渲染数据更简单是我们这边后端团队的宗旨。

[kanezeng]

其实我觉得这两个例子都无所谓吧，大多数时候我都是后端直接做好了出来。不过如果真碰到需要转换的时候有时候我也放用户的前端，让用户的机器帮我们的后端分担点计算资源嘛。

[will0404]

这两点前端都能做，而且很简单，但不应该由前端来做。前端的职责是渲染和交互，仅此而已。
通常不太负责的后端会说，这么简单的事你前端做一下就好了，我会怼回去，你不会写的话我来帮你写后端。

[serge001]

我觉得前端做,这样才够灵活,不然你今天要这样的排序,明天又想要那样的排序,后端的接口岂不是要反复变;然后对于所说的扁平数据变树跟树状数据变扁平, 除非数据量很大,影响到了性能跟体验,还是在前端做比较好,因为前端可能同时用到扁平数据跟树状数据;

[xuanbg]

排序一般都是后端做，因为排序往往还有分页。树形显示不是只要对象包含 id 和父级 id，前端组件数据绑上去就好的吗？

[lihongjie0209]

@serge001 我主要也是有这方面的顾虑

[lihongjie0209]

@xuanbg 不带分页的,审题

[lihongjie0209]

@will0404 前端改 UI 的话, 需要的数据不变, 是不是后端就因为数据格式的问题还要改接口

[lihongjie0209]

@liuhuansir 不是举手之劳的问题, 后面前端要改 UI, 你还要跟着改接口, 是耦合的问题

[zr8657]

前端的重点是与用户的交互，这种处理数据结构的问题应该后端做。

[lihongjie0209]

@zr8657
前端的重点是用后端的数据与用户交互
数据后端给, 交互的前端的事情.
至于前端拿到数据要怎么处理那是业务决定的, 后端不可能也不应该专门为了 UI 的方便而改接口

[Chingim]

后端做。因为一个接口可能对接 web，安卓,ios 等等各种客户端，客户端做就重复劳动了。而且排序规则改变时，若干个端都需要改。
当然排序这么简单的东西，谁做都一样。但是以后如果需要加分页了，那还是后端做，从扩展性上考虑，后端做比较好

[lihongjie0209]

@Chingim 没有多端, 所以暂时不考虑

[a62527776a]

这种应该是需求定的把 怎么能因为前端说组件不支持就要求后端改接口呢

[will0404]

@lihongjie0209 你的假设就是错的，接口不应该根据 UI 来定。既然你接口要根据 UI 来定，那么 UI 变了接口跟着变不是合理的吗？这个点在于，接口不是跟着前端变，而是接口和前端都跟着 UI 变了。

[a62527776a]

我感觉的问题是
前端说组件不支持数组 所以要个树
那不是应该前端自己找个支持数组的组件嘛

[lihongjie0209]

@will0404 我的意思是, UI 需要展示的数据我都发给前端, 至于说前端要展示 列表还是树状结构那是前端决定的. 就像前端展示 "2019 年 1 月 1 日" 或者是 "2019-01-01" 和我后端没关系

[OSF2E]

理论上说，交给前端来排序没有问题，但前提条件是 ——　由前端来决定什么时间请求数据以及如何请求数据。

“前端做起来很费力”，只能说明交互场景设计、视图状态分析等等工作拆分的还不够细。

换个角度说，不能用后端“少量字段抽象一个模型”的思路来处理前端问题，应当先分析交互流程，将一个完整的功能拆分为一系列静态场景，然后由前端提出后端数据接口的适配需求，也就是说实现一个功能可能需要提供多个接口，而不是后端把数据“一锅甩给前端，让前端自己在里面选有用的”。

[lihongjie0209]

@a62527776a 嗯, 前端组件需要什么数据结构肯定是前端自己处理, 现在和后端接口耦合了

[lihongjie0209]

@OSF2E 我说的费力是前端的组件需要一个树, 但是我给的是一个数组

[liuhuansir]

@lihongjie0209 前端 UI 变，接口跟着变也是常事，再说就这两个例子又不复杂，后台跟着变也无关紧要吧，商量着来就行了

[Caballarii]

所以现在经常有一层 API 转发，通常是 node，拿着后端大而全的数据，变成更精细的数据接口给前端用，属于前端的活

[version]

推荐是前端转吧.我看像是后台管理的应用
能减少后端的业务混乱才是好前端
一对多.多对多.树形结构.后台管理本来数据量不大.没必要后端去拼接..
前端都 vue react 有状态机了.很方便拼接的了.

我一般是让前端改..不会写的.我会帮前端写.然后再喷他们菜.一个数据处理都不会的前端都是 lj
所以前后端分离.不是一条心的..最终整个团队都是毒瘤了..接口数据拼接多.接口会忙.再加需求.后端抗不了的了

如果是 app 的那些接口.就统一后端处理数据了...最好前端只做展示.包括日期

[zmyongfeng]

打得过就让他做。打不过就自己做

[lihongjie0209]

@liuhuansir UI 变的意思是在所需数据不变的情况下调整 UI, 最简单的例子 前端展示 "2019 年 1 月 1 日" 改为 "2019-01-01", 这种情况下接口是不需要改变的

[KingOfUSA]

前端做。

[unco020511]

一般是后端处理,前端避免数据计算和整理

[lihongjie0209]

@version 这种数据处理工作 map reduce filter 直接解决, 没什么复杂性, 下次我直接帮前端写代码

[liuhuansir]

@lihongjie0209 我能说前端展示 "2019 年 1 月 1 日" 改为 "2019-01-01"，这种需求，我们的后端都愿意帮忙实现。。。可能是我们工作量都不饱和吧，人家愿意做，我总不能拦着吧

[lihongjie0209]

@liuhuansir ...........无话可说, 佩服佩服

[guorui112]

看和后端关系好不好，以前和一个关系比较好的后端做项目，都是抢着做，看哪边处理方便

[OSF2E]

@lihongjie0209 锅背不动了，那就不背了

[version]

@lihongjie0209 如果是后台管理最好要喷喷前端的了.不行就自己改了..后端再转..以后合并其它数据更加难..例如 table 是 5 个连表出来的数据...一个单独的 tag.都需要我转字段给他们..我就要说了..这无疑会搞垮整个 sql..后端再转多一层分明就是业务乱了.以前试过..后台管理不能让前端做话事权..能前端转数据的是最有利于以后迭代的..

[15651980765]

我司前端没人权，此类工作都是前端在做，后台大部分时间都是直接给全量数据，前端要啥数据，自己遍历去取然后拼成想要的格式，我已经不止一次吐槽过后台了，然并卵！

[will0404]

@lihongjie0209 你举的例子是两类问题。
要列表还是要树，后端做。
时间的格式，前端做（后端提供时间戳满足所有场景）。
对于第一类问题我说了，你接口是根据 UI 定的，从列表换到树，想必 UI 变了吧？而且改动还不小，有什么理由不重写接口呢？
举个例子，通常接口返回的数据会有一层数据校验，在后端某个中间件上，你不打算改接口，返回的旧数据，而数据转换放在了前端，那一层服务就形同虚设了。

[raynor2011]

和显示强相关的，必须前端做啊

[lihongjie0209]

@will0404 ui 变了, 但是数据还是那些数据

[527944441]

第一个谁做都行 第二个我觉得做之前应该商议一下

[Caballarii]

市场上彩笔前端太多了，培训班出来一点基本功都没有的，造成了都得后端帮忙的现状

[Sapp]

第一个问题无所谓，第二个问题得看具体情况，如果就是这一份数据需要稍微转换一下，实际谁做都可以。但是如果这个结构涉及到很多接口的调用组合然后才能拼出来，那这个接口设计就有问题，也不存在谁做的问题了。

[TimPeake]

作为前端做过类似的。
特别树形之类的复杂嵌套之类的数据，真的是后端做方便点。
后端可能几行代码解决了。 前端却需要十几行甚至几十行代码去转换格式化成理想数据，可能还有 BUG

总结：你把东西推给前端，工作流程没有错。但是出于道义，我建议你多为你的前端考虑一下

[lihongjie0209]

@Sapp 全量数据, 不存在调用多个接口的问题

[deleteDB]

第一个问题 后端做 如果有一天需要分页全表排序 前端是做不了的 还不如现在后端就做了
第二个问题 谁做都可以 数据量大推荐后端做

感觉没什么代码规范 要不然至少不应该有第一个问题

我是前端

[lizz666]

让我想起了上个项目，涉及到腾讯广点通区域定向和今日头条区域定向数据，这两个平台返回的数据结构并不一致，我前端有个树形结构，需要按我树形结构格式给我数据。
头条的数据由于是死的，官方文档上有，我直接在前台写死处理好了。腾讯就比较 fuck 了，必须通过腾讯的接口才能拿到那么多数据，一开始，嫌烦，让后端帮我做，结果，数据太多，接口超时，后来实在没辙，还是交给我前台来处理了。

[keikeizhang]

和 demo 操作没有关系的数据处理一律是后端的工作

[lihongjie0209]

@TimPeake
同样的逻辑用 java 写和用 js 写代码量不会有太大的差距
后端实现的唯一好处在于标准库比较丰富, 静态检查比较严格.

[lihongjie0209]

@deleteDB 第一个数据量是死的, 就几条

[tailf]

这些前端数据格式化的需求，理论上需要配一个 API 层来处理，这一层只负责给前端需要的数据做聚合和结构处理，这个是有后端工程师做的，但是却属于大前端的范畴。

其实大多数常见的场景都很好办，上 GraphQL 规范，搞定。

[freakxx]

这个问题其实主要看谁有空，谁方便，但有个平衡性

如果是数据展示的问题可以考虑类似
?format=json or ?format=xml 这种方式

如果数据是固定的，资源性的，那么考虑 /api/<api>/xxx/这种给他做个特殊化，比如
/api/students-tree/ or /api/students/tree/

[15651980765]

@lihongjie0209 话说请教一下数据量大的时候，放在前端处理，对页面性能会不会有什么影响？

[serge001]

我是前端,反正我觉得这些大部分情况下都应该在前端处理,为了处理数据格式没必要加多个 node 中间层...

[limuyan44]

解决问题最快的方法是让测试直接把 bug 提给你，这样不就不大费周章了。

[KingOfUSA]

因为有类似的问题，所以现在团队里面的前后端交互都是让后端的同事来负责(美名其曰 全栈)，前端的同事负责做静态页面以及后端解决不了的问题。

[BreezeInWind]

我前后端都做，做前端的时候我就跟后端说数据随便给，我自己处理成合适的格式，只要别多余浪费就行，比如要五条给十条，要十个字段给二十个字段之类的；做后端提供接口的时候就找前端确认好要的结构，争取他们不怎么用写任何多余的处理逻辑就渲染出界面，。这件事怎么做感觉就是存乎一心，做有做的道理，不做也有不做的道理，如果有合适的机会，前后端都做一下，你会对这件事有不一样的感悟的

[Yuicon]

看了半天 就是一个扯皮的问题

[l00t]

当然应该前端做。这就是个前端显示的需求，跟后端有什么关系。

[coolooks]

有时间来这里扯皮，没时间改接口，闲的蛋疼

[lihongjie0209]

@coolooks 接口早就写好了, 只是讨论一下这个问题而已

[lihongjie0209]

@Yuicon 是一个规范的问题

[rr41ns]

都是后端处理。

[rr41ns]

本人是后端，工作久了就知道沟通的成本很贵，只要是我力所能及能做的我就做。

有时候排序是 sql 里加个 order 的事儿，后端不弄还要让前端去专门排序考虑数据正确性吗？

有来回沟通的功夫早就弄好了，而且，这些活儿确实是该后端处理。

[drlalll]

事实上很多前端只会做界面，逻辑非常差。所以一般逻辑问题都是后端处理好，当然你们这个问题属于沟通不畅。

[coang]

如果是树后端做比较好.. 你排序问题 要加数据处理 而不是说前端要这个顺序接口就改成这个顺序.. 排序问题要对应有排序的参数... ps.我是后端

[zydxn]

第一种情况，一般接口都有默认排序，如果业务需求上来回变化，走配置。
第二种情况，如果需求变化，要求提供树，就再加个树接口。

[passerbytiny]

@lihongjie0209 这个其实后端做也是可以的，后端可以在不动领域模型 /服务核心层的情况下，针对不同的前端、版本、特殊定制出不同的接口。传统的 Dao-Service-Controller 分层，如果正确的隔离 Service 层和 Controller 层，是很容易以很少的工作量来实现这种效果的。此时，接口由前端定义——但前端需要深入了解领域模型或业务模型。这样安排，对整体的好处是前后端之间更加松散。对后端的好处是：后端虽然没有了接口的主要控制权，但也没有了定义接口的责任。

不过，以上只是一种可以选择的方式，而不是建议的方式，具体哪种方式，取决于架构师、技术委员会或者技术负责人，如果都没有，那就取决于前后端谁的话语权更大了。

[hyy1995]

其实这些个逻辑前后端都能写。但接口可能会多页面重复调用，如果是这样的话数据格式还是后端处理比较好

[tingfang]

都可以，我觉得后端做更好一些，前端如果是 APP 或者小程序，逻辑改动还需要审核发布，后端做的话改起来会更方便些？

[santom]

数据量不大 随便都可以吧 数据量稍微大点 还是后台做吧

[dicc]

用户量大的话,后端做就不好了

[Hakka]

排序问题
一般是我后端做
数据整理问题
一般是我后端做（同三楼）

[dongxiao]

看是否改动频繁吧，如果改动频繁前端做比较好点，不然每次调整页面都需要改动接口，如果基本定下来不会动了，后端改起来还是要快点，话说公司最近的一个项目包括页面显示的文字都是我这接口返回的，就是 No.1 xxxx No.2 xxxx 这种，前后端还是要多多配合，都是为了进度不是嘛

[zsy979]

到底由谁做？没人能给最终结论
我是后端前些时刚经历了因为数据结构问题跟前端扯皮。。
树形结构转换在扯皮过程中都是小事，也算是头一次遇到糟心的前端可能他也是这么想的。
现在好了没必要因为这种问题去扯皮，就算说服他让他转换又能怎样，他可能还会想这个煞笔这都不会或者这都懒得做

[x7395759]

此时就需要多一个层了

[mmuggle]

GraphQL

[NotNil1]

树的话我一般每个节点会额外给一个排序字段，层级字段。

[xianxiaobo]

建议分成三个职位，一个后端，只做数据库的增删查改，一个前端，只做页面渲染，交互和样式书写，还有一个中端，专门做数据转换，将前端传入的数据转换为后端想要的数据，将后端返回的数据转换为前端想要的数据，以此解决此类扯皮问题。

[MoRun]

这个得看情况
如果你的后端很重，有很多任务要做，比方说后端是一个负载均衡的网关，或者需要对个多展示层，那展示层的数据需要给前端做，或者再加一层数据处理层来专门做这个事情，比如说 GraphQL
如果你的后端仅仅只是简单的增删查改，我觉得还是尽量配合前端比较好

[CoCoMcRee]

我这里 后端大多接口都会提供排序字段, 支持正反排序.
最外层肯定是树形结构.
{
"success": true,
"errorCode": "",
"message": "",
"data":

}

[CoCoMcRee]

data 里头才是前端要的数据
而且 ,谁说只有后端才做数据校验

我这里前端对后端返的数据也要做数据校验的哦, 不同接口,校验的字段和结构都不一样哦.

[bdnet]

1. 问题不应该是 没有事先约定好接口数据结构？

2. 业务逻辑尽量收拢在一个地方，也就是后端，后端可以加一成，处理数据转换

[yufeng0681]

1、还缺个组长，定义接口数据按什么排序返回；
2、后端做得越厚，前端就越简单，多个终端做起来一致性也容易保证。
3、你想做得灵活一点，就让前端传排序参数，支持多种排序方法返回数据。

[petelin]

屁大点事 这都无所谓 当时文档怎么写的就怎么改

后期需求就看谁的老板硬

这都无所谓有什么好讨论的

[nidaye999]

后端做，这么弱智的问题

[a852695]

尽量后端做，前端核心是交互和数据可视化，你非觉得 chrome 性能好到比你服务器还快，那你就前端做吧

[a86356]

后端做，数据结构后端做，给前端需要的数据结构即可。前端也一样的，提交数据的时候给你需要的数据结构。没什么好说。前端主要是交互。而且排序什么的，后端处理一 order 的问题，前端做还要遍历再排序，浪费时间。前端要做的是一些小的数据转换显示，比如时间搓，一些状态，1.2.3 转成对应文字。

[a86356]

@hedamao9999 说的很对，都做过考虑会比较周全。要不然一叶障目