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

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

  •  
  •   StarkWhite · 2019-08-05 11:41:06 +08:00 · 19389 次点击
    这是一个创建于 1688 天前的主题,其中的信息可能已经有所发展或是发生改变。

    突然发现 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 ?

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

    楼主你列举的这些例子,看起来都虚的很,就像某大 V 推荐了一个牛逼东西一样。该关键字在(划重点:中立)搜索引擎上大红——这代表了真正有很多人在用或者在学习它,才能表示发展趋势良好。
    passerbytiny
        29
    passerbytiny  
       2019-08-05 17:38:58 +08:00   ❤️ 2
    多看了下楼主的主页,竟然发现是之前问“ Java 为什么不能热部署的”的作者。楼主如果不是编程初学者,则不需要看我后面的话。如果是,建议还是踏实点,从 Java、Javascript、SQL 的基础学起,不要搞 apijson、play、GraphQL 这些快速开发但高度封装(并隐藏细节)的工具。
    wentaoliang
        30
    wentaoliang  
       2019-08-05 18:02:51 +08:00
    尝试了几次,前端是用的爽了,后端一点都不爽,要知道大部分时候都是后端说了算。
    lolizeppelin
        31
    lolizeppelin  
       2019-08-05 19:20:57 +08:00
    好像 openstack 里 fileds 的用法...
    finian
        32
    finian  
       2019-08-05 19:45:43 +08:00   ❤️ 3
    在生产环境用了几年了,真香。楼上那些带着偏见的、搞不清概念的,建议用用再发表高见吧。还革 SQL 的命。。。先把人家是用来干嘛的搞清楚吧
    winglight2016
        33
    winglight2016  
       2019-08-05 20:31:03 +08:00
    @finian 好多人明显没有用过,批评都没批评到点子上
    icy37785
        34
    icy37785  
       2019-08-05 21:00:39 +08:00 via iPhone
    并不好用+10086
    wszgrcy
        35
    wszgrcy  
       2019-08-05 21:14:26 +08:00 via Android
    去年用的 nestjs+graphql,还要
    nyaapass
        36
    nyaapass  
       2019-08-05 21:16:28 +08:00
    辣个男人居然还没有来
    libook
        37
    libook  
       2019-08-05 21:22:25 +08:00
    没有银弹
    zjsxwc
        38
    zjsxwc  
       2019-08-05 21:23:02 +08:00 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 可以过滤掉不需要的字段,减少网络带宽。

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

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

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

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

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

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