关于数据加工，前端后端责任讨论

在外面这都是后端转好 前端复制展示

业务逻辑应后端处理，商家映射到 business，明显属于后端的业务逻辑，你的模型至少提供两个字段，一个是 name、一个是 displayName

这三个问题后端解决比较好
没有什么标准文件，后端标准都还没统一

你说的这三个 wanting 都是后端解决

例如前端有 Android，iOS，手机 Web H5，小程序，PC Web，如果前端处理，那么有多少地方需要处理，一个不小心就写错。

哎，又是一个后端直接返回数据，啥业务不想写的主。巴不得，前端可以直接入库、查库。

1. 如果你不想在这个接口中返回"商家", 那么你应该提供一个翻译接口, 让前端可以把"business"翻译为"商家"
2. 这个前后都可以
3. 取决于你对你接口的定义

谁打赢了谁说了算

看业务吧，该数据如果前端展示都一样的话，可以后端处理。

因为影响的因素不带一，这些问题都没有唯一解，单单拿这三个问题做分析，都是后端处理更为恰当，但是如果这些问题稍有变化，可能答案都不一样。

尽量后端自己处理，前端只负责展示和状态管理

哪边的平均工资高哪边说了算

今天前端要 c，明天可能要 d，你接口不可能跟着乱改的

多端 Android，iOS, web app，小程序...的话，无疑是后端处理最方便。
一端的话，前后端都可以做，商量着来（项目工期、手头的工作量），权衡一下，码农何苦为难码农

记住，前端就是个切图的，啥也干不了，有什么数据，都是照原样直接从接口直出到页面上....所以得后端干

@laoona
是这么个道理

说一个关键因素：很多场景下，前端更新达到率是很难 100% 的

数据加工后端比较好。

看 16 楼的意思，后端干了这么多活，事实上只比前端工资高 2k

简单啊,前端不做数据处理.
这些属于数据处理吗,
是,那就后端来做.
ps,小弟也是后端,这 2,3 根本没什么好问的完完全全就是后端的事

一些思考方式：
1、从整个全局链路来看，谁做最好？
2、谁的主动性更高？（谁好说话）

后端渲染前端只负责显示

工资高的做(滑稽)

具体情况具体分析，你说的这些目前来看，是后端做更合适。

如果多端展示一致，那就后端处理好，不用每个端都处理一遍，多一个客户端处理就多一点出错的可能
如果多端都要同一个数据，然后在本地进一步处理，做不同的逻辑或展示，那就前端处理，多端可以复用同一个接口，免得后端给每个端都出个接口
另一个考量因素是频繁更新的数据，而修改这些数据需要前端 /客户端重新打包发布，那直接在后端改数据好过前端重新打包发布

我们只是数据的搬运工[doge]

让后端去搞，假设你的第三方过段时间就不靠谱了，你不能让客户去升级新的客户端，后端切换新的 API 应该让前端无感。

第一个可以让前端解决。因为语言属于界面展示范畴，前端也要 i18n 的吧。
后面两个属于逻辑，个人倾向后端解决。

举个类似场景的问题，外籍教练到中国男足上班，教练不懂中文就必须有个翻译，那么挑选翻译的标准至少必须有以下几点：1、两种语言的口语水平相对一致。2、有足球相关的专业知识。

另外需要注意的地方是，教练、翻译、球员是三个功能责任相对独立的技术栈，一般情况下，教练或者球员无法达到专业翻译的技术水平。

所以，解决你的问题的关键是找到一个具备你所列举的相关问题的技术栈的“第三方角色”，考虑到前后端本质上还是处于同一个技术领域，前端或者后端中有人可能有能力兼任这个角色。

但是，工作内容划分上，还是必须大致分为 [前端] [后端] [交叉] 这几个部分， [交叉] 的部分不能让无法胜任的人来做，换句话说，就是不能让只懂前端或者只懂后端的人去做。

我觉得吧, 后端应该注重计算和逻辑处理, 前端应该负责展现和渲染.

那么需要计算的 2 和精确逻辑判断 3 的应该由后端干, 而进行简单映射转换的 1 应该后前端干. 你不能因为‘前端’ 好几个同事都要写一遍映射, 就把这个推给后端只用写一遍. 当用户数量起来了, ‘前端’干多少次处理基本不影响, 但是全丢给后端干, 那就是‘广大用户吊锤服务器了’

原则上我同意 @wu67 在 31 楼的观点。单纯的显示，例如从某个名字换成另外一个，这种事情应该由前端实现。但是如果需要计算平均值，求和，甚至搞不好还要搞机器学习，这种东西应该后端来干。
所以 1 应该前端干（当然，假如你的翻译还需要用到另外一个后端数据库甚至 NLP，那就是另外一个故事了）。2 和 3 都应该由后端来干。
我不太了解这是不是属于架构层面的事情......

一个报表下载 PHP 后端以数据量太大为由拒绝输出结果 要让客户端分页获取然后再拼接 Excel 总共两万左右的量级 他说 PHP 内存会爆掉……

这种的最好交给前端。
虽然只要不是返回 <view>这类型的，基本上后台锅。

@Soar360 这可能是 php 的锅

啊哈哈，很多后端都扔给前端处理了，唉

应该是后端负责处理的，前端不需要知道数据是从哪里来的

最基本的原则当然是能扔给客户端做的事情就全部扔给客户端，除非存在内容被篡改的风险。
这样可以降低成本和 CC 的风险。
不过现实中往往是倾向于节约成本所以往往想不到内容存在被篡改的风险，结果导致很多安全隐患。

楼上说到能给前端做的别给后端做的人一只手都能数过来

有些是后端做的。比如去重。但 lz 这些可以前端可以后端的。肯定都让前端做。假设你 a 客户端要现实客户。b 客户端要显示爸爸。c 客户端要显示甲方。一个接口肯定干不了。

另一方面，平均数的问题。服务器资源不是钱啊…

我的原则是 前端只负责展示数据,不错数据加工, 更别说计算了.

@Soar360 #33 是这样的
之前做导出 数据到接近 2W 的时候就开始不行，加内存限制和运行时间感觉也没啥太大意义
后面直接就是走异步 CLI 模式跑 另外做个页面展示所有已生成的文件让用户下载和删除

于情于理，数据加工这块应该是后端干的。
但是呢，如果多个不同客户端，不同版本要的东西不一样，那就扔回去，别客气，要不然以后全是坑

前端负责数据格式化显示，后端负责提供基础数据。

典型案例：某个数据为 10%，后端应当返回 0.1 而不是 10%，应当由前端将 0.1 格式化为 10%

同理，某个数据为 10 万，后端应当返回 100000 而不是 10 （万），应当由前端将 100000 格式化为 10 万

理由：后端并不知道如何显示数据更好，后端只需要提供统一规范的基础数据，前端与用户体验有关，根据实际情况转换为不同格式的数据进行展示即可

这个时候你需要数据中台，先在 nodejs 层将数据转成自己想要的

1 如果值是 bussiness，那是后端的活儿
如果属性名叫 bussiness 值是 0/1 或者 t/f，我们这是前端的活儿

2,3 都是后端

1 如果值是 bussiness，那是后端的活儿
如果属性名叫 bussiness 值是 0/1 或者 t/f，我们这是前端的活儿

2,3 都是后端

1.前后端都能干,建议后端提供翻译接口或者前端翻译,不建议直接返回商家,一个是中文传输可能存在问题,另一个是翻译成中文英文信息就丢失了;
2.前后端都能做,看返回 A 和 B 的这个接口是否可复用,属于会被其他服务调用的基础服务,若只是为当前页面定制的接口，必须后端做;
3.后端做。

谁最近划水划得多谁做

1、所有接第三方接口的都过一手自己的后端，这样好处是可以保证第三方换 API 的时候自己可以不用发版无缝切换。
2、关于计算和渲染部分，有时候利用客户端的 CPU 和 GPU 会减少服务器压力，这个得根据具体业务来进行，因为如果这样的话存在数据被篡改的可能。

GraphQL 了解一下（ FB 出品，必属精品）
t/589138

这个对应关系原来叫数据加工啊

@sampeng 我说的是我的国家，从帖子里看出中国的情况好像不太一样。目前欧美的问题其实是前端做了太多后端的活，导致了很多安全隐患。我猜测中国应该是因为大家都在自己造轮子所以导致了相反的情况。

后端做方便，前端做节省服务器资源

这特么就没有一个明确的标准，上面一堆前端甩锅给后端，后端甩锅给前端。

当初说起前端工程化，前端渲染、前端路由的时候前端可是抢的挺有劲的啊。

个人觉得这个数据组织谁来做就根据当前架构来，前后端分离的，前端已经上了 MVVM 的，就自己处理了吧。

还是传统后端渲染，前端做一些简单交互的，后端处理吧。

很简单的问题啊，

前端：不就是个接口么？
后端：不就是个页面么？

保命

你们公司的人这么会甩锅你还呆着干嘛 ，这么一件小事还要论责任。。。

1 2 前端做，3 后端做

第 1 种情况，第三方 API 返回的数据，后端要不要存数据库？如果不涉及数据库的，还让后端处理，这有点过分了，后端 IO、CPU 都是钱啊。

我司都是后端做了，不过我感觉 1 2 这种前端做也无妨，如果后端不要入库的话

肯定是前端做
后端做的话用户多了影响服务器性能
前端消耗的是客户机的资源
而且是分散的

跨多端的话，后端做数据加工，改起来方便。
越灵活多变的需求，数据加工环境越需要往后端放。
前端只负责实现不同展示效果，具体展示内容，例如价格格式化都可以交给后端。

front-end provides what back-end provides AS-IS
所以叫 “前端” “后端” 而不单是 “网页端” “服务器端”

不这么做的不叫前端叫 “对后端的封装”

昨天刚和 @mayswind 说过这个……但日常被锁……
AriaNg 是一个优秀的封装，但绝不是一个合格的前端。

如果用户量小，前后端做都一样。
如果用户量特别大，后端做会消耗服务器资源（字段越多，消耗越大）；前端做的话，如果出了相关的 BUG，需要修改 APP 代码，需要审核上架（不考虑热更新），对用户影响会较大；这个就看你们怎么权衡。
我们目前是后端做的，在不同的端（ web，APP，h5 ）和后端 API 之间加一个适配层，负责每个端的数据格式化。

前端:后端处理方便，数据统一，改动无痛热更新
后端:前端处理客户端分摊服务器成本，节省服务器资源

所有第三方接口尽量后端转一次，便于统一维护

来来来，举几个例子：
1、前端需要显示时间，但是要按照客户所在的时区和不同的 Format （“年月日”/“月日年”）呈现时。
2、终端存在多语言客户时。
3、多个终端（ Web、APP ）取同一个后端资源且输出内容稍有不同时。
4、前端请求数据过大，存在优化空间时。如若干个小的 tree 或 list 返回在前端拼装成 list 输出，要比后端直接提供 list 传输量小。
5、后端 API 不是自己的项目所提供的。

以上情况，谁会选择让后端处理，那才是见了鬼，尤其是情况 5。

但是另一些情况则刚好相反，比如楼主说的查询优惠券，交给前端处理才是脑子进水了。
所以这个问题根本没有标准答案，一切都要依据实际情况具体分析决定。而且摆在面前的选项绝对不是非此即彼的，某些时候是需要前后端各做一部分数据操作，两端同时处理的。

当前后端都可以处理时，可以适当分一部分给前端处理，现在前端设备都是性能过剩了，而服务器资源较贵

一个 utils 文件里的一个函数的事，分什么前端后端 ...

当然是数据中台处理啦
后端只应该关注架构扩展和性能,提供最基础的数据服务
然后由前端写 node 中间层自己爱咋玩咋玩

你们想要个 BFF，专门做这些事

@daveze 纠正：你们需要个 BFF，专门做这些事

前端不算程序员，所以后端做

这种问题从前端段分离普及以后，就没有停止过争吵
在“高素质的程序员应该用最少的成本完成需求覆盖”这个基本原则下
楼主列三种情况就很好区分由谁来做了

场景 1 应该前端 /客户端来做
场景 2/3 应该由服务端做