都 9102 年了，大家有没有用上 Facebook 出的 GraphQL ？
StarkWhite · 2019-08-05 11:41:06 +08:00 · 20131 次点击这是一个创建于 1945 天前的主题，其中的信息可能已经有所发展或是发生改变。
突然发现 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
 |
101
clino 2019-08-06 15:59:41 +08:00 via Android
你们这样确实会给辣个蓝人带去了不少流量
|
 |
102
StarkWhite OP |
|
103
StarkWhite OP @Les1ie 生产环境把自省关掉好了
|
|
104
StarkWhite OP @alphatoad protobuf 是 rpc 协议，facebook 也有个 thrift，都和 graphql 不是一类的项目。。。
|
|
105
StarkWhite OP @karllynn 首先 AI 得理解产品需求，现在担心还为时尚早哈哈
|
 |
106
ysp 2019-08-06 16:16:38 +08:00
我们公司全套后端都上了 graphQL~ 有兴趣的可以来围观下 https://www.v2ex.com/t/589523#reply0
|
 |
107
nigelvon 2019-08-06 16:39:14 +08:00
@zjsxwc 这种是简单业务，几乎没有额外消耗的，多一个字段少一个字段并没什么差别。但是稍微复杂点的业务都不是一个查询就能查出来的，这时候前端描述的协议就显得很有价值了。
|
 |
108
rizon 2019-08-06 17:23:49 +08:00
了解不深，诚恳希望有人给正经解释一下，graphql 和普通的开发中的一个查询接口里面接收查询条件与回显字段 这两者之间的区别有多大？
以及这东西后端开发怎么去优化性能？明明只查索引字段的数据，我却要把库里的所有字段都捞出来？ 不懂啊。 |
|
109
rizon 2019-08-06 17:27:02 +08:00
我举个例子，一个查询账单的接口，同时还要展示每条明细数据的所属人的中文名，那么用户信息是从其他系统的 api 接口获取的。
后端开发会把分页数据查询出来后，把用户 id 捞出来一个集合去 api 接口把用户信息查出来，再把用户信息的中文名塞回到最终结果数据中。 这样一个场景在引入了 graphql 之后该怎么去做呢？ 不说达到更好的效果，可以达到差不多相同的效果与效率吗？ |
|
110
StarkWhite OP @ysp 赞
|
|
111
StarkWhite OP @rizon dataloader 就是这个原理啊
|
|
112
StarkWhite OP @IsaacYoung 香蕉君是谁？网红吗？
|
 |
113
jss 2019-08-06 18:41:34 +08:00 via iPhone
感觉华而不实
|
 |
114
Mithril 2019-08-06 19:03:29 +08:00  1
不管是什么技术，总有个适用范围。没什么东西是万能的。
GraphQL 的语法也好，ElasticSearch 的 Query 语法也好，SQL 也好，本质上都是一个用来 Query 较复杂结构的 DSL。你如果把整套 Graph QL 抽象为接口，那么你认为你是在前端写 SQL 也没有问题。 但 GraphQL 主要是用来解决 API 设计问题的，至于怎么优化查询并不是它的重点。SQL 本质上也是一样，这种语言是设计用来查询关系型数据的，怎么优化是 DBMS 的事。 REST 接口实现简单，也没什么复杂的心智负担。但如果你需要做成 REST 的东西比较多的话，前端免不了做一堆的 Promise 来回的查。而且这种多次查询后台也没法做优化。 你给每个需求写个 API 可以做到细致的优化，但是前后端很难同时开始工作，你得先定好接口，Mock，或者上 Swagger。而且这种写法扩展性有限，新增需求很多时候你就得新弄个 API。 GraphQL 和 ElasticSearch 的 Query 比较类似，优点不在于优化性能，而在于更大程度上去释放系统的可扩展性。比如你要做个类似 Kibana 的工具，绘制的图像各个轴可以自定义 model 和 field，但不涉及特别复杂的计算聚合和优化。那么类似的东西就是最好的选择。 真正使用的时候还是要根据自己项目的特点去选择合适的技术，不是看什么新就用什么。GraphQL 也有一大堆的缺点，但是你的需求如果可以正好避开这些缺点，同时它擅长的东西也是你想要的，那么没什么理由不用它。 |
 |
115
dcoder 2019-08-07 06:46:55 +08:00
"GraphQL 和 ElasticSearch 的 Query 比较类似，优点不在于优化性能"
大家理解 GraphQL 暗含了多少查询性能的坑了没? 我还是那句话, 如果有天出现了成熟的 GraphQL Database, 专门做给 GraphQL 查询用的, GraphQL 可以一用, 但是, 本质上就是另外一个专门的 database with specific query APIs, 就像 ElasticSearch |
|
116
dcoder 2019-08-07 08:03:41 +08:00
然而人家 ElasticSearch 同时提供了 database 和 Query DSL -- 它复杂的 JSON API 其实已经是 DSL 了.
GraphQL 提供了什么? 一个看起来美妙的 Query DSL 和 ... ... ? |
|
117
dcoder 2019-08-07 08:30:07 +08:00
可以看看知乎这个帖子里 2018~2019 的讨论
"GraphQL 的每一个实体背后可能对应着不同的数据库甚至不同类型的存储集群，后端集群间的海量数据自由 join，基本还是无解的，只能搭专门的集群处理，这个不清楚 FB 是否有什么黑科技，我严重怀疑 FB 自己也没做到全业务查询" "FB 自己也没有黑科技...最近在做广告数据整合，FB 的广告相关 API 基本是一步一个 bug， 基础的时间段 filter 都有问题。传统 restapi 我好歹还可以看文档知道到底支持哪些 API 请求，Facebook 的 graphql 经常会出现明明符合查询字段，返回的确实毫不相关数据的情况" "这个事情到底由谁来做？ GraphQL 的利好主要是在于前端的开发效率，但落地却需要服务端的全力配合" GraphQL 玩玩可以. 认真做个大系统? 算了吧. |
|
118
dcoder 2019-08-07 08:31:52 +08:00
知乎帖子 <GraphQL 为何没有火起来?>
没有认证, 现在不能发 URL... |
|
119
StarkWhite OP @jss 但是前端可以为所欲为啊 /滑稽
|
|
120
StarkWhite OP @dcoder 知乎那个帖子都是 16 年前的了，现在都 9102 年了，性能问题也有 dataloader 来解决了
|
|
121
StarkWhite OP @Mithril 赞，适用范围内使用就好了
|
|
122
StarkWhite OP @StarkWhite 没必要像评论里一堆人抓着它的缺点不放，非得拿去干不适合的事情，然后说它垃圾
|
|
123
StarkWhite OP @dcoder 你看，我同样也能在知乎上找到支持 GraphQL 的回答：
"有人吐槽性能，只想说如果一定要做接口数据聚合这件事的话，GraphQL 遇到的问题几乎都会遇到，而并不是没有方案在解决此类问题。就接口数据聚合这事来说，它目前可能是最优方案。而就接口数据聚合这事需要不需要，个人认为微服务架构下几乎是必须。 还有提到 join 的，会有这个问题，但在微服务架构下，各自分管自己数据库这种场景下不也是一样么，抛弃了一些数据库本身所带来的直接好处以做妥协。如果本来服务粒度划分就很细，不用 GraphQL 同样也会遇到这个问题。" "总而言之，个人的观点是：一个产品需要整个数据模型架构图之类的东西帮助所有开发人员理解来减少沟通和其他软成本。微服务架构下本就需要不同服务的数据聚合后透出给前端，GraphQL 可能是目前最好的数据聚合方案。后端在标准化的流程下，可以把方向往自动化生成大多数代码上去走，然后在此基础上去做定制化修正和优化，最终其实能极大增加开发效率，也能让不同的开发人员开发出规范雷同的代码，利于以后的维护。" |
|
124
dcoder 2019-08-07 13:24:18 +08:00
@StarkWhite
我不觉得有什么很好的方案能解决效率问题，因为 GraphQL 要达到的黑魔法一样的效果，后端的支持必然会比较粗糙. 我们看观点，不看出处. 你引用的这段，看着真的挺 YY 的. 而且我没听说过, micro service 最好是要配套 GraphQL 的. |
|
125
Mithril 2019-08-07 14:42:09 +08:00
@dcoder 性能问题只要你做聚合就都会有的，用不用 GraphQL 都一样，也不用期待 GraphQL 能解决本应该用其它方法解决的问题。
其实自己做一个聚合查询的接口也可以，但要自己设计 API，Parser，配套的辅助工具，再给前端后端讲清楚接口。 GraphQL 实际上做的就是这些事，省了你自己设计这 API 的时间。基本上是和 Swagger 类似的地位，也没人指望 Swagger 能解决端口的性能问题吧。 |
|
126
nigelvon 2019-08-07 14:58:08 +08:00
GraphQL 能够帮助解决一部分非描述性接口的性能问题，说不能的只是不知道 GraphQL 请求方描述的内容有什么用、怎么用而已。
|
|
127
dcoder 2019-08-08 01:57:04 +08:00
@Mithril
GraphQL 的问题是, 它定义了某些高级的可以演义的动态 '语义' 和 '逻辑'. 没有任何成熟的机制，可以保证这些特性被高效可靠地实现. 所以, 其实要做聚合多个 micro service 的查询 api, 直接用死死的 function call 一样的 API 反而简单可靠高效 -- 比如就用 RESTful 之类就行了. |
 |
128
soulzz 2019-08-28 16:28:04 +08:00
提问：查询比原生查慢一倍
 如何优化 |
|
129
StarkWhite OP @soulzz dataloader
|
|
130
StarkWhite OP 你还可以明早发一条帖子，让更多人看到并回答
|
 |
131
aomine 2019-08-29 08:28:11 +08:00 via iPhone
加上 prisma 爽的一批
|
|
132
StarkWhite OP @ysp 感谢支持~
|
|
133
StarkWhite OP @aomine 是啊哈哈，我公司也在用 prisma
|
|
134
StarkWhite OP @soulzz 没图没真相，哪有这么大的差距。。。
|
|
135
StarkWhite OP @dcoder 那你得写多少 if else，光是字段组合就得累死，graphql 可以自动组装字段
|
Select Language