都 9102 年了，大家有没有用上 Facebook 出的 GraphQL ？

2019-08-05 11:41:06 +08:00
 StarkWhite

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

阿里云 2020 校招内推，光速面试流程
（通过类 GraphQL+Serverless 实现接口聚合，减少前后端沟通成本）
https://yangjunhui.monster/t/587238

[阿里巴巴秋招] 飞猪用户技术，免笔试极速内推！可查进度
（参与端领域开源技术建设：Nodejs / Graphql / Serverless ）
https://yangjunhui.monster/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 ？

20641 次点击
所在节点    程序员
137 条回复
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
2019-08-06 14:17:22 +08:00
@icy37785 为啥不是 10010 ？ 移动移不动，联通联不通，23333
abcbuzhiming
2019-08-06 14:19:04 +08:00
@leopku 官网是没宣布，顶不住这贴里很多人认为这东西就是用来降低后端复杂性的
abcbuzhiming
2019-08-06 14:37:14 +08:00
@nigelvon
“ GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成”
这个说法是错误的，GraphQL 并没有提供这个能力，这个功能需要你自己去实现。而这种实现——只要是写过足够长时间后端的人都明白，是要付出额外的资源才能实现的。说白了吧，后端一股脑的把所有属性都扔给前端，绝不是因为这种方式有多美好，而是在大多数情况下，权衡了人力资源，开发时间等种种要素后，这种丑陋的方式是成本最低的方案。所以才会流传最广。
说到底吧，GraphQL 目前只是解决了前后端之间的协议问题。对后端早就存在的陈年弊病。没有任何帮助
jy02201949
2019-08-06 14:57:01 +08:00
你们谁跟 Livid 告的状，把我心爱的汤米.柠檬给封了，要不然这么热闹的帖子，他这种自带爬虫属性的谦谦君子怎么可能不出现，你们赔我的“那个男人”
wentaoliang
2019-08-06 15:11:35 +08:00
@StarkWhite 新项目最开始就按照这个设计还好一点，但对我们来说依旧很麻烦因为有的接口输出字段有几十个，而且里面同一个字段在不同场景下的值还有复杂的逻辑，甚至和其他值有耦合。如果只是 curd 这种接口我觉得可以，复杂场景下但是能把业务代码写的合理就已经很有挑战了，还要在去关心 graph。。。
StarkWhite
2019-08-06 15:22:08 +08:00
@jy02201949 你们一口一个“那个‘男人‘’”，说得好像见过他本尊似的 /狗头
StarkWhite
2019-08-06 15:23:51 +08:00
@monkingame 有道理，不过自己封装一个，很可能没 GraphQL 火啊，那学习成本不是更高嘛？
nigelvon
2019-08-06 15:26:30 +08:00
@abcbuzhiming 那要看你怎么定义能力了，没有 graphQL 的协议支持，后端能知道前端需要哪些字段么？
StarkWhite
2019-08-06 15:27:42 +08:00
@karllynn 下岗说得太过了，没这么夸张吧，还是要后端做一些工作的
jy02201949
2019-08-06 15:28:10 +08:00
@StarkWhite #87 住口！！！那个男人需要见过吗！！！那犀利的舌战群儒技巧，那独树一帜开发不易求 star 的口吻，加上产品力宇宙超群 apijson，这样的男人仅仅活在想象里就已经是传说了好吗！！！
StarkWhite
2019-08-06 15:30:26 +08:00
@jy02201949 老哥，猛！
rockyou12
2019-08-06 15:33:25 +08:00
除了 node 写后端的真的有人用了这个？我们后端主要用 springboot，我是没看出来这东西比直接自动生成的 swagger 文档方便再哪，而且我找了半天，也没搞懂这东西怎么快速和 dto 做映射，怎样和 sql 映射？
StarkWhite
2019-08-06 15:34:53 +08:00
@jy02201949 对啊，真是过混，哦我亲爱的上帝，真想用皮鞋狠狠地踢他们的屁股 /狗头保命
StarkWhite
2019-08-06 15:36:10 +08:00
@rockyou12 Schema 和 Type 就是文档了，会直接在 GraphiQL 工具上展示。Type 就相当于 DTO，在 resolver 里映射
StarkWhite
2019-08-06 15:39:10 +08:00
看了下大家呼声很高的那个老哥账号还是在的，说不定是怕咱钓鱼，躲在暗中默默观察呢 /滑稽
https://yangjunhui.monster/member/TommyLemon
StarkWhite
2019-08-06 15:40:18 +08:00
@monkingame 老项目可以用 GraphQL 做中间层，resolver 里调用原来的 RESTful API
abcbuzhiming
2019-08-06 15:43:36 +08:00
@nigelvon 当然能啊，说到底 graphQL 只是协议而已，天下又不是只有它一种协议。它仅仅是回应了大家对 REST 的不满
dcoder
2019-08-06 15:43:40 +08:00
不能理解"GraphQL 就是把 SQL 弄到前端去", 就是没理解 GraphQL 这个沙雕 idea 的本质.
这样说吧, 从广义上讲, 给前端提供个有一定表现力的 query DSL...
这个方案的隐形代价是很大的! 除非你后端专门为这个 query DSL 设计个特别的数据库.
不然没有魔法能保证你的查询效率, 你们支持 GraphQL 自己慢慢想吧...
StarkWhite
2019-08-06 15:59:33 +08:00
@dcoder 你说的查询效率是指 n+1 么？官方也提供了 dataloader 把这个问题解决掉了

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://yangjunhui.monster/t/589138

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX