后端给前端应该提供什么样的数据?

2019-09-09 18:56:58 +08:00
 tourist2018

这几天和前端同事对接,遇到一些分歧。 前端同学认为我应该把页面每项数据都用 API 直接返回,前端拿到的就是直接可用的。 我认为我提供一些基础数据就可以了,除非特别复杂的逻辑,前端可以通过一些简单的计算得到自己的要求(计算量并不大,我看了下就是简单的求和之类的)。

因为前端的需求比较复杂多变,我在了解需求的情况下,提供现阶段基础数据就可以,具体怎么计算由前端负责。大家觉得呢?(惭愧之前虽然是后端,但一直做 infra 的工作,没有怎么做过 API 方面的对接)

备注: 一个页面如果按前端的说法 可能后端会有 n 多个 API 接口 目前暂时使用前端做法

10138 次点击
所在节点    程序员
79 条回复
reus
2019-09-09 21:17:11 +08:00
如果后端也要根据页面来写接口,那还要前后端分离干嘛?
后端只要能提供正交的接口,就是合格的接口。如果前端没有能力做一些计算,那后端额外做了,也可以。
blessyou
2019-09-09 21:18:38 +08:00
坚持原则 一个接口做同类的事情
randm
2019-09-09 21:19:47 +08:00
GraphQL 吧。公司新项目都已经启用了,真香。
guolaopi
2019-09-09 21:27:23 +08:00
@reus
赞同,
每次说到前后端分离的开发就跟我说什么工程化,
稍微涉及到一点逻辑的就是后端偷懒。
合着工程化就是多个 HTML 拆成多个 Components 呗?
Rwing
2019-09-09 21:31:32 +08:00
各位 ,有个东西叫 BFF
Rwing
2019-09-09 21:31:56 +08:00
至于这个 BFF 有谁来写,我司是由前端用 node 来写
areless
2019-09-09 21:33:06 +08:00
https://postgres.rest
http://postgrest.org
https://github.com/michelp/pgjwt
续 node 之后,用储存过程完成 token、session……现在还有后端什么事情?
akira
2019-09-09 21:39:12 +08:00
你们需要一个中间层
guolaopi
2019-09-09 21:41:56 +08:00
每次说到前端有关的话题。最后都会归为”CURD/XXX 用 JS ( node )也能实现,后端可以裁掉了“。我都觉得瑟瑟发抖,一言不合就会被取缔。
@guolaopi
xfriday
2019-09-09 21:44:50 +08:00
同样一个时间,客户端要根据本地时区显示本地时间,难道要在参数里加请求的时区,让后端转换?有时候觉得少数前端智商有问题
AngryMagikarp
2019-09-09 21:54:10 +08:00
为什么有人总觉得客户端的任务就是展示呢?诸如 gmail,twitter 这样的网站或者 APP,前端的操作逻辑多了去了。只展示接口数据根本做不出那种效果。twitter 的很多接口还是开放的,反正我是从中看不到任何和展示相关的东西。

也许是我大 a 清 a 自 a 有 a 国 a 情在此。

接口应该按照业务逻辑来给,而不是页面展示。一个页面可能有多个接口,那么可以接口做聚合,也可以客户端自己处理。一个接口的数据可能用在多个页面,不同页面展示甚至可能有所不同,那么客户端需要自己做数据存储流转。

上面吹 GraphQL 的真觉得后端只是增删查改吗?

中间层也不解决问题,除非前端自己维护中间层。那么他们自己随便怎么写。如果我来维护,我依然有自己的接口原则。不是说中间层就能随便写。

设计后端接口应该从可维护性考虑,有些人说什么需求变了后端改一下就好。改一两次还好,改多了,接口就变成一坨 shit 了。这个时候再让其他人接手,就更糟了。不要为了解决一个小问题引入一个更大的问题。
StarkWhite
2019-09-09 22:03:17 +08:00
@areless 这些只能生成简单的增删改查接口,复杂嵌套的不行,还是 GraphQL 这种天然支持多层嵌套的协议才好办
StarkWhite
2019-09-09 22:04:12 +08:00
@StarkWhite 可以自动聚合数据,前端要啥自己取,要什么结构自己组合,后端也不会被烦了
StarkWhite
2019-09-09 22:06:00 +08:00
@AngryMagikarp GraphQL 提供的 resolver 里面可以处理业务逻辑
barbery
2019-09-10 09:55:36 +08:00
app 由于上架的问题,后端可以妥协或者弄个中间层来转换数据格式。。。网页端的话,肯定是提供基础数据,前端根据交互和实际需求进行处理
raynor2011
2019-09-10 10:08:44 +08:00
在游戏开发中,有很多数据都是前端算的,因为同步有时候比计算麻烦多了
jsq2627
2019-09-10 11:17:32 +08:00
@lihongjie0209 #40 前端有一些客观技术 /非技术原因,不能保证发版实时到达,例如小程序 /app 要审核,热更新会有到达率问题,web 端有 js 缓存问题,等等,这时候前端是完全没辙的,只能后端去兼容

现在一般大厂通用原则是前端不做业务逻辑处理,后端吐出什么就显示什么。包括你说的日期问题,也要后端去 format,特别是国际化的场景不是前端能轻易处理的。


那么问题来了,后端去处理这些问题确实很恶心,明明是 UI 界面的事情偏偏要放后端来做。于是才有了 GraphQL,才有了 BFF 和 serverless,让前端人员低成本地写中间层
Ixizi
2019-09-10 11:33:53 +08:00
给啥显示啥 前端不参与计算
wly19960911
2019-09-10 12:36:47 +08:00
N 个 api 接口肯定是让后端处理啊。数据的聚合由前端处理拖累性能,不如说这个可以是一个中间层去处理。
reus
2019-09-10 13:02:40 +08:00
说前端不用计算的,说前端给啥显示啥的,就是切图仔一样的角色
切图仔怎么了,对吧?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/599400

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX