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

关于前端工作的一些疑惑

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

    首先呢,我们后端写的 API 太屎了(一年 C#经验,转 Java 了),也就是说,后端给的数据,和前端用户交互的时候产生的数据产生太大的 gap,我每天都在转化数据,把后端来的数据,重新梳理成前端能用的结构。 (当然,和业务本来就很复杂也有关,也不能完全怪后端。)

    老板尚未发现后端 API 太屎,但是他至少认可了这里有很大的 gap,需要我来抹平。

    于是我就想起来了,阿里巴巴据说是利用 nodejs,写中间层,就是聚合各种后端 API,然后封装成一个对前端更友好的 API。

    大概是这样的,可能记忆不太精确。

    所以请教各位,这样的操作是否是常规操作?

    如果是,我就考虑考虑用 nodejs 写个中间层,这样前端的代码会更优雅一些,性能和可维护性应该稍微好一些。

    至于为啥不要求后端写对前端更友好的 API ?原因我就不说了,指望她,还不如指望我自己。 她设计的数据库,我看了一下结构,比鸡窝还乱,但我没说话,毕竟不好对别人的工作指手画脚。

    第 1 条附言  ·  132 天前
    7 楼说的对啊

    用 nodejs 写中间层,会导致甩锅不好甩的问题,和导致 bug 不好定位的问题。
    56 回复  |  直到 2019-04-18 11:15:43 +08:00
        1
    zyEros   132 天前 via Android
    我觉得封装 model service 等类,在内部抹平就行了,没必要上 node
        2
    ericgui   132 天前
    @zyEros 这显然还是要指望后端。。。。
        3
    FEDT   132 天前 via iPhone
    完全可以。
        4
    q8164305   132 天前 via Android   ♥ 2
    前端封装下就好了,没必要上中间层,中间层是为了加快首屏渲染和 seo 的,不是这么玩的
        5
    ericgui   132 天前
    @q8164305 加快首屏渲染倒是比较需要,SEO 不需要。
        6
    azh7138m   132 天前
    我觉得 GraphQLParty 还行,可以看一下之前的记录 https://juejin.im/post/5b29cd2be51d4558d217c644

    其实算一个 BFF 层,但是会好很多(对前端的友好程度)
        7
    blessyou   132 天前 via Android
    所以你打算用 node 吃屎了吗,并且做好面对以后可能会出现不知道是 node 太屎还是他们后端太屎的准备了吗
        8
    ericgui   132 天前
    @blessyou 好吧,你说对了,这确实会是个问题,责任划分的问题。就算不考虑甩锅的问题,debug 定位也不好弄。
        9
    IvanLi127   131 天前 via Android
    只有我不知道什么是 gap,google 还搜不出来吗😂
        10
    NCry   131 天前
    @IvanLi127 我猜测是代沟,不知道对不对
        11
    Dogergo   131 天前
    这种问题当然让后端来搞啊,规范要从一开始就开始执行,数据结构走统一的定义。而且我疑惑的是,不是你要什么数据他给你什么数据么?
        12
    HSvng   131 天前
    GraphQL 了解一下
        13
    daodao116   131 天前
    这个听起来不是前后端的问题,而是系统总体设计的问题。不要为了弥补设计的缺陷去盲目的加入一层。

    还有,想问问现在大家用的 js 后端框架都是什么呀?感觉 node 就是个玩具,其他有什么更好一点的推荐吗?
        14
    alexmy   131 天前
    后端用的 egg.js -> 同构框架 beidou。这就是练手产品 https://www.keylala.cn ,为了简便(实际是云服务器低配),就把后端都移除了,注册登录,redis,mysql 什么的都不要了。
        15
    stillsilly   131 天前
    在前端的 model 层处理 不需要多加个 node ……
        16
    baojiweicn2   131 天前 via Android
    接口屎为啥不怼他.....大家都是同事,凭啥要埋别人的坑
        17
    babedoll   131 天前
    。。没必要

    你只需要告诉后端你要什么数据让他穿就好了,另外一般不是穿 json 类型的吗(挠头)还要什么转换吗
        18
    ben1024   131 天前
    指望她?
    渲染层需要包装数据的
        19
    ianva   131 天前
    后端的 api 会尽量考虑和前端的业务解耦的,所以是必然不适合前端调用的,前端有两个选择:
    一个是前端建模,加一层把后端的 api 映射到前端的模型里,然后前端基于前端的模型去开发具体业务,但问题在于前端要不断维护模型的状态,而且无法夸业务复用模型。
    另一种就是现在比较通用的加一层 BFF ( Backend for Front-End ),BFF 层去聚合后端 API 然后给前端调用,BFF 层的复用性会更高。
        21
    yhxx   131 天前
    是常规操作,但是我觉得除了 KPI 和提升自己之外没什么好处

    为了处理数据,你在浏览器里一样能做

    出问题浏览器里还能调试一下,用 node 搞就只能翻日志了吧
        22
    ianva   131 天前
    另外在现在微服务及面向多终端的背景下,后端的 API 必然不会和前端耦合的,而且前端也会面对不同服务的接口,这种情况下 BFF 是有必要的。
        23
    november   131 天前 via iPhone
    所以大家都知道 gap 是什么意思吗?。。。
        24
    NaVient   131 天前
    在现在服务端背景下后端的数据和前端业务数据有出入是相当正常的吧....
    现在后端提供的是可供多人调用的标准数据,前端根据自己业务整理数据才是“常规操作吧“
        25
    yorkding   131 天前
    @november 隔阂 /嫌隙 很好理解啊。
        26
    abcbuzhiming   131 天前   ♥ 2
    我认真的看了一下,我觉得楼主完全没说清楚为啥叫“接口屎”。因为他给你的数据,必须你在前端再转一遍才能用,所以说屎?那我告诉你,前端转换层从来都是客观存在的,无论你用什么,说的再天花烂坠,转换层一定在某种程度上存在。无非这个工作是你来做还是他来做,他来做,那就要涉及后端的计算资源问题,因为后端资源总是稀缺的,很多中小企业是不愿意付出过多计算资源的,所以这个工作就被转嫁到客户的电脑或者手机上了,因此你以它的数据需要转换才能用就说他屎我觉得是不客观的。后端首先要保证的是可用性,其次是性能,最后才是,能不能让前端绑数据时觉得很开心。至于你说上个 Node,那么又涉及一个问题,多出来的计算资源谁出啊?
    另外楼主已经觉得对方设计的数据库结构跟鸡窝一样,却打算“自己解决”而不主动在会议上提出,作为技术人员,虽然不违反职业道德,但是你不算尽职。有些问题是一定要及时指出的
        27
    november   131 天前
    @yorkding
    看来确实是我英文不好。。。。
        28
    HustLiu   131 天前
    如果不是本身就有一套 node 服务体系,个人建议不要接入……洗数据的事儿,client 做不就完了么,能比放在服务端慢多少?你是打算在 node 层做缓存吗?还是说计算量大到会影响客户端速度?那不就更不适合用 node 来做了……
        29
    whypool   131 天前
    正常操作,没啥喷的

    客户端自己去筛选想要的数据
        30
    zhangalong69   131 天前
    领域驱动设计了解一下
        31
    v2chou   131 天前   ♥ 1
    后端直接 select * from XXX ?
        32
    chairuosen   131 天前
    缺一个前端 model 层
        33
    swaggeek   131 天前
    看需求像是 graphQL
        34
    doommm   131 天前
    我之前在 v2 发过一个类似的问题,对于每项业务我都得写 adapter 来转换请求及响应的数据
        35
    dengshen   131 天前 via iPhone
    可是前端连服务器账户都没有啊!你 node 服务部署在哪呢?
        36
    learnshare   131 天前   ♥ 1
    找人定 API 文档,然后再开发,这样就可以名正言顺要求后端了
        37
    a494836960   131 天前
    见过后端给的接口数据都是 ID 的嘛!想要 name 需要自己查出来在匹配上去
        38
    wenhainan   131 天前
    兄弟啊,我都替你感到憋屈
        39
    randyo   131 天前 via Android
    难道不是前端要什么数据后端给什么数据吗?本来只要很少的数据和简单数据结构,后端直接把整个 dao 层数据结构丢出来,数据乱七八糟,还要你自己去转换,流量也翻了几倍😙😐
        40
    66beta   131 天前 via Android
    你推动下,上 graphql 吧
        41
    duan602728596   131 天前
    我们的网站就是 node 后端获取数据,剔除掉前端不需要的字段,数据去重,格式化数据。不在前端做的原因是为了性能和节省流量,不存在甩锅的问题
        42
    mars0prince   131 天前
    @abcbuzhiming 和计算资源关系不大,本来计算就应该服务端做的,说白了就是这事就是个狗屎活,没有技术长进还麻烦,谁都不愿意做,就看公司是不是愿意用技术解决了,很多公司面对重复工作就只会堆人力
        43
    mars0prince   131 天前
    这个要看你们公司是技术驱动还是业务驱动了,一般业务驱动的公司,基本就无解了,这层对业务没帮助还加了系统复杂度
        44
    ChefIsAwesome   131 天前 via Android
    后端懒而已。你跟他讲 graph ql 他也不会愿意搞。老老实实前端转下数据就行了,能多费性能。
        45
    IvanLi127   131 天前 via Android
    我之前也是这样。。后面合作的项目我给他们写了 api 文档。。纯手敲 md,加上他们对我能力还算比较相信。第三个项目后 api 就好些了,不过还是有点不整洁。
    现在,我是一名后端工程师了。
        46
    ericgui   131 天前
    @mars0prince 小型物流公司,所以没有所谓技术驱动。后端就一个人,还是一年 C#转来写 Java 的,因为老板觉得 Java 和 Oracle 数据库配合的更好。。。。。

    所以我其实很无奈的。
        47
    ericgui   131 天前
    @ChefIsAwesome 不仅是懒,她还觉得自己牛逼得不行。
        48
    ericgui   131 天前
    @wenhainan 谢谢老铁
        49
    ericgui   131 天前
    @IvanLi127 先写 API 文档是可行的,但要求对业务有了解。

    所以呢,我们只能走一步看一步,因为 6 个月前,整个团队对业务部门具体有什么需求,了解几乎为零。
        50
    Sain   130 天前
    争取成为全栈
        51
    mars0prince   130 天前
    @ericgui 那就赶紧走吧,业务型驱动公司就是这样,尽自己最大能力吧
        52
    yiyi11   130 天前
    @ericgui #47 确实🐮🍺啊,一个人扛起后端,至于质量就另说了。
        53
    ericgui   128 天前
    @yiyi11 是的,前端就一个我,后端也就是一个人,还是个 1 年 C#转 Java,我也无 fuck 可说的。
        54
    ericgui   125 天前
    @ianva 才看到老铁这个文章,感谢啊,正在读,写的非常好!
        55
    ianva   124 天前
    @ericgui BFF 层可以考虑 graphql,GraphQLParty 有两个技术分享很不错可以参考
    https://juejin.im/post/5b29cd2be51d4558d217c644
    https://juejin.im/post/5b32f27ae51d4558b277992b
        56
    ericgui   124 天前
    @ianva 感谢老铁,我研究一下
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   880 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 22ms · UTC 20:33 · PVG 04:33 · LAX 13:33 · JFK 16:33
    ♥ Do have faith in what you're doing.