大家怎么看马斯克rpc1000+事件？？？

匿名用户 发表于 2022-11-15 11:10:56
（利申：我讨厌马应龙，以下就事论事）

not exactly true. 他上来回复马应龙说0个RPC，首先这就是杠精上头，RPC从狭义来说是0，但是马应龙的意思就是app启动期远程请求数据过多

他没上来就说0，只是说老板说的不对，后边解释了很多。

匿名用户 发表于 2022-11-15 13:53
他没上来就说0，只是说老板说的不对，后边解释了很多。

我用词不当，不是上来就说

但是这句 "Zero. The apps don't make RPC calls." @ Eric Frohnhoefer 是他原话，图片懒得上传了。。。

从对话来看老马上次写code 可能是20年前

匿名用户 发表于 2022-11-15 11:10:56
（利申：我讨厌马应龙，以下就事论事）

not exactly true. 他上来回复马应龙说0个RPC，首先这就是杠精上头，RPC从狭义来说是0，但是马应龙的意思就是app启动期远程请求数据过多

首先Eric没有上来就说rpc是zero 也没有盯着这一点杠 他有非常中肯的解释app为什么慢

其次关于削减feature这个建议 这个是有数据支持的 而且建议的也不是随便削减 是削减那些根本没什么用的feature 马一龙虽然把Eric开了 不过行动上还是支持了这个建议的（马一龙今天宣布要把推文包括手机机型这个feature给删掉）我不觉得这个建议和super app这个vision是冲突的 去除糟粕 是为了更轻更好的重新出发

还有一点 拿微信启动速度来做比较是不恰当的 微信启动一次 可以一直使用直到你后台退出微信 推特时间线用户可是一直在浏览 动态刷新的 这两个使用场景区别很大 tradeoff也自然会非常不一样

最后 我觉得Eric对出发点不是为了他自己 他不爽马一龙很久了 但是直到这次马一龙公开诋毁推特的技术团队 他没有公开shitposting

graphql只是让前端用起来比较省心而已，本质并没有降低数据库query，对performace有多少影响到底和分别call这些api有多少差距真不好说，马斯克说因为rpc太多导致的速度慢算是product manager级别的理解，不能说全错，但也不严谨。

各位不用洗地了，就说你是fanboys，然后你说啥我都点赞有道理。Musk一开始就没打算好好说话，那为什么要低三下四的惯着他。说得直白点，被fire的20多个人（没错，一共20多个人，包括只在内部slack发表意见的），哪个会担心找不到工作？

雯仔 发表于 2022-11-15 18:34:16
graphql只是让前端用起来比较省心而已，本质并没有降低数据库query，对performace有多少影响到底和分别call这些api有多少差距真不好说，马斯克说因为rpc太多导致的速度慢算是pro

让前端用起来省心是非常非常大的帮助，这个规模的系统，系统设计原则上堆机器>>>提高单机性能。

匿名用户 发表于 2022-11-15 11:21
什么是rpc？

remote procedure call

匿名用户 发表于 2022-11-15 18:10:54
首先Eric没有上来就说rpc是zero 也没有盯着这一点杠 他有非常中肯的解释app为什么慢

其次关于削减feature这个建议 这个是有数据支持的 而且建议的也不是随便削减 是削减那些根本没什么

就我能看到的特性和公开能了解到的数据而言，说twitter的复杂度比微信低一个数量级不夸张。

1000rpc这个，复杂请求后面的关联查询如果有1000这么多，可能还能被理解。但如果出现在首页这么个地方，每次都有1000不管你怎么解释是什么实现，这个大的团队架构设计方面就是很差，而且差得离谱，干掉丝毫不冤枉，而且应当谨慎怀疑这个团队评价体系出来的整体水平。

补充内容 (2022-11-16 13:15 +08:00):
主要还是1000关联的rpc是否属实吧，如果属实，至少感觉很明显后台服务部分粒度分拆过度，而且可能缺少一些业务逻辑的应用层汇聚/缓存/预处理。
feed流因为序列id和内容可以很轻松分离，不应该那么夸张才对。

匿名用户 发表于 2022-11-15 21:01:14
让前端用起来省心是非常非常大的帮助，这个规模的系统，系统设计原则上堆机器>>>提高单机性能。

这种规模的系统还用如此粗放的方式，确实很离谱…单纯从一个技术的角度来看