V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
doommm
V2EX  ›  程序员

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

  •  1
     
  •   doommm · 2019-01-03 23:38:01 +08:00 · 8030 次点击
    这是一个创建于 1910 天前的主题,其中的信息可能已经有所发展或是发生改变。

    前端对接这样的 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"
    },
    // ...
    
    • A0001, A0002 这些都是实际的字段名,也是数据库的列名,有一张 Excel 的对照表可以查字段的含义。前端需要哪些列的值,就把相应列的 code 作为请求的参数传给后台

    • 后台返回格式不一致(宽表、窄表两套格式)。

    • 不同的首字母表示不同的表,对应的字段需要 post 到不同的 API。比如 AXXXXBXXXX 要分别给到api/a, api/b两个接口。

    • 一项业务存在使用多张表的数据的情况,前端需要自己来做数据聚合

    • 根据业务需要,前端要对部分返回结果做过滤 /分类 /计算

    • 同一项指标的不同选项(比如留存,有 3 日、7 日、14 日等选项可选)会对应不同的 code,前端需要区分发送。目前我用表驱动法维护了很多这类的 mapping。

    考虑的问题

    • 业务逻辑的维护

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

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

    • Ajax 请求数量

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

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

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


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

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


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

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

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

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

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

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

    然后越做越觉得难,想说是不是哪里做的不对,就又来发帖请教了。
    doommm
        21
    doommm  
    OP
       2019-01-04 09:53:20 +08:00
    @preach 谢谢老哥。人在厦门,暂时不考虑北京。再次感谢。
    doommm
        22
    doommm  
    OP
       2019-01-04 09:54:59 +08:00
    @qinrui
    产品还就是从建行出来的。。这个项目里面也有类似的需求需要这样实现。。
    dany813
        23
    dany813  
       2019-01-04 10:00:40 +08:00
    这个设计真牛逼,要是我立马就开怼
    183shl
        24
    183shl  
       2019-01-04 10:26:17 +08:00 via Android
    我见过查询用户信息把 passwd 也返回的
    daimen
        25
    daimen  
       2019-01-04 10:42:00 +08:00
    BQID。。。 哈哈哈哈哈哈哈哈哈
    yepinf
        26
    yepinf  
       2019-01-04 10:49:56 +08:00
    @preach 哈哈哈

    这么干脆~ 有没有上海的
    preach
        27
    preach  
       2019-01-04 10:52:07 +08:00   ❤️ 2
    @yepinf 救人要緊
    tosmq009
        28
    tosmq009  
       2019-01-04 11:02:08 +08:00   ❤️ 1
    如果考虑到字段加密来说,我觉得可以考虑 你们的设计,如果直接放到物理数据库,我只能说。。。。
    这水平太差了,还活在 10 多年前的 世界,可维护性,可读性,都是垃圾

    个人建议,找技术老大提问题,如果大家都不是好好做事的心态的话,赶紧找下家,不然工作水平提不上去,心态还各种纠结。


    数据库设计,最近很火的是,领域驱动设计,或者最简单的

    能准确表达。
    vivachencs
        29
    vivachencs  
       2019-01-04 11:05:50 +08:00
    上家公司后端也是这么干的, 数据统计全是我前端在做, 完事还要说: "你看我接口写得多灵活, 你想要什么数据都可以自由组合, 性能还这么好", 然后我现在跑路整一年了
    519718366
        30
    519718366  
       2019-01-04 11:21:58 +08:00
    我们这边前后分离奉行的原则是:能后端处理的,就不交给前端。

    比如前端的某个状态要根据 2,3 个属性综合判断,那后端基本就把这个状态计算好了返回。

    前端就塞塞值,换换文案,多搞搞交互样式代码。

    你这种字段设计绝对不是个例,我一个做过社保项目的同学也是你这样的,他说后端数据库是专门有一张字典表的。
    这个表说明了 A00001 表示什么意思,一般值什么的~~所以你前端也搞个字典?
    Ritr
        31
    Ritr  
       2019-01-04 11:38:02 +08:00
    后端返回的数据不一定符合前端的需求,当前端页面展示变更的时候,后端也不一定跟着变更。
    我的建议是使用一个中台系统来整合、梳理这些数据。
    如果没有时间和精力做这个事情,可以考虑在前端 /后端加个适配器处理数据,保证数据输出的格式符合你的需求
    "3 人团队,1 产品 + 1 后端 + 1 前端" oh ...shit,还是随便搞搞吧
    kela
        32
    kela  
       2019-01-04 12:12:22 +08:00 via Android
    @qinrui 我以为要两开花
    doommm
        33
    doommm  
    OP
       2019-01-04 12:55:52 +08:00
    @dany813 试用期,怕是怼不动
    mynameisz
        34
    mynameisz  
       2019-01-04 13:18:37 +08:00 via iPhone
    劝楼主,苦海无涯,回头是岸!
    shyangs
        35
    shyangs  
       2019-01-04 13:25:12 +08:00
    壮哉大前端, JavaScript 必将统一世界
    atonku
        36
    atonku  
       2019-01-04 13:28:43 +08:00
    我也像写这样的接口,但是我怕会被领导打死。这尼玛写的是个屁哦
    bojackhorseman
        37
    bojackhorseman  
       2019-01-04 14:08:11 +08:00
    @MonoLogueChi #4 233
    SakuraKuma
        38
    SakuraKuma  
       2019-01-04 14:12:00 +08:00
    自己架中间层,写 mapping,转换回自己要的格式。就不用暴露字段前端又好写点了。
    ChenFanlin
        39
    ChenFanlin  
       2019-01-04 14:23:26 +08:00
    ..我记得之前在 v2?还是 nga?看到过有个帖子也是这样的命名...同一家公司吗...
    yzkcy
        40
    yzkcy  
       2019-01-04 14:57:33 +08:00
    后端把表里所有数据全传到前端,让前端自己处理,会产生很严重的安全问题的。

    比如查询 XX(前端只需要 XX 的某个值),后端却把 XX 的所有数据(包括敏感信息)全返回了。
    rasck
        41
    rasck  
       2019-01-04 15:12:41 +08:00
    怎么不直接传 sql 语句 23333
    rasck
        42
    rasck  
       2019-01-04 15:13:34 +08:00
    @ChenFanlin 我也以为碰见同一家公司了,仔细看下楼主说了上个月发过帖子问过了
    jinhan13789991
        43
    jinhan13789991  
       2019-01-04 15:19:57 +08:00
    让后端给你数据库地址和密码,自己直连数据库。
    ChenFanlin
        44
    ChenFanlin  
       2019-01-04 15:20:20 +08:00
    @rasck #42 多谢, 眼瞎了....,那确实也算是同一家公司了
    reself
        45
    reself  
       2019-01-04 15:20:54 +08:00 via Android
    不给映射表做个鸡巴,这后端已经不是懒了,完全没有团队意识
    stzz
        46
    stzz  
       2019-01-04 15:32:14 +08:00
    这种设计要后端干嘛,和直接传 SQL 语句有啥区别
    yamamotoahua
        47
    yamamotoahua  
       2019-01-04 15:36:22 +08:00
    @chniccs 前端=设计稿具现化工具? 233
    auroraccc
        48
    auroraccc  
       2019-01-04 15:39:42 +08:00
    按照你们这个后端和项目负责人的性格,不要想 graphql 了,这个需要后端配合的
    doommm
        49
    doommm  
    OP
       2019-01-04 17:05:15 +08:00
    @ChenFanlin 同一家公司
    doommm
        50
    doommm  
    OP
       2019-01-04 17:07:52 +08:00
    @tosmq009

    公司将近 100 人,按产品组分的。这个项目组是单独一个小组,产品直接对老板负责,前端没有技术老大
    lolizeppelin
        51
    lolizeppelin  
       2019-01-04 17:11:14 +08:00
    让不让看后端代码? 让看 看完再喷呗
    noe132
        52
    noe132  
       2019-01-04 17:56:27 +08:00
    比我之前待的公司 api 接口从 function001 到 funtion152 还是强一点。。。
    传个二维数组,用逗号分隔后再用分号分隔连接成字符串传给后端
    后端再存储过程里再去解析出来。。。
    doommm
        53
    doommm  
    OP
       2019-01-04 20:14:12 +08:00 via Android
    @reself …所以是要赶紧跑路吗
    qinrui
        54
    qinrui  
       2019-01-04 22:56:03 +08:00 via iPhone
    @doommm 而且建行这个页面,api 吐出的 json 格式还不符合规范,真的烂
    947211232
        55
    947211232  
       2019-01-05 00:16:25 +08:00
    这么有诗意的规范实在令人倍感无力。
    dapang1221
        56
    dapang1221  
       2019-01-05 00:22:54 +08:00
    感觉吐槽这种字段名的帖子已经挺多了,等保要求里好像的确是有这个加密要求,规定如此……
    kingcos
        57
    kingcos  
       2019-01-05 00:28:21 +08:00 via iPhone
    我比较奇怪的一点是,微服务微服务,应该是针对后端的逻辑,前端需要什么东西就不能组装一下吗…难道后端微服务,前端就要一次性调四五个接口才能拿到所有需要的数据,这样割裂的,是微服务的锅?
    Lindp
        58
    Lindp  
       2019-01-05 10:40:14 +08:00
    我相信大部分公司应该都是前端是大爷,后端应该准备好所有数据给前端服务,而且还要是前端最简单的实现方式,毕竟数据还是后端处理起来方便嘛
    Gakho
        59
    Gakho  
       2019-01-05 10:42:00 +08:00
    @kingcos 微服务 API 网关了解一下
    doommm
        60
    doommm  
    OP
       2019-01-06 00:08:31 +08:00
    所以真的没有什么建议吗
    doommm
        61
    doommm  
    OP
       2019-01-07 00:00:43 +08:00
    @Ritr 随便搞搞是说先把项目搞出来,其它什么的暂时就别考虑了么
    Ritr
        62
    Ritr  
       2019-01-07 10:18:10 +08:00
    @doommm 先跑起来吧,看着也不是大项目
    doommm
        63
    doommm  
    OP
       2019-01-14 21:07:37 +08:00
    @Ritr 跑起来了,现在产品要我去翻旧版项目( PHP, jQuery ),把新旧两套数据库字段的对照关系整理给他,他好做迁移,这要怎么搞?
    Ritr
        64
    Ritr  
       2019-01-15 09:47:36 +08:00
    @doommm 这后端也太懒了吧,我晕,你让自己整理对照关系呗
    doommm
        65
    doommm  
    OP
       2019-01-15 12:51:17 +08:00
    @Ritr 职级比我高怎么解呢,我是真的在考虑趁还在试用期赶紧离职。。。
    Ritr
        66
    Ritr  
       2019-01-15 13:13:26 +08:00
    @doommm 那就等过完年跑路吧
    serge001
        67
    serge001  
       2019-06-09 23:16:57 +08:00
    @doommm 想请教下最后怎么解决的呢?我的想法是统一在请求层 map 处理一下
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3662 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 10:43 · PVG 18:43 · LAX 03:43 · JFK 06:43
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.