dcoder

Django request 会对应到数据库的 transaction. 是数据库帮你搞定的, 基本只有数据库才是 stateful 的.

难道不该是 gRPC 配 Protocol Buffer, webSocket 配 JSON?

@Mithril
GraphQL 的问题是, 它定义了某些高级的可以演义的动态 '语义' 和 '逻辑'.
没有任何成熟的机制，可以保证这些特性被高效可靠地实现.
所以, 其实要做聚合多个 micro service 的查询 api, 直接用死死的 function call 一样的 API 反而简单可靠高效 -- 比如就用 RESTful 之类就行了.

@StarkWhite
我不觉得有什么很好的方案能解决效率问题，因为 GraphQL 要达到的黑魔法一样的效果，后端的支持必然会比较粗糙.

我们看观点，不看出处. 你引用的这段，看着真的挺 YY 的. 而且我没听说过, micro service 最好是要配套 GraphQL 的.

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

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

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

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

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

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

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

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

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

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