阅读数:24381 发布于:2019 年 1 月 21 日 09:57

更多 前端、语言 & 开发、JavaScript 相关课程,可下载【 极客时间 】App 免费领取 >

评论 (15 条评论)

发布
用户头像
说是前后端不用再沟通了,我怎么觉得这样反而前后端必须沟通才能使用了呢,要不我怎么知道后端资源的每个字段和关系呢,如果用restful,至少通过url的能读懂这个接口到底是做什么的,看下返回结果就知道资源结构,通过include 可以实现一个接口调用多个关联资源。而且restful后端只需要关注某个资源和联系,感觉用了这个都耦合到一起了。
2019 年 12 月 19 日 16:12
回复
用户头像
GraphQL 还是可以的。
虽然本质上都是资源的获取和操作,但是在一定程度可以提高前端的开发效率。
当然,得让后端先把模型关联好。
有点类似前端直接写SQL传给后端,但是更安全。
且关联模型由后端还是控制。
当然,门槛相对于REST来说,还是有点颇高,期待各大厂家能把多讲讲实战经验以及力所能及的开源,有利于行业的发展。
2019 年 05 月 13 日 15:25
回复
用户头像
REST本意是资源获取,没有像RPC一样有服务调用的意味。GraphQL定义为一种查询语言,像另一位同学说的“SQL前移”,本质上还是资源获取,也没有看到服务调用的意味。个人拙见,两者没有什么本质变化,只是形式变了而已,至于API稳定的问题,那不是技术导致的,而是设计问题,就像现实中拿REST实现服务接口不在少数吧。
2019 年 05 月 04 日 20:43
回复
用户头像
话说,怎么在InfoQ 上写文章呀?
2019 年 02 月 20 日 13:58
回复
还是 知乎/cnblogs 好用
2019 年 02 月 20 日 14:07
回复
用户头像
当年用ajax分布加载不就是为了让页面先出来,数据分步填入么,GraphQL这样等统一返回,一个大页面要等我后台20个sql查完了再一起出来?感觉回到了10多年前的老路啊
2019 年 01 月 29 日 11:55
回复
用户头像
GraphQL的意义是将后台数据模型,以一种安全的方式暴露给前端进行定制化查询,模型统一后可以减少后台的各种定制查询接口。
2019 年 01 月 29 日 11:02
回复
用户头像
直接拿到关联数据的解决方案, 而不是一直传各种主键
2019 年 01 月 27 日 13:08
回复
用户头像
令人激动,跃跃欲试
2019 年 01 月 27 日 11:08
回复
用户头像
没看出优势在哪里
2019 年 01 月 21 日 15:55
回复
用户头像
好, 假设真的REST API数量暴增了, 然后通过GraphQL能解决吗? GraphQL的API数量倒是减少了, 但数据中携带的元数据的复杂性是不是也会暴增了? Essential Complex不会因为实现方式的改变而减少, 只会从一个地方转移到另外一个地方。 尝试通过改变实现方式来减少Essential Complex,注定会徒劳无功。
2019 年 01 月 21 日 14:30
回复
前端看起来就一个“接口”,看起来可不是简单多了,哈哈。在他们眼里,下一步让前端直接传递sql更省事。
2019 年 01 月 21 日 14:37
回复
用户头像
"他们的遗留 REST API 数量暴增,变得十分复杂;"
"GET https://inbox.indeed.com/api/getConversationCount"

嗯,所以作者把RPC当做REST API了, 所以“他们的REST API“暴增了。
2019 年 01 月 21 日 14:27
回复
用户头像
文中举了个例子,"在使用 GraphQL 时,上面的这些请求可以被包含在单个查询和单个请求中。query HomePage",RestAPI也可以做到,“GET /xxx/api/homePage"。 所以GraphQL的优势在哪里?
2019 年 01 月 21 日 10:14
回复
RestAPI不仅指service 路径的pattern, 每个api都应该是独立而稳定的。 homePage是一个不稳定的resource, 会根据前端业务的变化而变化, 不应该在后端提供一个这样的api。
2019 年 01 月 22 日 11:42
回复
没有更多评论了