前后端分离的边界在哪

[zioc]

有一句话说业务逻辑后端做，渲染逻辑前端做。

具体怎么理解呢？

例如表数据如下：
id name pid
0 广东 -1
10 广州 0
11 深圳 0
21 天河 10
22 南山 11


前端需要的格式如下：


A 方案后端递归处理数据最后输出如上，前端直接使用


B 方案服务端直接按照表结构给数据，前端递归，格式如下：


B 的好处是：
1 后端输出简单，节省服务器资源
2 源数据结构，不管页面怎么改，restful api 都不用改
3 分离清晰，后端只提供数据



是 A 还是 B 呢？

[bengle]

前端更偏向交互，后端更偏向业务逻辑。理论上应该是这样，但是现实中只能各种撕逼。。。所以需要一层前后端对接的中间层，后端保持一种数据结构输出，中间层把后端数据转成前端需要的结构，这个中间层可以后端搞也可以前端搞，我厂是前端做的，诶～

[johnpang]

[
{"1":{"name":"广东","pid":0}｝,
{"2":{"name":"广州","pid":1}｝,
{"3":{"name":"天河","pid":2-1}｝,

]


在已知层级数的情况下这样会不会好点呢。。。

[zioc]

@x464744246 实际业务类型并不是省市
@bengle 感觉现在前端做更合理，或者叫客户端
@learnshare 如果把前端换成 iOS/安卓客户端呢，应该客户端做吗
@sagaxu 这个沟通成本更高了，如果中端的工程师水平一般或者对接口质量没有追求，那简直是一场灾难。我前公司就有中间件。
@ywgx 比较同意，而且前端处理起来并不复杂

[learnshare]

@zioc 移动端也不做
类似的数据几乎是永远不变的，服务器生成一份缓存起来，以后就都是直接返回了，代价真的小

[zioc]

@learnshare 如果数据是变得呢

[learnshare]

@zioc 变得也有理想的改变周期
比如估计一天才改动一次，那缓存 1 小时，改动后更新缓存。类似的设计