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

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

  •  1
     
  •   doommm · 284 天前 · 5906 次点击
    这是一个创建于 284 天前的主题,其中的信息可能已经有所发展或是发生改变。

    前端对接这样的 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
        1
    preach   284 天前
    楼主在北京的话考虑我公司吧 私我简历
        2
    qinrui   284 天前 via iPhone
    说到前后端 api,我又想到了建行网站。建行 web 有个页面,展示了数据 A,而数据 A 是个汇总值,汇总成这个值的明细数据并不需要在 web 上展示。

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

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

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

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

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

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

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


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

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

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

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

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

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

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