前端对接这样的 API ,各位老哥有什么建议吗

2019-01-03 23:38:01 +08:00
 doommm

前端对接这样的 API,各位老哥有什么建议吗

先说一下项目背景

互联网公司,做自己的产品,全新的统计项目。3 人团队,1 产品 + 1 后端 + 1 前端。

项目负责人(产品)是从银行出来的,和后端一起设计、维护数据库,制定了前后端 API。

上个月就 API 字段命名方式我提过一个问题( https://www.v2ex.com/t/514030)

后续和负责人沟通的结果是:API 和字段名没有改变的可能,没有、也不会提供什么字段表,不好做就自己想办法。

当时大家建议去做 mapping,因为各种原因,目前我只把这些 code 全部变量化,加上 JSDoc,并且所有跟这些 code 相关的代码都单独用TypeScript来写。

目前页面已经写完了,用的 Vue + echarts,数据目前都是我本地 Mock 的,因为 API 给的晚,Mock 的格式没有和实际完全对应。

API 示例

// request params
// 请求 A 表这些字段,post to api/a
{
  "date_start": "2019-1-1",
  "date_end": "2019-1-3",
  "id": "v2ex",
  "cols": "A0001,A0002,A0003,A0004..." 
}
// B 表,post to api/b
{
  "date_start": "2019-1-1",
  "date_end": "2019-1-3",
  "id": "v2ex",
  "cols": "A0001,A0002,B0001,B0002..." 
  // ...
}
// ...

// 前端请求哪些字段,后端就只返回这些字段的数据
// 部分字段通用
// 返回数据格式区分宽表、窄表

// 宽表返回格式
{
  "A0001": "2019-1-1", // date,通用
  "A0002": "v2ex", // id,通用
  "A0003": "1",
  "A0004": "1",
  // ...
}

// 窄表返回格式
{
  "A0001": "2019-1-1",
  "A0002": "v2ex",
  "INDEXID": "F0001"
  "INDEXV": "1"
},
{
  "A0001": "2019-1-1",
  "A0002": "v2ex",
  "INDEXID": "F0002"
  "INDEXV": "1"
},
// ...

考虑的问题

目前我针对每一项具体业务写了 Adapter ,用来管理要发送的数据列,以及返回数据的转换处理工作 。

感觉项目中用的最多的就是 Array.map, Array.reduce 这两个方法。。UI 的文本、各种选项下对应的请求字段、各种图表数据都跟那些 code 做了对应。很怕以后维护的时候看不懂。

目前各个业务模块的请求是单独发送的(一个页面多个模块),一次刷新 devtool 里面各种 abcdef 的请求,如果存在跨表的业务(Promise.all 等待)就有更多。等浏览器排队走完。

目前后台数据还不完善,很多返回值都是 null,速度还无法评估。

请问前端目前这样处理有没有什么问题?听说过 GraphQL, 不知道是不是可以解决这类问题?不过估计也没有用的机会。


还想问问各位老哥,前端对接这样的接口,有没有什么好的做法?有没有什么坑是需要注意的?

另外,因为以前只做过后端给大接口(聚合了目标业务需要的所有数据)的项目,想问问这样的接口算不算 RESTful ? 后端 API 这样设计,是不是后续只要负责往数据库里面填数据就可以了?


试用期还有一个月,做的好心累,感觉自己好菜

8077 次点击
所在节点    程序员
67 条回复
preach
2019-01-04 01:45:04 +08:00
楼主在北京的话考虑我公司吧 私我简历
qinrui
2019-01-04 03:08:39 +08:00
说到前后端 api,我又想到了建行网站。建行 web 有个页面,展示了数据 A,而数据 A 是个汇总值,汇总成这个值的明细数据并不需要在 web 上展示。

但大方的建行,将全部明细数据都通过 api 吐给了前端,前端通过 js 汇总再显示出来。

真真的体会了前后端“分离”
kltt22
2019-01-04 07:24:46 +08:00
我公司前端和客户端是块宝,后端写接口都要考虑前端好不好实现。不好实现的,后段就再加工下。感觉后端处理数据还是方便些。
MonoLogueChi
2019-01-04 07:55:57 +08:00
我想到了,我给别人做后端,有个只有几十行数据的表,我都想不管他怎么查,我直接把整个表返回给他,让他自己在前端去做处理。后来想想算了,没敢跟他说,怕被打死,老老实实的去做正常 API 了
duan602728596
2019-01-04 08:04:06 +08:00
不能跨表查询,那还要后端和数据库干毛线?我这个半吊子都能对付写个查询把数据查出来
Akiyu
2019-01-04 08:09:37 +08:00
@kltt22
主要是后端经常干这些事情, 比较熟练
shew2356
2019-01-04 08:13:37 +08:00
那前端还不如自己全部搞定得了
MonoLogueChi
2019-01-04 08:14:59 +08:00
@kltt22 我也感觉后端处理和加工数据比较简单,但是为了性能时候,这些应该是前端做的
MrUser
2019-01-04 08:18:21 +08:00
能力太低,看不透,问下,如果那个“ Excel ”泄漏了,你们这不是白折腾吗
加密有很多方法和适用场景,这样写莫不是要把所有加密方法方式都用上?
这个规范加上后端那样的接口,如果他们不改,我是不会呆下去了
reus
2019-01-04 08:49:00 +08:00
垃圾后端,这都能忍,屎都能吃了。
chniccs
2019-01-04 08:54:59 +08:00
这?是让你做全栈?后端=数据库连接工具?
jrtzxh020
2019-01-04 09:00:36 +08:00
那后端所有数据都 select * from xx_table 得了。然后给前端自己处理,哈哈
drydiy
2019-01-04 09:01:52 +08:00
GraphQL 是要前后端一起配合的。
一般情况下,人少的团队最好配合的,没什么历史包袱,分歧也少。
你们 3 人团队搞成这样,不觉得恶心??
lihongjie0209
2019-01-04 09:08:07 +08:00
瞎搞
ytmsdy
2019-01-04 09:12:14 +08:00
假如后端走了,新来接手的后端会一脸懵吧。
90d0n
2019-01-04 09:12:38 +08:00
这后端写的真轻松啊, 找个模板一键生成接口就行了...
同 11 楼, 这后端完全就是个数据库连接工具... 还是只查单表的
julio867
2019-01-04 09:14:19 +08:00
听说银行的系统的命名方式都是类似的~~之前做过中小企业的 C/S 管理软件,字段命名也是类似,不能说不好,只能说看团队和项目情况~~
个人一直认为的是,API 接口返回的数据,应该仅仅是调用者需要的,而不是把所有数据都扔给调用者,否则后端就真的是“数据库连接工具”了(当然,这个可能对于某些项目不一定是合适的)~~
yikyo
2019-01-04 09:14:41 +08:00
相信我,换个工作吧,别忍着了。
xpol
2019-01-04 09:14:44 +08:00
GraphQL 挺好的,可以研究一下。
doommm
2019-01-04 09:46:10 +08:00
@drydiy

一开始肯定不能接受,所以才有上个月发的那帖,当时只知道大概的数据格式,还没有 API。

当时有老哥说见过这种格式,这样的字段命名方式是有原因的,我就尝试去接受,想法子来做了。

然后越做越觉得难,想说是不是哪里做的不对,就又来发帖请教了。

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

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

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

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

© 2021 V2EX