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

[StarkWhite]

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

[StarkWhite]

拉勾上好像也有很多要求会 GraphQL 的岗位了

[darknoll]

有没有啥资料让我学一下？

[Cabana]

还之前记得有个 v 友自己写的类似的框架不知现在咋样了

[yiyi11]

那个男人，会来吗？

[monkingame]

用了，但没有 dart 的支持，暂时搁置了

[VDimos]

@yiyi11 看来都有被那个男人支配的恐惧

[agdhole]

那个男人，多久来呢

[zqx]

无数以聚合数据为无数的 node 项目都要重构了？

[yedanten]

并不觉得好用

[YOOHUU]

@VDimos #6 萌新问下,是谁?

[herbertzz]

不觉得好用 +1

[zjsxwc]

GraphQL 其实还不如“古老”的结构化查询语言 SQL (Structured Query Language) 来的方便

[chendy]

并不觉得好用

[whitehack]

并不觉得好用

[MrKou47]

辣个男人还没有现身

[myyou]

我来代替辣个蓝人发言，个人认为 apijson 要好于 GraphQL

[IsaacYoung]

我以为香蕉君呢

[PDX]

这种技术就是“可以有，但是没必要”，不要轻易尝试。

[source]

@IsaacYoung #17 v2 香蕉君

[VDimos]

@DAPTX4869 为 apijson 代言的男人

[hirasawayui]

我们.net 后端用上了

[razertory]

没错，完爆 GraphQL ...

[wiix]

GraphQL 无非就是把后端当数据库用，把前端当后端用而已。还隐藏了调用数据库的实现。企图革 SQL 的命但毫无希望。

[Caballarii]

GraphQL 革的是 REST 的命啊，为啥上面说革 SQL 的命？？？

[xuyl]

很多人都不愿尝试改变，RESTful 还没普及，GraphQL 还有待时日

[razertory]

我们实践了两年 GraphQL。。。总体的感受实际上是后端会花更多的心思在设计 schema 上，前端是要自己写 GraphQL 代码，但是因为强类型 + 固定返回数据结构的模式下。可以很放心地 call api 而不必处理很多恶心的边界条件，当然 API 文档。。。你懂的，为啥要写文档呢

[abcbuzhiming]

我坚信自己没看错，这东西的好处在前端，锅要后端背，最重要的是这东西增加了成本，所以这玩意没戏。大公司可以靠强推火几年，中小型公司你根本推不下去

[passerbytiny]

如果数据模型还要后端定义，那么 GraphQL 模式并不比 RESTful 模式省成本，更因为取消了中间层大大降低灵活性。
如果完全不要后端，那么成本有可能降低，但前端铁定要骂娘。而且这种模式也不是啥新模式，这就是以前的 C/S 模式，只不过 C 端从 VB、C#变成了 Javascript。

楼主你列举的这些例子，看起来都虚的很，就像某大 V 推荐了一个牛逼东西一样。该关键字在（划重点：中立）搜索引擎上大红——这代表了真正有很多人在用或者在学习它，才能表示发展趋势良好。

[passerbytiny]

多看了下楼主的主页，竟然发现是之前问“ Java 为什么不能热部署的”的作者。楼主如果不是编程初学者，则不需要看我后面的话。如果是，建议还是踏实点，从 Java、Javascript、SQL 的基础学起，不要搞 apijson、play、GraphQL 这些快速开发但高度封装（并隐藏细节）的工具。

[wentaoliang]

尝试了几次，前端是用的爽了，后端一点都不爽，要知道大部分时候都是后端说了算。

[lolizeppelin]

好像 openstack 里 fileds 的用法...

[finian]

在生产环境用了几年了，真香。楼上那些带着偏见的、搞不清概念的，建议用用再发表高见吧。还革 SQL 的命。。。先把人家是用来干嘛的搞清楚吧

[winglight2016]

@finian 好多人明显没有用过，批评都没批评到点子上

[icy37785]

并不好用+10086

[wszgrcy]

去年用的 nestjs+graphql，还要

[nyaapass]

辣个男人居然还没有来

[libook]

没有银弹

[zjsxwc]

说通俗一点，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]

说辣个男人的都是在脑子里建了用户表么 233333~我看到第二个回复才反应过来看来我的索引待优化 TAT

[Les1ie]

3 个月前刚写过一个项目，一个人写的。 前端 vue+mint-ui 后端 django+django-graphene 数据库 mysql redis
体验良好，前后端传递数据的时候感觉很方便，比较清晰

存在的问题：
安全性 由于 graphql 的代码即文档，他的自省大大方便了攻击者，可以很容易得到前后端交互的逻辑，信息泄露比 rest 严重 开发者如果不了解 graphql 的这些功能，可能写出来有巨大安全隐患的代码
学习曲线 rest 上手更快，graphql 和平时写 web 的方式有点区别，需要学习很多东西才能开始上手，而且文档不是很丰富，django-graphene 的官方文档写得非常简单，甚至看完了可能也不够写完一个项目

[husinhu]

那个男人被处理了，不会来了。

[leven87]

graphql 是一种前后端数据传输的方式，优点是代码即文档，非常直观，方便前后端同学交流。 还有通过 schema 定义数据格式，使得数据形式显得更加清晰，对于开发也是有帮助的。现在的开发的趋势就是模块化，组件化，我个人觉得不错的。
Rest 的优点是更加灵活，接口对前端屏蔽了大量的细节。
文档来说，基本是英文资料，虽然不是非常多，但也是够用的。

[jinliming2]

那个男人👨弃坑，来不了了！

[lincanbin]

用过，不好用。

[alphatoad]

为啥不用 protobuf

[jamesliu96]

会用，但没必要用

[StarkWhite]

@darknoll 现在已经很多资料了，除了各种博客，还有视频教程
https://www.bilibili.com/video/av46200333/?p=9

[StarkWhite]

@Cabana 是这个吧？
https://www.v2ex.com/t/583356

[tailf]

我的团队用了半年了，说下感受：

1. 表面上看是给前端创造价值
2. 表面上看后端的工作量增加了
3. 其实这个东西是造福后端的，或者说是造福整个项目的：因为它提供了真正优秀的前后端分离架构
4. 用上了 GraphQL 之后，软件质量显著提升，后端接口跨平台支持能力显著提升，后端接口可测试性显著提升
5. 缺点也是有的，后端响应时间容易失控，需要更强的后端代码把控能力才能用的开心

[StarkWhite]

@yiyi11
来了吗？
来了。
还来吗？
不来了。
/手动滑稽

[StarkWhite]

@VDimos wo wei graphql dai yan

[StarkWhite]

我也给 graphql 喂袋盐，哈哈

[StarkWhite]

@myyou apijson 不是一个个人项目吗？ graphql 后面有 fb 支撑

[StarkWhite]

@hirasawayui 有开源嘛？可以贡献 demo 哈
https://github.com/GraphQL-China/graphql-examples

[StarkWhite]

@monkingame graphql 主要是后端实现，和前端用 dart 还是 js 没太大的关系啊

[StarkWhite]

@yedanten 不用再等后端给接口了，前端自己就能拿数据哈哈，还解决了 over fetch 的问题。。。

[skadi]

辣个男人来了么? jxxxxxi 的那位.

[StarkWhite]

@razertory 什么鬼？谁完爆 GRAPHQL ?

[tabris17]

GraphQL，后端甩锅前端的工具

[StarkWhite]

@abcbuzhiming 后端也省了很多事啊，不用组装接口了

[StarkWhite]

@wentaoliang 后端也省了很多事啊，不用组装接口了

[myyou]

@StarkWhite graphql 只是 fb 贡献了一个协议，任何人都可以根据协议实现自己的 graphql，谈不上 fb 支撑。

[nicoljiang]

graphql 跟 restful 一样，只是一个思路或 Guide 吧。

[karllynn]

感觉没啥优势，类似的解决方案有很多。

最大的作用可能将来方便用 AI 替代人写 CURD，让一批人下岗（

[Tonni]

Graphql 用起来确实方便，接口非常灵活，我以前做过一个 demo 给团队里面介绍过，后来业务没需求也就没在线上使用 - https://github.com/HouCoder/graphql-presentation

[dcoder]

本来 SQL 还有优化 SQL 就是一堆问题了,
现在好，来个更沙雕的 idea，把 SQL 弄到最前端去, 直接暴露在空气中随便弄...
好像所有的查询优化都可以魔法搬自动解决一样, 实在太脑残了

[abcbuzhiming]

@StarkWhite 后端省事个毛，后端多了一堆事。这东西对后端的业务复杂性有任何降低吗？没有！它给了前端自由，但是这个自由你以为没代价的？

[leopku]

前面很多喷的能搞清楚再来喷么！

还特么说什么把 sql 弄到前端，你丫就整一个脑残玩意！

[nigelvon]

开喷麻烦先搞清楚一点行么？
GraphQL 生产环境用了 2 年了，适合新项目，不适合老顽固后端。
有一定的门槛，水品差的没有按照 GraphQL 的逻辑来思考反而会增加工作量，还不如不用。
摸透了之后是真的爽，接口效率大幅提审，版本迭代快得飞起。

[catcalse]

都 9012 年了，大家还没有吃上热乎的翔。是道德的沦丧还是人性的扭曲

[nigelvon]

@zjsxwc GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成，到你这就变成“服务器查询执行业务的消耗仍旧不变”了？你确定你用过么

[zjsxwc]

@nigelvon #67 原文：“@zjsxwc GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成，到你这就变成“服务器查询执行业务的消耗仍旧不变”了？你确定你用过么”
======
回复：到了业务层面，就算不反回某数据的字段，数据库也返回数据的，除非你不用 orm

[leopku]

@abcbuzhiming graphql 官网哪条宣传信息告诉你它是用来降低后端业务复杂性的？！！！能先搞清楚 graphql 的作用和在系统架构中的位置才来再喷吗？

[StarkWhite]

@winglight2016 我也觉得，talk is cheap，show me your code

[monkingame]

@StarkWhite 前端是需要的，比如有 apollo graphql 的 client 端，有 js （ react/vue/ng ）、java、swift 等实现，但就是没有 dart 的。我现在要用 flutter 开发，必须找 dart 实现，但没有官方支持。
graphql 是 Facebook 提出来的，flutter 是 Google 的，估计两家尿不到一块去，dart 的实现目前只有第三方个人开发支持，很脆弱，目前 flutter 下只能作罢。

graphql 用过一段时间，感觉还不错，因为是从头自己设计开发的 App，没有包袱，所以逮着最新技术就用，反正掉坑里大不了躺着不出来。
我个人感觉，前端后端碰个头，自己写一套工具，隐藏掉存取细节，只暴露必须的数据接口，就是个微型的 graphql 了。

[StarkWhite]

@monkingame
前端用正常的 HTTP 请求拼接 GraphQL 的 Query 字符串过去就行了，
有封装更好，没有也麻烦不了多少啊

[StarkWhite]

@myyou 官方提供了 js 版实现
https://github.com/graphql/graphql-js

[StarkWhite]

@xuyl RESTful 早就烂大街了啊，只是复杂的接口，用 RESTful 不好搞，前端调用多个 API 再提取和组装数据挺烦的，后端组装各种不同的接口给前端不同版本，不同客户端去调用，维护也很麻烦，然后 GraphQL 就出来了，前端就可以定制接口了，后端也省了很多工作量

[Yanickkk]

并不觉得好用

[StarkWhite]

@catcalse 就你皮~

[monkingame]

@StarkWhite 差不多这个意思吧，query 字符串到后台再分析处理，这是常规操作，再封装一下会更好。
可能 graphql 设计者是这样想的（我个人推测）：
restful api 比较 low，而且没有通用性，都是在分析字符串。那如果前后端传递的是类型数据呢，那就又高端又安全方便。
比如前端扔一个 class person 请求过来，要 person.name，后端看到请求，处理完毕，扔回 person.name 给前端，这就比字符串分析要高级多了，而且出错率还很低。毕竟是类型数据处理的话，语言层面就可以防止很多错误发生。
其实这些都可以自己写一个封装实现，但 graphql 提供了现成的方案，当然代价也是有的：学习并掌握 graphql，将现有体系转换为 graphql （尤其老旧项目苦不堪言）。

[StarkWhite]

@icy37785 为啥不是 10010 ？ 移动移不动，联通联不通，23333

[abcbuzhiming]

@leopku 官网是没宣布，顶不住这贴里很多人认为这东西就是用来降低后端复杂性的

[abcbuzhiming]

@nigelvon
“ GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成”
这个说法是错误的，GraphQL 并没有提供这个能力，这个功能需要你自己去实现。而这种实现——只要是写过足够长时间后端的人都明白，是要付出额外的资源才能实现的。说白了吧，后端一股脑的把所有属性都扔给前端，绝不是因为这种方式有多美好，而是在大多数情况下，权衡了人力资源，开发时间等种种要素后，这种丑陋的方式是成本最低的方案。所以才会流传最广。
说到底吧，GraphQL 目前只是解决了前后端之间的协议问题。对后端早就存在的陈年弊病。没有任何帮助

[jy02201949]

你们谁跟 Livid 告的状，把我心爱的汤米.柠檬给封了，要不然这么热闹的帖子，他这种自带爬虫属性的谦谦君子怎么可能不出现，你们赔我的“那个男人”

[wentaoliang]

@StarkWhite 新项目最开始就按照这个设计还好一点，但对我们来说依旧很麻烦因为有的接口输出字段有几十个，而且里面同一个字段在不同场景下的值还有复杂的逻辑，甚至和其他值有耦合。如果只是 curd 这种接口我觉得可以，复杂场景下但是能把业务代码写的合理就已经很有挑战了，还要在去关心 graph。。。

[StarkWhite]

@jy02201949 你们一口一个“那个‘男人‘’”，说得好像见过他本尊似的 /狗头

[StarkWhite]

@monkingame 有道理，不过自己封装一个，很可能没 GraphQL 火啊，那学习成本不是更高嘛？

[nigelvon]

@abcbuzhiming 那要看你怎么定义能力了，没有 graphQL 的协议支持，后端能知道前端需要哪些字段么？

[StarkWhite]

@karllynn 下岗说得太过了，没这么夸张吧，还是要后端做一些工作的

[jy02201949]

@StarkWhite #87 住口！！！那个男人需要见过吗！！！那犀利的舌战群儒技巧，那独树一帜开发不易求 star 的口吻，加上产品力宇宙超群 apijson，这样的男人仅仅活在想象里就已经是传说了好吗！！！

[StarkWhite]

@jy02201949 老哥，猛！

[rockyou12]

除了 node 写后端的真的有人用了这个？我们后端主要用 springboot，我是没看出来这东西比直接自动生成的 swagger 文档方便再哪，而且我找了半天，也没搞懂这东西怎么快速和 dto 做映射，怎样和 sql 映射？

[StarkWhite]

@jy02201949 对啊，真是过混，哦我亲爱的上帝，真想用皮鞋狠狠地踢他们的屁股 /狗头保命

[StarkWhite]

@rockyou12 Schema 和 Type 就是文档了，会直接在 GraphiQL 工具上展示。Type 就相当于 DTO，在 resolver 里映射

[StarkWhite]

看了下大家呼声很高的那个老哥账号还是在的，说不定是怕咱钓鱼，躲在暗中默默观察呢 /滑稽
https://www.v2ex.com/member/TommyLemon

[StarkWhite]

@monkingame 老项目可以用 GraphQL 做中间层，resolver 里调用原来的 RESTful API

[abcbuzhiming]

@nigelvon 当然能啊，说到底 graphQL 只是协议而已，天下又不是只有它一种协议。它仅仅是回应了大家对 REST 的不满

[dcoder]

不能理解"GraphQL 就是把 SQL 弄到前端去", 就是没理解 GraphQL 这个沙雕 idea 的本质.
这样说吧, 从广义上讲, 给前端提供个有一定表现力的 query DSL...
这个方案的隐形代价是很大的! 除非你后端专门为这个 query DSL 设计个特别的数据库.
不然没有魔法能保证你的查询效率, 你们支持 GraphQL 自己慢慢想吧...

[StarkWhite]

@dcoder 你说的查询效率是指 n+1 么？官方也提供了 dataloader 把这个问题解决掉了