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

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

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

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

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

好像 openstack 里 fileds 的用法...

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

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

并不好用+10086

去年用的 nestjs+graphql，还要

辣个男人居然还没有来

没有银弹

说通俗一点，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 可以过滤掉不需要的字段，减少网络带宽。

虽然减少网络带宽，但服务器查询执行业务的消耗仍旧不变，而且对于大部分业务来说，前端获取的数据越多越好，很少有人会为了省那点带宽干这事情。

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

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

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

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

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

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

用过，不好用。

为啥不用 protobuf

会用，但没必要用

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

@Cabana 是这个吧？
t/583356

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

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

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

@VDimos wo wei graphql dai yan

我也给 graphql 喂袋盐，哈哈

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

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

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

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

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

@razertory 什么鬼？谁完爆 GRAPHQL ?

GraphQL，后端甩锅前端的工具

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

并不觉得好用

@catcalse 就你皮~

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

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

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

@

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