首页   注册   登录
 dcoder 最近的时间轴更新

dcoder

V2EX 第 28237 号会员,加入于 2012-10-16 02:59:17 +08:00
Vim 的 :Ex 命令的问题. 用来代替 NERDTree
Vim  •  dcoder  •  2017-06-23 16:50:14 PM  •  最后回复来自 dcoder
11
Time Machine 的全盘还原
macOS  •  dcoder  •  2016-03-04 02:27:23 AM  •  最后回复来自 dcoder
4
vi (not vim) 怎样直接使用 Vundle?
问与答  •  dcoder  •  2015-07-13 11:29:34 AM  •  最后回复来自 jsfaint
17
cmder 快捷键的问题
程序员  •  dcoder  •  2015-07-08 06:01:52 AM  •  最后回复来自 dcoder
8
Nodyn:让 Node.js 应用运行于 JVM
Node.js  •  dcoder  •  2014-03-05 13:00:44 PM
小米路由是 OpenWRT? 不用开源?
分享发现  •  dcoder  •  2015-04-29 10:40:57 AM  •  最后回复来自 maryjeck
17
Python RQ (Redis Queue) 0.4.0 如何?
RQ  •  dcoder  •  2014-11-25 14:40:19 PM  •  最后回复来自 stillzhl
17
gdb, Eclipse CDT for Mavericks
macOS  •  dcoder  •  2013-10-25 02:04:02 AM  •  最后回复来自 luikore
1
47个web框架效能比较
Velocity  •  dcoder  •  2014-06-07 20:34:46 PM  •  最后回复来自 lang1pal
15
为什么V2EX login没有使用SSL
问与答  •  dcoder  •  2013-02-01 03:51:36 AM  •  最后回复来自 xinhugo
11
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 自己慢慢想吧...
本来 SQL 还有优化 SQL 就是一堆问题了,
现在好,来个更沙雕的 idea,把 SQL 弄到最前端去, 直接暴露在空气中随便弄...
好像所有的查询优化都可以魔法搬自动解决一样, 实在太脑残了
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1597 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 20ms · UTC 23:57 · PVG 07:57 · LAX 16:57 · JFK 19:57
♥ Do have faith in what you're doing.