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

你们这样确实会给辣个蓝人带去了不少流量

@StarkWhite 基本上每种语言也都是实现了自己的 dataloader
https://github.com/graphql/dataloader

@Les1ie 生产环境把自省关掉好了

@alphatoad protobuf 是 rpc 协议，facebook 也有个 thrift，都和 graphql 不是一类的项目。。。

@karllynn 首先 AI 得理解产品需求，现在担心还为时尚早哈哈

我们公司全套后端都上了 graphQL~ 有兴趣的可以来围观下 https://yangjunhui.monster/t/589523#reply0

@zjsxwc 这种是简单业务，几乎没有额外消耗的，多一个字段少一个字段并没什么差别。但是稍微复杂点的业务都不是一个查询就能查出来的，这时候前端描述的协议就显得很有价值了。

了解不深，诚恳希望有人给正经解释一下，graphql 和普通的开发中的一个查询接口里面接收查询条件与回显字段 这两者之间的区别有多大？
以及这东西后端开发怎么去优化性能？明明只查索引字段的数据，我却要把库里的所有字段都捞出来？ 不懂啊。

我举个例子，一个查询账单的接口，同时还要展示每条明细数据的所属人的中文名，那么用户信息是从其他系统的 api 接口获取的。
后端开发会把分页数据查询出来后，把用户 id 捞出来一个集合去 api 接口把用户信息查出来，再把用户信息的中文名塞回到最终结果数据中。
这样一个场景在引入了 graphql 之后该怎么去做呢？ 不说达到更好的效果，可以达到差不多相同的效果与效率吗？

@ysp 赞

@rizon dataloader 就是这个原理啊

@IsaacYoung 香蕉君是谁？网红吗？

感觉华而不实

不管是什么技术，总有个适用范围。没什么东西是万能的。
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 也有一大堆的缺点，但是你的需求如果可以正好避开这些缺点，同时它擅长的东西也是你想要的，那么没什么理由不用它。

"GraphQL 和 ElasticSearch 的 Query 比较类似，优点不在于优化性能"
大家理解 GraphQL 暗含了多少查询性能的坑了没?

我还是那句话, 如果有天出现了成熟的 GraphQL Database,
专门做给 GraphQL 查询用的, GraphQL 可以一用,
但是, 本质上就是另外一个专门的 database with specific query APIs, 就像 ElasticSearch

然而人家 ElasticSearch 同时提供了 database 和 Query DSL -- 它复杂的 JSON API 其实已经是 DSL 了.
GraphQL 提供了什么? 一个看起来美妙的 Query DSL 和 ... ... ?

可以看看知乎这个帖子里 2018~2019 的讨论

"GraphQL 的每一个实体背后可能对应着不同的数据库甚至不同类型的存储集群，后端集群间的海量数据自由 join，基本还是无解的，只能搭专门的集群处理，这个不清楚 FB 是否有什么黑科技，我严重怀疑 FB 自己也没做到全业务查询"

"FB 自己也没有黑科技...最近在做广告数据整合，FB 的广告相关 API 基本是一步一个 bug， 基础的时间段 filter 都有问题。传统 restapi 我好歹还可以看文档知道到底支持哪些 API 请求，Facebook 的 graphql 经常会出现明明符合查询字段，返回的确实毫不相关数据的情况"

"这个事情到底由谁来做？ GraphQL 的利好主要是在于前端的开发效率，但落地却需要服务端的全力配合"

GraphQL 玩玩可以. 认真做个大系统? 算了吧.

知乎帖子 <GraphQL 为何没有火起来?>
没有认证, 现在不能发 URL...

@jss 但是前端可以为所欲为啊 /滑稽

@dcoder 知乎那个帖子都是 16 年前的了，现在都 9102 年了，性能问题也有 dataloader 来解决了