这是一个创建于 1940 天前的主题，其中的信息可能已经有所发展或是发生改变。
这几天和前端同事对接，遇到一些分歧。 前端同学认为我应该把页面每项数据都用 API 直接返回，前端拿到的就是直接可用的。 我认为我提供一些基础数据就可以了，除非特别复杂的逻辑，前端可以通过一些简单的计算得到自己的要求（计算量并不大，我看了下就是简单的求和之类的）。
因为前端的需求比较复杂多变，我在了解需求的情况下，提供现阶段基础数据就可以，具体怎么计算由前端负责。大家觉得呢？（惭愧之前虽然是后端，但一直做 infra 的工作，没有怎么做过 API 方面的对接）
备注： 一个页面如果按前端的说法 可能后端会有 n 多个 API 接口 目前暂时使用前端做法
第 1 条附言 · 2019-09-10 23:28:10 +08:00
大家的观点我基本上都看了，看到了做一个懂前端技术的后端的重要性
 |
1
tourist2018 OP 目前我这边妥协了
|
 |
2
jamesxu 2019-09-09 19:00:21 +08:00 via iPhone  1
看情况，我这一般直接后台返回，前端直接显示，因为如果还有 app 或其他应用调用的话，每个应用都得写一遍
|
|
3
tourist2018 OP @jamesxu #2 没有 app 只有前端调用 而且是单一的
|
 |
4
springz 2019-09-09 19:02:35 +08:00
只提供基础数据，前端要是觉得不合适，我可以把 Model 层给他们写了。再撕就不需要前端了。
|
|
5
springz 2019-09-09 19:03:26 +08:00
后端计算成本非常高，平白无故增加计算和 IO 开销
|
 |
6
672795574 2019-09-09 19:03:28 +08:00 10
我是后端，认为放在后端好一些。
说一个点：需求改动，涉及 APP，小程序发版本。后端效率要高于前端。 |
 |
7
chenzheyu 2019-09-09 19:03:40 +08:00
json 格式啊，复杂度看心情跟工期，后端忙不过来就简单点，很闲就顺手做点修饰呗
|
 |
8
oddisland 2019-09-09 19:06:12 +08:00
按照你说的情况来看，我觉得前端做简单计算更好。
但是一般还是后端直接返回结果，前端做展示更为妥当吧。 |
 |
10
fffang 2019-09-09 19:14:14 +08:00
没什么特殊情况的话，能后端做的一律后端做。
|
 |
11
xxx749 2019-09-09 19:17:34 +08:00
我，前端，基础数据
|
 |
12
ArtIsPatrick 2019-09-09 19:17:44 +08:00 via iPhone
前端都是被你们惯坏的，后端怎么会帮前端写聚合转换逻辑？不知道怎么写就按标准来，RESTful 和 GraphQL 二选一，你这种情况 GraphQL 可以完美解决。实在不行就在后端加一个聚合层，专门做接口聚合，还能顺便做点网关的功能。
|
 |
13
no1xsyzy 2019-09-09 19:21:09 +08:00
按标准的 “前端” “后端” 叫法分，就是后端提供数据，前端提供显示。
请其他分法不要叫前后端： 1、把 B/S 写成类 C/S 的，包括 SPA 请求生数据客户端计算的 —— 请叫 WC/S （ Web Client/Server ）； 2、用 WebSocket、高频轮询 等实现前后端同步的，请叫 WebUI ； 3、强行把接口设计不良的服务器套层 Web 变成用户友好的，请叫 Wrapper ； 4、欢迎补充…… 当然具体用哪种可以自由选择，组织结构决定软件结构。 |
 |
14
orzorzorzorz 2019-09-09 19:26:43 +08:00
一些典型的数据结构还是提供下吧，比如说行政区划树。前端渲染的时候还是得把扁平化的数据递归嵌套或者做类似的操作，这就很难受了
还有一个，一般而言，针对小厂的话，后端其实要干的事大多数是对业务跟设计库表，后端们会给前端写个通用的接口，然后给个部署方法让前端自己去写 sql。比如 /api/data?key=xxx，前端到指定资源文件里写 sql，接口返回的查询数据。一般这样会积累不少通用的脚本，只有一些个性化很强的接口才会让后端去写 |
|
15
no1xsyzy 2019-09-09 19:31:18 +08:00
还有一个就是 RESTful 要让 Web 端计算的话做好打不开的准备。
一堆小请求直接阻塞，反正浏览器限制同域名同时 6 请求。 |
 |
16
DOLLOR 2019-09-09 19:31:37 +08:00 via iPhone
太基础的数据，别人拿来就可以猜出你的数据库结构，做攻击尝试了
|
|
17
no1xsyzy 2019-09-09 19:32:42 +08:00
@orzorzorzorz 你说的这个，不就是自己造了个 GraphQL ？
|
 |
18
337136897 2019-09-09 19:36:52 +08:00
我是个后端抛开所有其他不说，我认为后端直接把所有逻辑计算好返回给前端就行了。前端请求接口拿到数据直接渲染就行。无非就是服务器压力大一点。没必要把计算性能都分发到每个用户的手机上。手机越用越卡是有原因的，都各种各样的计算，耗费手机 CPU 性能。让用户多点体验不行咩
|
 |
19
nyaapass 2019-09-09 19:39:09 +08:00 via iPhone
辣个男人可能不会来了
|
 |
20
starsriver 2019-09-09 19:42:08 +08:00 via Android
简洁，充分，明了，优雅
|
 |
22
LiuJiang 2019-09-09 19:48:20 +08:00
前端只做展示，后端负责具体数据计算。主要是前端自己说了不算啊！！！
|
 |
23
Baymaxbowen 2019-09-09 19:51:15 +08:00 via Android
如果你后台的东西变了你改一遍后前端又得改一遍
|
 |
24
Fishdrowned 2019-09-09 19:54:37 +08:00 1
涉及到业务的数据计算还是在后端做比较好，这不是因为计算量，而是因为不应该把这些基础数据直接暴露出去。
如果是简单的把 0.9 展示为 90% 的这些倒是可以放在前端处理。 |
 |
25
learnshare 2019-09-09 19:59:26 +08:00
大部分都需要“直接返回”，简单的计算也可以前端做，但通常不给前端这种机会
|
 |
26
luoway 2019-09-09 20:06:37 +08:00
月经帖
前端最好只展示，原因上面讨论有提到 - 多端展示时，改动逻辑只需要改后端 - 业务逻辑变动，不影响展示，只需要改后端 - 前端计算精度、兼容性可能存在问题 事实上，如果前端能用 nodejs 包装一下接口，更合适。 |
 |
27
codermagefox 2019-09-09 20:06:43 +08:00 1
我是前端,我的观点是前端不应该处理任何非展示层逻辑.
如果业务逻辑都放在前端,请问要后端干啥?CRUD 我都帮你写了,你就查个表吗? 之前不懂后端,傻了吧唧的都写了,自己学了后端之后发现,原来很多后端不是不会,也不是不知道应该放在后端,就是懒... |
 |
28
xrr2016 2019-09-09 20:09:56 +08:00 via Android
API JSON 还不出现？
|
 |
29
wanacry 2019-09-09 20:11:44 +08:00 via iPhone
等一个那个男人
|
 |
30
fool079 2019-09-09 20:12:36 +08:00 via Android 1
都可以
不过最好中间层(bff)去做 比如上面提到的 graphql |
 |
31
StarkWhite 2019-09-09 20:14:53 +08:00
@nyaapass 我来替那个蓝人说下，用 apijson， 前端不用写，后端不用等 /狗头
|
 |
32
uTOmOuk3L6sb4MSI 2019-09-09 20:28:17 +08:00 via iPhone
|
 |
33
mamahaha 2019-09-09 20:30:16 +08:00
如果这种事情可以让前端后端商量着来，那这个地方没必要呆了，你在玩命或者在偷懒，老板估计都看不出来。
|
|
34
StarkWhite 2019-09-09 20:42:25 +08:00
@starsriver 如果用的是 REST 等别的方式，那就太理想了，工作量很大，直接 GraphQL 轻松解决
|
 |
35
leopku 2019-09-09 20:54:02 +08:00 via Android
你们这是典型的架构中少了一层
|
 |
36
luozic 2019-09-09 20:55:28 +08:00 via iPhone
网关或者中间层可以玩聚合的
|
 |
37
weixiangzhe 2019-09-09 21:04:27 +08:00 via iPhone
加一层 node 层确实不错
|
 |
38
chenlaocong 2019-09-09 21:08:03 +08:00 via Android
等辣个男人
|
 |
39
wu67 2019-09-09 21:12:44 +08:00
我觉得吧, 设计到‘计算’, 那应该是后端做. 涉及到‘转换’, 那应该是前端做. 除非很复杂或者精度要求, 其实都可以前端做
|
 |
40
lihongjie0209 2019-09-09 21:13:49 +08:00 2
别惯着
假如说一个小程序的组件需要数据结构 A， 一个安卓组件需要数据结构 B， 但是里面的数据都是一样的， 你需要写几个接口？ 简单一点的， 小程序显示 yyyy-MM-dd， 安卓显示 yyyyMMdd， 你要写几个接口？ 至于说小程序或者 APP 需要发版本的问题， 那我后端直接给你返回渲染好的 HTML 如何， 热更新， 不需要发版本。 后端保证数据是对的， 前端出 BUG， 导致显示有问题， 你不想着怎么把前端的 BUG 的修复， 而是想着改后端接口去“兼容”前端的问题， 这叫耦合， 前端和后端的强耦合！！ |
 |
41
reus 2019-09-09 21:17:11 +08:00 3
如果后端也要根据页面来写接口，那还要前后端分离干嘛？
后端只要能提供正交的接口，就是合格的接口。如果前端没有能力做一些计算，那后端额外做了，也可以。 |
 |
42
blessyou 2019-09-09 21:18:38 +08:00 via Android
坚持原则 一个接口做同类的事情
|
 |
43
randm 2019-09-09 21:19:47 +08:00
GraphQL 吧。公司新项目都已经启用了，真香。
|
 |
44
guolaopi 2019-09-09 21:27:23 +08:00
|
 |
45
Rwing 2019-09-09 21:31:32 +08:00
各位 ，有个东西叫 BFF
|
|
46
Rwing 2019-09-09 21:31:56 +08:00
至于这个 BFF 有谁来写，我司是由前端用 node 来写
|
 |
47
areless 2019-09-09 21:33:06 +08:00
https://postgres.rest
http://postgrest.org https://github.com/michelp/pgjwt 续 node 之后，用储存过程完成 token、session……现在还有后端什么事情？ |
 |
48
akira 2019-09-09 21:39:12 +08:00
你们需要一个中间层
|
|
49
guolaopi 2019-09-09 21:41:56 +08:00
每次说到前端有关的话题。最后都会归为”CURD/XXX 用 JS （ node ）也能实现，后端可以裁掉了“。我都觉得瑟瑟发抖，一言不合就会被取缔。
@guolaopi |
 |
50
xfriday 2019-09-09 21:44:50 +08:00
同样一个时间，客户端要根据本地时区显示本地时间，难道要在参数里加请求的时区，让后端转换？有时候觉得少数前端智商有问题
|
 |
51
AngryMagikarp 2019-09-09 21:54:10 +08:00
为什么有人总觉得客户端的任务就是展示呢？诸如 gmail，twitter 这样的网站或者 APP，前端的操作逻辑多了去了。只展示接口数据根本做不出那种效果。twitter 的很多接口还是开放的，反正我是从中看不到任何和展示相关的东西。
也许是我大 a 清 a 自 a 有 a 国 a 情在此。 接口应该按照业务逻辑来给，而不是页面展示。一个页面可能有多个接口，那么可以接口做聚合，也可以客户端自己处理。一个接口的数据可能用在多个页面，不同页面展示甚至可能有所不同，那么客户端需要自己做数据存储流转。 上面吹 GraphQL 的真觉得后端只是增删查改吗？ 中间层也不解决问题，除非前端自己维护中间层。那么他们自己随便怎么写。如果我来维护，我依然有自己的接口原则。不是说中间层就能随便写。 设计后端接口应该从可维护性考虑，有些人说什么需求变了后端改一下就好。改一两次还好，改多了，接口就变成一坨 shit 了。这个时候再让其他人接手，就更糟了。不要为了解决一个小问题引入一个更大的问题。 |
|
52
StarkWhite 2019-09-09 22:03:17 +08:00
@areless 这些只能生成简单的增删改查接口，复杂嵌套的不行，还是 GraphQL 这种天然支持多层嵌套的协议才好办
|
|
53
StarkWhite 2019-09-09 22:04:12 +08:00
@StarkWhite 可以自动聚合数据，前端要啥自己取，要什么结构自己组合，后端也不会被烦了
|
|
54
StarkWhite 2019-09-09 22:06:00 +08:00
@AngryMagikarp GraphQL 提供的 resolver 里面可以处理业务逻辑
|
 |
55
barbery 2019-09-10 09:55:36 +08:00
app 由于上架的问题，后端可以妥协或者弄个中间层来转换数据格式。。。网页端的话，肯定是提供基础数据，前端根据交互和实际需求进行处理
|
 |
56
raynor2011 2019-09-10 10:08:44 +08:00
在游戏开发中，有很多数据都是前端算的，因为同步有时候比计算麻烦多了
|
 |
57
jsq2627 2019-09-10 11:17:32 +08:00 1
@lihongjie0209 #40 前端有一些客观技术 /非技术原因，不能保证发版实时到达，例如小程序 /app 要审核，热更新会有到达率问题，web 端有 js 缓存问题，等等，这时候前端是完全没辙的，只能后端去兼容
现在一般大厂通用原则是前端不做业务逻辑处理，后端吐出什么就显示什么。包括你说的日期问题，也要后端去 format，特别是国际化的场景不是前端能轻易处理的。 那么问题来了，后端去处理这些问题确实很恶心，明明是 UI 界面的事情偏偏要放后端来做。于是才有了 GraphQL，才有了 BFF 和 serverless，让前端人员低成本地写中间层 |
 |
58
Ixizi 2019-09-10 11:33:53 +08:00
给啥显示啥 前端不参与计算
|
 |
59
wly19960911 2019-09-10 12:36:47 +08:00
N 个 api 接口肯定是让后端处理啊。数据的聚合由前端处理拖累性能，不如说这个可以是一个中间层去处理。
|
|
60
reus 2019-09-10 13:02:40 +08:00
说前端不用计算的，说前端给啥显示啥的，就是切图仔一样的角色
切图仔怎么了，对吧？ |
 |
61
zhang77555 2019-09-10 13:46:52 +08:00
现在有一个接口返回一个数组,前端把他渲染成一个表格.
1.现在要显示这个表格某个属性值的求和, 谁来处理? 2.没过多久又要显示另一个属性值求平均,谁来处理? 3.这样类似的表格接口有几十个,都有类似要求,谁来处理? 4.还是这类表格数据量基本在固定几十条,本来只在 PC 端展示,突然要求要上 APP 一页展示 10 条,分页谁来处理? 5.表格数据量随时间增长,做分页,谁来处理? |
 |
62
royzxq 2019-09-10 14:25:10 +08:00
我觉得都可以，看具体需求。
----- btw block 了某位四字母“大神”，总能发表一些奇奇怪怪的言论。 |
 |
63
Yuicon 2019-09-10 14:38:51 +08:00
现在前端也越来越复杂了，不再是以前的切图仔了。我认识的前端朋友跟我说的是很多业务逻辑都被前端抢过去做，话语权也不停的上升，搞得我还有点危机感。
|
 |
64
tiedan 2019-09-10 15:13:52 +08:00
前端只负责展示
|
 |
65
root8080 2019-09-10 16:05:13 +08:00
感觉还是要分复杂程度吧 但是由于这个度的界限很难定义 就开始互相甩锅了
|
 |
66
tt67wq 2019-09-10 16:28:14 +08:00
我们的前端因为不会把 timestamp 转字符串跟我吵了一架你敢信？
|
 |
68
saulshao 2019-09-10 16:52:38 +08:00
这种事情由谁来干其实就一个标准: 谁花的时间少精力少就由谁干.
|
 |
69
MisakaMikoto 2019-09-10 17:14:25 +08:00
服务端就是提供服务的，服务目标给谁？客户端呀！
|
 |
70
dk7952638 2019-09-10 17:20:56 +08:00
就看前后端谁牛逼了，理论来说后端提供统一接口，前端按需对数据进行加工是最合理的
|
 |
71
anan1231230 2019-09-10 17:43:53 +08:00
这事出来结果请通知我一下 [滑稽]
|
 |
72
npe 2019-09-10 17:56:53 +08:00
你就惯着他吧
|
|
73
no1xsyzy 2019-09-10 18:26:55 +08:00
@AngryMagikarp 所以说问题的根源在于笼统地将所有的 “用户端” 称为 “前端”。
仔细检查就可以发现，twitter.com 是基于 Web 技术的 C/S 模式，我认为叫做 WC/S 模式也并无不可。 这和之前 Viaweb 那时候的真· B/S 模式是显著不同的。 更类似边缘计算了。 你什么时候产生了 GraphQL 只能 CRUD 的错觉？ |
 |
74
sdushn 2019-09-10 18:49:49 +08:00
后端吧，前端需要考虑版本兼容问题，实现起来确实不难，但是如果规则有改动，就 gg 了
|
|
76
AngryMagikarp 2019-09-10 21:57:11 +08:00 1
@no1xsyzy 这个说法和“是什么让你产生了 JQuery 不能做单页巨型应用的错觉一样。”当然能做，你就是这么牛逼。
GraphQL 只能算一个规范的中间层，但在这个问题上并不解决任何问题，它不能“自动”地按照产品设计要求给出相应格式的数据，中间的转化总得有人去做。那么问题来了，到底谁去做？ 不要指望用技术弥补人的愚蠢。以前 restful 刚出的时候也一大堆吹嘘，结果真正能用好的没几个。一个系统的设计必然要考虑到可维护性扩展性等等，不能简单地按照谁方便谁做来定。这就是为什么中国的互联网企业和国外的在专业性上相差这么大的根本原因。 功能都能实现，毕竟还有 996 福报加持，但实现得如何那就是另外一回事了。 另外我是做全栈的，我很清楚客户端是怎么回事。也遇到过很多客户端的开发，总是喜欢把一些很简单的东西夸张化（也许在他们的眼里确实很难），好减轻自己的工作，甚至减少自己的责任。有这种想法的团队，我是很难相信能做出多好的产品的。 我不想扯一些具体的情况，因为情况往往是复杂的，不能在这里说清楚。我强调的是一种工程化规范化的做事方式，绝不是简单的客户端只负责展示，也不是全部客户端自己算那么简单。 但一般会按照服务端的方案走，因为他们往往更清楚具体的数据逻辑关系。很多后端开发并不具备这种能力，那是个人问题。 |
|
77
no1xsyzy 2019-09-11 01:13:31 +08:00
@AngryMagikarp jQuery 当然能做好单页巨型应用，并且在恰当的调教下能做得比 Vue 好。模块化、数据驱动、双向绑定，都可以依赖一些插件，但每个都能做到最好。而且对于 Progressive Enhancement 支持更好，比那些一旦自定义元素就直接废了的强。这点上我认为 Svelte （因为标榜自己是编译器所以）本可以做到更好…… 结果没能符合期待。
我还指望编译完成就符合表单交互（为什么会这么指望） 具体到底谁去写，还是 “组织结构决定软件结构”。 我更倾向用技术过滤愚蠢的人…… RESTful 我没能十分钟理解，就说明里面有问题。 最后是这一句让我（感到）完全理解了：“模拟 Unix 文件操作”。那么其优劣就很明显了。Unix 哲学完全看写的人，不然分分钟变 X11，说了等于没说…… 直接做成 HTTP 的 RFC，那就是真的 “什么都没说” 有（明白设计中间层规范的也是经常犯蠢的凡人）这基础，看 GraphQL 的时候就明白很多了。问题也很清晰：比如，多联级容易引入太多重复的数据。Pocket 的接口算是让我直接见识了。因为不信任不同级数据间能保持一致性的关系，我就一直在纠结到底用哪个这一数据。最后还是第二天重构成 dataclass 用 dacite 读取的时候才放弃思考这个问题。 我认为这方面 “工程化规范化的做事方式” 根本不存在。也可能我曾在和现在的组织本来就比较松散有关。 但基本上我觉得这种，要么是架构先拍板，要么就是先随便写，看情况再改。前者在快，后者在可变。 说到底是前后端语言不同的问题，最好是直接传有类型的。为什么要传 timestamp ？直接传 datetime 类型多好？ |
 |
78
icris 2019-09-11 10:06:15 +08:00
『简单的求和』
1. js 数字运算不精确，不存在简单的求和（ 2. 具体应用不了解，如果简单的求和是指数组内属性求和，比如说叫购物车总价，如果后期改动添加分页就不存在前端计算的可能性，服务端计算不正是为了适应复杂多变的需求。 『一个页面如果按前端的说法 可能后端会有 n 多个 API 接口』 不理解，后端聚合只会减少 api |
 |
79
INFP 2021-11-14 06:36:02 +08:00
现在的人都是 nt 吗？后端该给什么数据都要发帖来问？
|
Select Language