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

[lihongjie0209]

1. 排序问题

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

1. 数据整理问题

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

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

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

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

[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]

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