都 9102 年了，大家有没有用上 Facebook 出的 GraphQL ？
StarkWhite · 2019-08-05 11:41:06 +08:00 · 20099 次点击这是一个创建于 1938 天前的主题，其中的信息可能已经有所发展或是发生改变。
突然发现 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
StarkWhite OP 拉勾上好像也有很多要求会 GraphQL 的岗位了
|
 |
2
darknoll 2019-08-05 12:16:16 +08:00
有没有啥资料让我学一下？
|
 |
3
Cabana 2019-08-05 13:43:21 +08:00 via Android
还之前记得有个 v 友自己写的类似的框架不知现在咋样了
|
 |
4
yiyi11 2019-08-05 13:49:15 +08:00 via Android  21
那个男人，会来吗？
|
 |
5
monkingame 2019-08-05 13:50:53 +08:00
用了，但没有 dart 的支持，暂时搁置了
|
 |
7
agdhole 2019-08-05 14:06:47 +08:00
那个男人，多久来呢
|
 |
8
zqx 2019-08-05 14:10:25 +08:00 via Android
无数以聚合数据为无数的 node 项目都要重构了？
|
 |
9
yedanten 2019-08-05 14:18:16 +08:00 via Android
并不觉得好用
|
 |
11
henyi2211 2019-08-05 14:28:16 +08:00
不觉得好用 +1
|
 |
12
zjsxwc 2019-08-05 14:34:18 +08:00
GraphQL 其实还不如“古老”的结构化查询语言 SQL (Structured Query Language) 来的方便
|
 |
13
chendy 2019-08-05 14:35:53 +08:00
并不觉得好用
|
 |
14
whitehack 2019-08-05 15:17:22 +08:00
并不觉得好用
|
 |
15
MrKou47 2019-08-05 15:31:50 +08:00 via iPhone
辣个男人还没有现身
|
 |
16
myyou 2019-08-05 15:34:13 +08:00 2
我来代替辣个蓝人发言，个人认为 apijson 要好于 GraphQL
|
 |
17
IsaacYoung 2019-08-05 15:35:02 +08:00
我以为香蕉君呢
|
 |
18
PDX 2019-08-05 15:44:11 +08:00
这种技术就是“可以有，但是没必要”，不要轻易尝试。
|
 |
19
source 2019-08-05 16:08:53 +08:00
@IsaacYoung #17 v2 香蕉君
|
 |
21
hirasawayui 2019-08-05 16:19:49 +08:00
我们.net 后端用上了
|
 |
22
razertory 2019-08-05 16:48:25 +08:00
没错，完爆 GraphQL ...
|
 |
23
wiix 2019-08-05 16:52:28 +08:00 1
GraphQL 无非就是把后端当数据库用，把前端当后端用而已。还隐藏了调用数据库的实现。企图革 SQL 的命但毫无希望。
|
 |
24
Caballarii 2019-08-05 16:56:16 +08:00
GraphQL 革的是 REST 的命啊，为啥上面说革 SQL 的命？？？
|
 |
25
xuyl 2019-08-05 16:57:25 +08:00
很多人都不愿尝试改变，RESTful 还没普及，GraphQL 还有待时日
|
|
26
razertory 2019-08-05 17:01:04 +08:00 2
我们实践了两年 GraphQL。。。总体的感受实际上是后端会花更多的心思在设计 schema 上，前端是要自己写 GraphQL 代码，但是因为强类型 + 固定返回数据结构的模式下。可以很放心地 call api 而不必处理很多恶心的边界条件，当然 API 文档。。。你懂的，为啥要写文档呢
|
 |
27
abcbuzhiming 2019-08-05 17:09:06 +08:00
我坚信自己没看错，这东西的好处在前端，锅要后端背，最重要的是这东西增加了成本，所以这玩意没戏。大公司可以靠强推火几年，中小型公司你根本推不下去
|
 |
28
passerbytiny 2019-08-05 17:24:46 +08:00
如果数据模型还要后端定义，那么 GraphQL 模式并不比 RESTful 模式省成本，更因为取消了中间层大大降低灵活性。
如果完全不要后端，那么成本有可能降低，但前端铁定要骂娘。而且这种模式也不是啥新模式，这就是以前的 C/S 模式，只不过 C 端从 VB、C#变成了 Javascript。 楼主你列举的这些例子，看起来都虚的很，就像某大 V 推荐了一个牛逼东西一样。该关键字在（划重点：中立）搜索引擎上大红——这代表了真正有很多人在用或者在学习它，才能表示发展趋势良好。 |
|
29
passerbytiny 2019-08-05 17:38:58 +08:00 2
多看了下楼主的主页，竟然发现是之前问“ Java 为什么不能热部署的”的作者。楼主如果不是编程初学者，则不需要看我后面的话。如果是，建议还是踏实点，从 Java、Javascript、SQL 的基础学起，不要搞 apijson、play、GraphQL 这些快速开发但高度封装（并隐藏细节）的工具。
|
 |
30
wentaoliang 2019-08-05 18:02:51 +08:00
尝试了几次，前端是用的爽了，后端一点都不爽，要知道大部分时候都是后端说了算。
|
 |
31
lolizeppelin 2019-08-05 19:20:57 +08:00
好像 openstack 里 fileds 的用法...
|
 |
32
finian 2019-08-05 19:45:43 +08:00 3
在生产环境用了几年了，真香。楼上那些带着偏见的、搞不清概念的，建议用用再发表高见吧。还革 SQL 的命。。。先把人家是用来干嘛的搞清楚吧
|
 |
33
winglight2016 2019-08-05 20:31:03 +08:00
@finian 好多人明显没有用过，批评都没批评到点子上
|
 |
34
icy37785 2019-08-05 21:00:39 +08:00 via iPhone
并不好用+10086
|
 |
35
wszgrcy 2019-08-05 21:14:26 +08:00 via Android
去年用的 nestjs+graphql，还要
|
 |
36
nyaapass 2019-08-05 21:16:28 +08:00
辣个男人居然还没有来
|
 |
37
libook 2019-08-05 21:22:25 +08:00
没有银弹
|
|
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 可以过滤掉不需要的字段，减少网络带宽。 虽然减少网络带宽，但服务器查询执行业务的消耗仍旧不变，而且对于大部分业务来说，前端获取的数据越多越好，很少有人会为了省那点带宽干这事情。 |
 |
39
xingyue 2019-08-05 21:28:08 +08:00 via Android
说辣个男人的都是在脑子里建了用户表么 233333~我看到第二个回复才反应过来看来我的索引待优化 TAT
|
 |
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 的官方文档写得非常简单，甚至看完了可能也不够写完一个项目 |
 |
41
husinhu 2019-08-05 21:39:41 +08:00 1
那个男人被处理了，不会来了。
|
 |
42
leven87 2019-08-05 21:53:58 +08:00
graphql 是一种前后端数据传输的方式，优点是代码即文档，非常直观，方便前后端同学交流。 还有通过 schema 定义数据格式，使得数据形式显得更加清晰，对于开发也是有帮助的。现在的开发的趋势就是模块化，组件化，我个人觉得不错的。
Rest 的优点是更加灵活，接口对前端屏蔽了大量的细节。 文档来说，基本是英文资料，虽然不是非常多，但也是够用的。 |
 |
43
jinliming2 2019-08-06 01:01:08 +08:00 via iPhone
那个男人👨弃坑，来不了了！
|
 |
44
lincanbin 2019-08-06 01:42:15 +08:00 via Android
用过，不好用。
|
 |
45
alphatoad 2019-08-06 03:49:12 +08:00 via iPhone
为啥不用 protobuf
|
 |
46
jamesliu96 2019-08-06 09:15:07 +08:00 via Android
会用，但没必要用
|
|
47
StarkWhite OP |
|
48
StarkWhite OP |
 |
49
tailf 2019-08-06 10:10:28 +08:00 1
我的团队用了半年了，说下感受：
1. 表面上看是给前端创造价值 2. 表面上看后端的工作量增加了 3. 其实这个东西是造福后端的，或者说是造福整个项目的：因为它提供了真正优秀的前后端分离架构 4. 用上了 GraphQL 之后，软件质量显著提升，后端接口跨平台支持能力显著提升，后端接口可测试性显著提升 5. 缺点也是有的，后端响应时间容易失控，需要更强的后端代码把控能力才能用的开心 |
|
50
StarkWhite OP |
|
51
StarkWhite OP @VDimos wo wei graphql dai yan
|
|
52
StarkWhite OP 我也给 graphql 喂袋盐，哈哈
|
|
53
StarkWhite OP @myyou apijson 不是一个个人项目吗？ graphql 后面有 fb 支撑
|
|
54
StarkWhite OP |
|
55
StarkWhite OP @monkingame graphql 主要是后端实现，和前端用 dart 还是 js 没太大的关系啊
|
|
56
StarkWhite OP @yedanten 不用再等后端给接口了，前端自己就能拿数据哈哈，还解决了 over fetch 的问题。。。
|
 |
57
skadi 2019-08-06 10:25:08 +08:00
辣个男人来了么? jxxxxxi 的那位.
|
|
58
StarkWhite OP @razertory 什么鬼？谁完爆 GRAPHQL ?
|
 |
59
tabris17 2019-08-06 10:29:09 +08:00
GraphQL，后端甩锅前端的工具
|
|
60
StarkWhite OP @abcbuzhiming 后端也省了很多事啊，不用组装接口了
|
|
61
StarkWhite OP @wentaoliang 后端也省了很多事啊，不用组装接口了
|
|
62
myyou 2019-08-06 10:34:26 +08:00
@StarkWhite graphql 只是 fb 贡献了一个协议，任何人都可以根据协议实现自己的 graphql，谈不上 fb 支撑。
|
 |
63
nicoljiang 2019-08-06 10:36:51 +08:00
graphql 跟 restful 一样，只是一个思路或 Guide 吧。
|
 |
64
karllynn 2019-08-06 11:08:27 +08:00
感觉没啥优势，类似的解决方案有很多。
最大的作用可能将来方便用 AI 替代人写 CURD，让一批人下岗（ |
 |
65
Tonni 2019-08-06 11:21:08 +08:00
Graphql 用起来确实方便，接口非常灵活，我以前做过一个 demo 给团队里面介绍过，后来业务没需求也就没在线上使用 - https://github.com/HouCoder/graphql-presentation
|
 |
66
dcoder 2019-08-06 11:42:16 +08:00
本来 SQL 还有优化 SQL 就是一堆问题了,
现在好，来个更沙雕的 idea，把 SQL 弄到最前端去, 直接暴露在空气中随便弄... 好像所有的查询优化都可以魔法搬自动解决一样, 实在太脑残了 |
|
67
abcbuzhiming 2019-08-06 12:36:05 +08:00
@StarkWhite 后端省事个毛，后端多了一堆事。这东西对后端的业务复杂性有任何降低吗？没有！它给了前端自由，但是这个自由你以为没代价的？
|
 |
68
leopku 2019-08-06 12:41:27 +08:00 via iPhone 1
前面很多喷的能搞清楚再来喷么！
还特么说什么把 sql 弄到前端，你丫就整一个脑残玩意！ |
 |
69
nigelvon 2019-08-06 13:02:05 +08:00
开喷麻烦先搞清楚一点行么？
GraphQL 生产环境用了 2 年了，适合新项目，不适合老顽固后端。 有一定的门槛，水品差的没有按照 GraphQL 的逻辑来思考反而会增加工作量，还不如不用。 摸透了之后是真的爽，接口效率大幅提审，版本迭代快得飞起。 |
 |
70
catcalse 2019-08-06 13:03:39 +08:00
都 9012 年了，大家还没有吃上热乎的翔。是道德的沦丧还是人性的扭曲
|
|
71
nigelvon 2019-08-06 13:05:37 +08:00
@zjsxwc GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成，到你这就变成“服务器查询执行业务的消耗仍旧不变”了？你确定你用过么
|
|
72
zjsxwc 2019-08-06 13:26:05 +08:00
@nigelvon #67 原文：“@zjsxwc GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成，到你这就变成“服务器查询执行业务的消耗仍旧不变”了？你确定你用过么”
====== 回复：到了业务层面，就算不反回某数据的字段，数据库也返回数据的，除非你不用 orm |
|
73
leopku 2019-08-06 13:49:36 +08:00
@abcbuzhiming graphql 官网哪条宣传信息告诉你它是用来降低后端业务复杂性的？！！！能先搞清楚 graphql 的作用和在系统架构中的位置才来再喷吗？
|
|
74
StarkWhite OP @winglight2016 我也觉得，talk is cheap，show me your code
|
|
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 了。 |
|
76
StarkWhite OP |
|
77
StarkWhite OP |
|
78
StarkWhite OP @xuyl RESTful 早就烂大街了啊，只是复杂的接口，用 RESTful 不好搞，前端调用多个 API 再提取和组装数据挺烦的，后端组装各种不同的接口给前端不同版本，不同客户端去调用，维护也很麻烦，然后 GraphQL 就出来了，前端就可以定制接口了，后端也省了很多工作量
|
 |
79
yannxia 2019-08-06 14:07:46 +08:00
并不觉得好用
|
|
80
StarkWhite OP @catcalse 就你皮~
|
|
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 （尤其老旧项目苦不堪言）。 |
|
82
StarkWhite OP @icy37785 为啥不是 10010 ？ 移动移不动，联通联不通，23333
|
|
83
abcbuzhiming 2019-08-06 14:19:04 +08:00
@leopku 官网是没宣布，顶不住这贴里很多人认为这东西就是用来降低后端复杂性的
|
|
84
abcbuzhiming 2019-08-06 14:37:14 +08:00 1
@nigelvon
“ GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成” 这个说法是错误的，GraphQL 并没有提供这个能力，这个功能需要你自己去实现。而这种实现——只要是写过足够长时间后端的人都明白，是要付出额外的资源才能实现的。说白了吧，后端一股脑的把所有属性都扔给前端，绝不是因为这种方式有多美好，而是在大多数情况下，权衡了人力资源，开发时间等种种要素后，这种丑陋的方式是成本最低的方案。所以才会流传最广。 说到底吧，GraphQL 目前只是解决了前后端之间的协议问题。对后端早就存在的陈年弊病。没有任何帮助 |
 |
85
jy02201949 2019-08-06 14:57:01 +08:00
 你们谁跟 Livid 告的状，把我心爱的汤米.柠檬给封了，要不然这么热闹的帖子，他这种自带爬虫属性的谦谦君子怎么可能不出现，你们赔我的“那个男人” |
|
86
wentaoliang 2019-08-06 15:11:35 +08:00
@StarkWhite 新项目最开始就按照这个设计还好一点，但对我们来说依旧很麻烦因为有的接口输出字段有几十个，而且里面同一个字段在不同场景下的值还有复杂的逻辑，甚至和其他值有耦合。如果只是 curd 这种接口我觉得可以，复杂场景下但是能把业务代码写的合理就已经很有挑战了，还要在去关心 graph。。。
|
|
87
StarkWhite OP @jy02201949 你们一口一个“那个‘男人‘’”，说得好像见过他本尊似的 /狗头
|
|
88
StarkWhite OP @monkingame 有道理，不过自己封装一个，很可能没 GraphQL 火啊，那学习成本不是更高嘛？
|
|
89
nigelvon 2019-08-06 15:26:30 +08:00
@abcbuzhiming 那要看你怎么定义能力了，没有 graphQL 的协议支持，后端能知道前端需要哪些字段么？
|
|
90
StarkWhite OP @karllynn 下岗说得太过了，没这么夸张吧，还是要后端做一些工作的
|
|
91
jy02201949 2019-08-06 15:28:10 +08:00
@StarkWhite #87 住口！！！那个男人需要见过吗！！！那犀利的舌战群儒技巧，那独树一帜开发不易求 star 的口吻，加上产品力宇宙超群 apijson，这样的男人仅仅活在想象里就已经是传说了好吗！！！
|
|
92
StarkWhite OP @jy02201949 老哥，猛！
|
 |
93
rockyou12 2019-08-06 15:33:25 +08:00
除了 node 写后端的真的有人用了这个？我们后端主要用 springboot，我是没看出来这东西比直接自动生成的 swagger 文档方便再哪，而且我找了半天，也没搞懂这东西怎么快速和 dto 做映射，怎样和 sql 映射？
|
|
94
StarkWhite OP @jy02201949 对啊，真是过混，哦我亲爱的上帝，真想用皮鞋狠狠地踢他们的屁股 /狗头保命
|
|
95
StarkWhite OP @rockyou12 Schema 和 Type 就是文档了，会直接在 GraphiQL 工具上展示。Type 就相当于 DTO，在 resolver 里映射
|
|
96
StarkWhite OP 看了下大家呼声很高的那个老哥账号还是在的，说不定是怕咱钓鱼，躲在暗中默默观察呢 /滑稽
https://www.v2ex.com/member/TommyLemon |
|
97
StarkWhite OP @monkingame 老项目可以用 GraphQL 做中间层，resolver 里调用原来的 RESTful API
|
|
98
abcbuzhiming 2019-08-06 15:43:36 +08:00
@nigelvon 当然能啊，说到底 graphQL 只是协议而已，天下又不是只有它一种协议。它仅仅是回应了大家对 REST 的不满
|
|
99
dcoder 2019-08-06 15:43:40 +08:00
不能理解"GraphQL 就是把 SQL 弄到前端去", 就是没理解 GraphQL 这个沙雕 idea 的本质.
这样说吧, 从广义上讲, 给前端提供个有一定表现力的 query DSL... 这个方案的隐形代价是很大的! 除非你后端专门为这个 query DSL 设计个特别的数据库. 不然没有魔法能保证你的查询效率, 你们支持 GraphQL 自己慢慢想吧... |
|
100
StarkWhite OP @dcoder 你说的查询效率是指 n+1 么？官方也提供了 dataloader 把这个问题解决掉了
|
Select Language