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

都 9102 年了,大家有没有用上 Facebook 出的 GraphQL ?

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

    突然发现 v2 首页有两个阿里招聘贴,并且都有提到 Facebook 开源的 GraphQL。

    阿里云 2020 校招内推,光速面试流程
    (通过类 GraphQL+Serverless 实现接口聚合,减少前后端沟通成本)
    https://www.v2ex.com/t/587238

    [阿里巴巴秋招] 飞猪用户技术,免笔试极速内推!可查进度
    (参与端领域开源技术建设:Nodejs / Graphql / Serverless )
    https://www.v2ex.com/t/588764

    去年 Linux 基金会成立了 GraphQL 基金会,今年亚马逊 AWS 宣布加入
    https://aws.amazon.com/cn/blogs/china/aws-joins-the-graphql-foundation/

    掘金、简书 上也有频繁发布的大量 GraphQL 各种相关博客
    https://juejin.im/tag/GraphQL
    https://www.jianshu.com/search?q=GraphQL

    GitHub 上各种语言的开源实现都有了,Star 数基本都挺高。
    https://github.com/search?q=graphql

    V 站、知乎、技术群等也有很多关于 GraphQL 的讨论,看起来 GraphQL 已经是一个大趋势了。
    https://graphql.org/
    https://graphql.cn/
    https://graphql.org.cn/

    那么问题来了,都 9102 年了,大家有没有用上 Facebook 出的 GraphQL ?

    135 回复  |  直到 2019-11-20 10:59:58 +08:00
    1  2  
        1
    StarkWhite   131 天前
    拉勾上好像也有很多要求会 GraphQL 的岗位了
        2
    darknoll   131 天前
    有没有啥资料让我学一下?
        3
    Cabana   131 天前 via Android
    还之前记得有个 v 友自己写的类似的框架不知现在咋样了
        4
    yiyi11   131 天前 via Android   ♥ 21
    那个男人,会来吗?
        5
    monkingame   131 天前
    用了,但没有 dart 的支持,暂时搁置了
        6
    VDimos   131 天前
    @yiyi11 看来都有被那个男人支配的恐惧
        7
    agdhole   131 天前
    那个男人,多久来呢
        8
    zqx   131 天前 via Android
    无数以聚合数据为无数的 node 项目都要重构了?
        9
    yedanten   131 天前 via Android
    并不觉得好用
        10
    DAPTX4869   131 天前
    @VDimos #6 萌新问下,是谁?
        11
    henyi2211   131 天前
    不觉得好用 +1
        12
    zjsxwc   131 天前
    GraphQL 其实还不如“古老”的结构化查询语言 SQL (Structured Query Language) 来的方便
        13
    chendy   131 天前
    并不觉得好用
        14
    whitehack   131 天前
    并不觉得好用
        15
    MrKou47   131 天前 via iPhone
    辣个男人还没有现身
        16
    myyou   131 天前   ♥ 1
    我来代替辣个蓝人发言,个人认为 apijson 要好于 GraphQL
        17
    IsaacYoung   131 天前
    我以为香蕉君呢
        18
    PDX   131 天前
    这种技术就是“可以有,但是没必要”,不要轻易尝试。
        19
    source   131 天前
    @IsaacYoung #17 v2 香蕉君
        20
    VDimos   131 天前 via Android
    @DAPTX4869 为 apijson 代言的男人
        21
    hirasawayui   131 天前
    我们.net 后端用上了
        22
    razertory   131 天前
    没错,完爆 GraphQL ...
        23
    wiix   131 天前   ♥ 1
    GraphQL 无非就是把后端当数据库用,把前端当后端用而已。还隐藏了调用数据库的实现。企图革 SQL 的命但毫无希望。
        24
    Caballarii   131 天前
    GraphQL 革的是 REST 的命啊,为啥上面说革 SQL 的命???
        25
    xuyl   131 天前
    很多人都不愿尝试改变,RESTful 还没普及,GraphQL 还有待时日
        26
    razertory   131 天前   ♥ 2
    我们实践了两年 GraphQL。。。总体的感受实际上是后端会花更多的心思在设计 schema 上,前端是要自己写 GraphQL 代码,但是因为强类型 + 固定返回数据结构的模式下。可以很放心地 call api 而不必处理很多恶心的边界条件,当然 API 文档。。。你懂的,为啥要写文档呢
        27
    abcbuzhiming   131 天前
    我坚信自己没看错,这东西的好处在前端,锅要后端背,最重要的是这东西增加了成本,所以这玩意没戏。大公司可以靠强推火几年,中小型公司你根本推不下去
        28
    passerbytiny   131 天前
    如果数据模型还要后端定义,那么 GraphQL 模式并不比 RESTful 模式省成本,更因为取消了中间层大大降低灵活性。
    如果完全不要后端,那么成本有可能降低,但前端铁定要骂娘。而且这种模式也不是啥新模式,这就是以前的 C/S 模式,只不过 C 端从 VB、C#变成了 Javascript。

    楼主你列举的这些例子,看起来都虚的很,就像某大 V 推荐了一个牛逼东西一样。该关键字在(划重点:中立)搜索引擎上大红——这代表了真正有很多人在用或者在学习它,才能表示发展趋势良好。
        29
    passerbytiny   131 天前   ♥ 2
    多看了下楼主的主页,竟然发现是之前问“ Java 为什么不能热部署的”的作者。楼主如果不是编程初学者,则不需要看我后面的话。如果是,建议还是踏实点,从 Java、Javascript、SQL 的基础学起,不要搞 apijson、play、GraphQL 这些快速开发但高度封装(并隐藏细节)的工具。
        30
    wentaoliang   131 天前
    尝试了几次,前端是用的爽了,后端一点都不爽,要知道大部分时候都是后端说了算。
        31
    lolizeppelin   131 天前
    好像 openstack 里 fileds 的用法...
        32
    finian   131 天前   ♥ 2
    在生产环境用了几年了,真香。楼上那些带着偏见的、搞不清概念的,建议用用再发表高见吧。还革 SQL 的命。。。先把人家是用来干嘛的搞清楚吧
        33
    winglight2016   131 天前
    @finian 好多人明显没有用过,批评都没批评到点子上
        34
    icy37785   131 天前 via iPhone
    并不好用+10086
        35
    wszgrcy   131 天前 via Android
    去年用的 nestjs+graphql,还要
        36
    nyaapass   131 天前
    辣个男人居然还没有来
        37
    libook   131 天前
    没有银弹
        38
    zjsxwc   131 天前 via Android
    说通俗一点,graphql 对于后端来说该写的接口还是要写,上了 graphql 后,后端的每个接口,变成了类似数据库表资源的存在,于是前端可以写出等价于 sql 的查询语句:

    “ SELECT apiXXX1 WHERE arg1=aaaa AND arg2=bbbbb; SELECT .....”

    等价于

    {result1:apiXXX1(arg1:aaaa, arg2:bbbbb), result2: apiXXX2......}



    前端同学的需求痛点是
    1. graphql 可以一个请求完成对原先多次请求的查询,这样就不用 promise 等异步处理了。

    但一般来说后端不用 graphql 也能做到一次请求性合并处理多个接口请求,无非是加一个循环而已。


    2. graphql 可以通过 schema 约定接口请求与返回的强参数类型。

    这个其实前后端本来就能通过接口文档的形式约定,原本是程序员基本素养问题,现在通过强制代码编写约定,我觉得可以提倡,但不少人会不乐意写因为麻烦。

    3. graphql 可以过滤掉不需要的字段,减少网络带宽。

    虽然减少网络带宽,但服务器查询执行业务的消耗仍旧不变,而且对于大部分业务来说,前端获取的数据越多越好,很少有人会为了省那点带宽干这事情。
        39
    xingyue   131 天前 via Android
    说辣个男人的都是在脑子里建了用户表么 233333~我看到第二个回复才反应过来看来我的索引待优化 TAT
        40
    Les1ie   131 天前
    3 个月前刚写过一个项目,一个人写的。 前端 vue+mint-ui 后端 django+django-graphene 数据库 mysql redis
    体验良好,前后端传递数据的时候感觉很方便,比较清晰

    存在的问题:
    安全性 由于 graphql 的代码即文档,他的自省大大方便了攻击者,可以很容易得到前后端交互的逻辑,信息泄露比 rest 严重 开发者如果不了解 graphql 的这些功能,可能写出来有巨大安全隐患的代码
    学习曲线 rest 上手更快,graphql 和平时写 web 的方式有点区别,需要学习很多东西才能开始上手,而且文档不是很丰富,django-graphene 的官方文档写得非常简单,甚至看完了可能也不够写完一个项目
        41
    husinhu   131 天前   ♥ 1
    那个男人被处理了,不会来了。
        42
    leven87   131 天前
    graphql 是一种前后端数据传输的方式,优点是代码即文档,非常直观,方便前后端同学交流。 还有通过 schema 定义数据格式,使得数据形式显得更加清晰,对于开发也是有帮助的。现在的开发的趋势就是模块化,组件化,我个人觉得不错的。
    Rest 的优点是更加灵活,接口对前端屏蔽了大量的细节。
    文档来说,基本是英文资料,虽然不是非常多,但也是够用的。
        43
    jinliming2   131 天前 via iPhone
    那个男人👨弃坑,来不了了!
        44
    lincanbin   131 天前 via Android
    用过,不好用。
        45
    alphatoad   131 天前 via iPhone
    为啥不用 protobuf
        46
    jamesliu96   131 天前 via Android
    会用,但没必要用
        47
    StarkWhite   131 天前
    @darknoll 现在已经很多资料了,除了各种博客,还有视频教程
    https://www.bilibili.com/video/av46200333/?p=9
        48
    StarkWhite   131 天前
        49
    tailf   131 天前   ♥ 1
    我的团队用了半年了,说下感受:

    1. 表面上看是给前端创造价值
    2. 表面上看后端的工作量增加了
    3. 其实这个东西是造福后端的,或者说是造福整个项目的:因为它提供了真正优秀的前后端分离架构
    4. 用上了 GraphQL 之后,软件质量显著提升,后端接口跨平台支持能力显著提升,后端接口可测试性显著提升
    5. 缺点也是有的,后端响应时间容易失控,需要更强的后端代码把控能力才能用的开心
        50
    StarkWhite   131 天前
    @yiyi11
    来了吗?
    来了。
    还来吗?
    不来了。
    /手动滑稽
        51
    StarkWhite   131 天前
    @VDimos wo wei graphql dai yan
        52
    StarkWhite   131 天前
    我也给 graphql 喂袋盐,哈哈
        53
    StarkWhite   131 天前
    @myyou apijson 不是一个个人项目吗? graphql 后面有 fb 支撑
        54
    StarkWhite   131 天前
        55
    StarkWhite   131 天前
    @monkingame graphql 主要是后端实现,和前端用 dart 还是 js 没太大的关系啊
        56
    StarkWhite   131 天前
    @yedanten 不用再等后端给接口了,前端自己就能拿数据哈哈,还解决了 over fetch 的问题。。。
        57
    skadi   131 天前
    辣个男人来了么? jxxxxxi 的那位.
        58
    StarkWhite   131 天前
    @razertory 什么鬼?谁完爆 GRAPHQL ?
        59
    tabris17   131 天前
    GraphQL,后端甩锅前端的工具
        60
    StarkWhite   131 天前
    @abcbuzhiming 后端也省了很多事啊,不用组装接口了
        61
    StarkWhite   131 天前
    @wentaoliang 后端也省了很多事啊,不用组装接口了
        62
    myyou   131 天前
    @StarkWhite graphql 只是 fb 贡献了一个协议,任何人都可以根据协议实现自己的 graphql,谈不上 fb 支撑。
        63
    nicoljiang   131 天前
    graphql 跟 restful 一样,只是一个思路或 Guide 吧。
        64
    karllynn   131 天前
    感觉没啥优势,类似的解决方案有很多。

    最大的作用可能将来方便用 AI 替代人写 CURD,让一批人下岗(
        65
    Tonni   131 天前
    Graphql 用起来确实方便,接口非常灵活,我以前做过一个 demo 给团队里面介绍过,后来业务没需求也就没在线上使用 - https://github.com/HouCoder/graphql-presentation
        66
    dcoder   130 天前
    本来 SQL 还有优化 SQL 就是一堆问题了,
    现在好,来个更沙雕的 idea,把 SQL 弄到最前端去, 直接暴露在空气中随便弄...
    好像所有的查询优化都可以魔法搬自动解决一样, 实在太脑残了
        67
    abcbuzhiming   130 天前
    @StarkWhite 后端省事个毛,后端多了一堆事。这东西对后端的业务复杂性有任何降低吗?没有!它给了前端自由,但是这个自由你以为没代价的?
        68
    leopku   130 天前 via iPhone   ♥ 1
    前面很多喷的能搞清楚再来喷么!

    还特么说什么把 sql 弄到前端,你丫就整一个脑残玩意!
        69
    nigelvon   130 天前
    开喷麻烦先搞清楚一点行么?
    GraphQL 生产环境用了 2 年了,适合新项目,不适合老顽固后端。
    有一定的门槛,水品差的没有按照 GraphQL 的逻辑来思考反而会增加工作量,还不如不用。
    摸透了之后是真的爽,接口效率大幅提审,版本迭代快得飞起。
        70
    catcalse   130 天前
    都 9012 年了,大家还没有吃上热乎的翔。是道德的沦丧还是人性的扭曲
        71
    nigelvon   130 天前
    @zjsxwc GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成,到你这就变成“服务器查询执行业务的消耗仍旧不变”了?你确定你用过么
        72
    zjsxwc   130 天前
    @nigelvon #67 原文:“@zjsxwc GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成,到你这就变成“服务器查询执行业务的消耗仍旧不变”了?你确定你用过么”
    ======
    回复:到了业务层面,就算不反回某数据的字段,数据库也返回数据的,除非你不用 orm
        73
    leopku   130 天前
    @abcbuzhiming graphql 官网哪条宣传信息告诉你它是用来降低后端业务复杂性的?!!!能先搞清楚 graphql 的作用和在系统架构中的位置才来再喷吗?
        74
    StarkWhite   130 天前
    @winglight2016 我也觉得,talk is cheap,show me your code
        75
    monkingame   130 天前
    @StarkWhite 前端是需要的,比如有 apollo graphql 的 client 端,有 js ( react/vue/ng )、java、swift 等实现,但就是没有 dart 的。我现在要用 flutter 开发,必须找 dart 实现,但没有官方支持。
    graphql 是 Facebook 提出来的,flutter 是 Google 的,估计两家尿不到一块去,dart 的实现目前只有第三方个人开发支持,很脆弱,目前 flutter 下只能作罢。

    graphql 用过一段时间,感觉还不错,因为是从头自己设计开发的 App,没有包袱,所以逮着最新技术就用,反正掉坑里大不了躺着不出来。
    我个人感觉,前端后端碰个头,自己写一套工具,隐藏掉存取细节,只暴露必须的数据接口,就是个微型的 graphql 了。
        76
    StarkWhite   130 天前
    @monkingame
    前端用正常的 HTTP 请求拼接 GraphQL 的 Query 字符串过去就行了,
    有封装更好,没有也麻烦不了多少啊
        77
    StarkWhite   130 天前
    @myyou 官方提供了 js 版实现
    https://github.com/graphql/graphql-js
        78
    StarkWhite   130 天前
    @xuyl RESTful 早就烂大街了啊,只是复杂的接口,用 RESTful 不好搞,前端调用多个 API 再提取和组装数据挺烦的,后端组装各种不同的接口给前端不同版本,不同客户端去调用,维护也很麻烦,然后 GraphQL 就出来了,前端就可以定制接口了,后端也省了很多工作量
        79
    yannxia   130 天前
    并不觉得好用
        80
    StarkWhite   130 天前
    @catcalse 就你皮~
        81
    monkingame   130 天前
    @StarkWhite 差不多这个意思吧,query 字符串到后台再分析处理,这是常规操作,再封装一下会更好。
    可能 graphql 设计者是这样想的(我个人推测):
    restful api 比较 low,而且没有通用性,都是在分析字符串。那如果前后端传递的是类型数据呢,那就又高端又安全方便。
    比如前端扔一个 class person 请求过来,要 person.name,后端看到请求,处理完毕,扔回 person.name 给前端,这就比字符串分析要高级多了,而且出错率还很低。毕竟是类型数据处理的话,语言层面就可以防止很多错误发生。
    其实这些都可以自己写一个封装实现,但 graphql 提供了现成的方案,当然代价也是有的:学习并掌握 graphql,将现有体系转换为 graphql (尤其老旧项目苦不堪言)。
        82
    StarkWhite   130 天前
    @icy37785 为啥不是 10010 ? 移动移不动,联通联不通,23333
        83
    abcbuzhiming   130 天前
    @leopku 官网是没宣布,顶不住这贴里很多人认为这东西就是用来降低后端复杂性的
        84
    abcbuzhiming   130 天前   ♥ 1
    @nigelvon
    “ GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成”
    这个说法是错误的,GraphQL 并没有提供这个能力,这个功能需要你自己去实现。而这种实现——只要是写过足够长时间后端的人都明白,是要付出额外的资源才能实现的。说白了吧,后端一股脑的把所有属性都扔给前端,绝不是因为这种方式有多美好,而是在大多数情况下,权衡了人力资源,开发时间等种种要素后,这种丑陋的方式是成本最低的方案。所以才会流传最广。
    说到底吧,GraphQL 目前只是解决了前后端之间的协议问题。对后端早就存在的陈年弊病。没有任何帮助
        85
    jy02201949   130 天前
    你们谁跟 Livid 告的状,把我心爱的汤米.柠檬给封了,要不然这么热闹的帖子,他这种自带爬虫属性的谦谦君子怎么可能不出现,你们赔我的“那个男人”
        86
    wentaoliang   130 天前
    @StarkWhite 新项目最开始就按照这个设计还好一点,但对我们来说依旧很麻烦因为有的接口输出字段有几十个,而且里面同一个字段在不同场景下的值还有复杂的逻辑,甚至和其他值有耦合。如果只是 curd 这种接口我觉得可以,复杂场景下但是能把业务代码写的合理就已经很有挑战了,还要在去关心 graph。。。
        87
    StarkWhite   130 天前
    @jy02201949 你们一口一个“那个‘男人‘’”,说得好像见过他本尊似的 /狗头
        88
    StarkWhite   130 天前
    @monkingame 有道理,不过自己封装一个,很可能没 GraphQL 火啊,那学习成本不是更高嘛?
        89
    nigelvon   130 天前
    @abcbuzhiming 那要看你怎么定义能力了,没有 graphQL 的协议支持,后端能知道前端需要哪些字段么?
        90
    StarkWhite   130 天前
    @karllynn 下岗说得太过了,没这么夸张吧,还是要后端做一些工作的
        91
    jy02201949   130 天前
    @StarkWhite #87 住口!!!那个男人需要见过吗!!!那犀利的舌战群儒技巧,那独树一帜开发不易求 star 的口吻,加上产品力宇宙超群 apijson,这样的男人仅仅活在想象里就已经是传说了好吗!!!
        92
    StarkWhite   130 天前
    @jy02201949 老哥,猛!
        93
    rockyou12   130 天前
    除了 node 写后端的真的有人用了这个?我们后端主要用 springboot,我是没看出来这东西比直接自动生成的 swagger 文档方便再哪,而且我找了半天,也没搞懂这东西怎么快速和 dto 做映射,怎样和 sql 映射?
        94
    StarkWhite   130 天前
    @jy02201949 对啊,真是过混,哦我亲爱的上帝,真想用皮鞋狠狠地踢他们的屁股 /狗头保命
        95
    StarkWhite   130 天前
    @rockyou12 Schema 和 Type 就是文档了,会直接在 GraphiQL 工具上展示。Type 就相当于 DTO,在 resolver 里映射
        96
    StarkWhite   130 天前
    看了下大家呼声很高的那个老哥账号还是在的,说不定是怕咱钓鱼,躲在暗中默默观察呢 /滑稽
    https://www.v2ex.com/member/TommyLemon
        97
    StarkWhite   130 天前
    @monkingame 老项目可以用 GraphQL 做中间层,resolver 里调用原来的 RESTful API
        98
    abcbuzhiming   130 天前
    @nigelvon 当然能啊,说到底 graphQL 只是协议而已,天下又不是只有它一种协议。它仅仅是回应了大家对 REST 的不满
        99
    dcoder   130 天前
    不能理解"GraphQL 就是把 SQL 弄到前端去", 就是没理解 GraphQL 这个沙雕 idea 的本质.
    这样说吧, 从广义上讲, 给前端提供个有一定表现力的 query DSL...
    这个方案的隐形代价是很大的! 除非你后端专门为这个 query DSL 设计个特别的数据库.
    不然没有魔法能保证你的查询效率, 你们支持 GraphQL 自己慢慢想吧...
        100
    StarkWhite   130 天前
    @dcoder 你说的查询效率是指 n+1 么?官方也提供了 dataloader 把这个问题解决掉了
    1  2  
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2226 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 39ms · UTC 03:25 · PVG 11:25 · LAX 19:25 · JFK 22:25
    ♥ Do have faith in what you're doing.