Home Sign Up Sign In
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
ericgui
V2EX  ›  程序员

关于前端工作的一些疑惑

  •   
  •   ericgui · Apr 11, 2019 · 6842 views
    This topic created in 2765 days ago, the information mentioned may be changed or developed.

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

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

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

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

    所以请教各位，这样的操作是否是常规操作？

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

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

    Supplement 1  ·  Apr 11, 2019
    7 楼说的对啊

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

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

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

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

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

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

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

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

    所以呢，我们只能走一步看一步，因为 6 个月前，整个团队对业务部门具体有什么需求，了解几乎为零。
    Sain
    Sain
    Apr 12, 2019
    50
    争取成为全栈
    mars0prince
    mars0prince
    Apr 12, 2019
    51
    @ericgui 那就赶紧走吧，业务型驱动公司就是这样，尽自己最大能力吧
    yiyi11
    yiyi11
    Apr 12, 2019
    52
    @ericgui #47 确实🐮🍺啊，一个人扛起后端，至于质量就另说了。
    ericgui
    ericgui
    OP
    Apr 15, 2019
    53
    @yiyi11 是的，前端就一个我，后端也就是一个人，还是个 1 年 C#转 Java，我也无 fuck 可说的。
    ericgui
    ericgui
    OP
    Apr 18, 2019
    54
    @ianva 才看到老铁这个文章，感谢啊，正在读，写的非常好！
    ianva
    ianva
    Apr 18, 2019
    55
    @ericgui BFF 层可以考虑 graphql，GraphQLParty 有两个技术分享很不错可以参考
    https://juejin.im/post/5b29cd2be51d4558d217c644
    https://juejin.im/post/5b32f27ae51d4558b277992b
    ericgui
    ericgui
    OP
    Apr 18, 2019
    56
    @ianva 感谢老铁，我研究一下
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   1281 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 164ms · UTC 21:14 · PVG 05:14 · LAX 13:14 · JFK 16:14
    ♥ Do have faith in what you're doing.