都 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 ？

[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 的官方文档写得非常简单，甚至看完了可能也不够写完一个项目