2022-11-18 17:24
可以的
2022-11-18 09:06
马斯克懂不懂GraphQL不重要,重要的是TwitterApp太慢了
2022-11-17 12:22
看到 GraphQL 身影,感觉 马斯克说的 有那么几分道理。
2022-11-15 12:52
graphql是可以合并请求的,讲道理可以提高响应速度的。还有什么批量处理一般都是异步的吧,怎么会慢?一般慢要么是服务器端处理速度慢,要么就是前端频繁的串行发送大量请求
2022-11-17 12:27
请求是合并了,但是该发起 rpc 一个都没少,反倒是因为这种高效的服务聚合能力。让人们更加肆无忌惮的 编写各种微服务。最后的结果就是 马斯克说的那样。 一个简单的服务聚合聚合了大量的服务,发起了过多的 rpc。 这仅仅是开发效率的提升,完全没有考虑性能。
2022-11-17 13:08
哎呀,灵活不一定会导致滥用,这两个分明就是两件事,graphql解决的是需求变化的快速迭代能力,前端改页面可能就不用去找后端同学改代码了,twitter的聚合了1000个rpc的请求分明就是开发人员应付差事导致的技术债,是开偷懒的结果,这个锅graphql背有点不合适了。
2022-11-18 11:41
“灵活不一定会导致滥用” 你你说了不一定,那也就是说也可能被滥用。 这里面最关键的问题是采用这种过滤灵活的技术之后你很可能在管理上无法控制具体的人。规范会被沦为一张废纸。 twitter 里面技术发展怎样咱们外人确实不知道,但如果一个技术过于灵活。很可能将人引入另外一个极端,1000个 rpc 是有可能的。
2022-11-18 14:42
所以说,滥用并不是graphql造成的,及时使用restful也解决不了滥用问题,而快速迭代必然导致沟通不畅,滥用的土壤是管理沟通和迭代成本,既然restual和graphql都无法避免滥用和低效性能,那这1000个rpc的出现就不是个技术问题了,是随着时间推移代码逐渐陈化的必然结果,也就是那个被裁的twitter工程师所说的技术债,就必须由公司专门的投入资源和成本来集中解决和优化,相对来说,使用graphql更好一点,起码迭代更快。
2022-11-15 08:16
GraphQL 根本不好使,太复杂,学习成本高,另外所谓的按需加载似乎是空中楼阁,因为要实现这点,需要从头到尾都支持,但是大系统都是很多api嵌套的,往往是做不到。
2022-11-15 09:45
同意,复杂性过高,需要前后端同时从底层开始支持,而且一旦这样设计,以后很难再抛开GraphQL改用其他。充分的灵活性也是双刃剑,意味着缺少约束性,很轻易就会变得糟糕,难以维护。陡峭的学习曲线,又不能快速推广铺开。所以这玩意看起来很迷人,确实也很迷人,但是我就不敢用
2022-11-17 13:13
那1000个api的聚合请求可能证明了这块业务本来就很复杂,而且堆积了6年的逻辑都纠缠在里面,进一步加剧了复杂性,twitter需要的是先仔细评估这些api的作用,找出能够合并的请求和可以删除的请求,梳理出流程和调用关系,然后用graphql重写这部分逻辑
2022-11-14 21:50
马斯克把所有服务端项目用.NET 7.0 重构,哈哈哈😁
2022-11-15 09:35
真的假的?
2022-11-14 16:30
美国挺开放啊,一个花臂女也能当技术主管。
2022-11-14 14:24
GraphQL 好用的代价 就是变慢啊
2022-11-14 15:31
难道是为了更少的数据传输量牺牲响应处理时间? 换句话说是用时间换空间?用算力换空间?
2022-11-14 14:11
GraphQL 确实是一个糟糕的设计
2022-11-17 12:29
GraphQL 设计是一个优秀的设计,但是滥用它的人是一个糟糕的工程师。
2022-11-14 11:51
这个 kiss my ass elon 是发出邀请的意思吗?
回复 @
{{emojiItem.symbol}}
返回顶部
顶部