这是一个创建于 1835 天前的主题，其中的信息可能已经有所发展或是发生改变。
GraphQL 通过帮助我们构建能够将客户端用例编译为服务器资源的服务器引擎，重新定义了客户端服务器边界。持久查询使这更容易理解，本质上是客户端生成的服务器资源。 GraphQL 在客户端级别上尤其受欢迎！将 GraphQL 片段与我们在现代前端框架中看到的组件模式配对时，绝对是很棒的做法。同样，与持久查询配合使用，GraphQL 客户端开发人员的体验可能会非常令人难以置信的棒。
https://apisyouwonthate.com/blog/lets-stop-building-apis-around-a-network-hack
 |
1
StarkWhite OP 原文看不懂的话可以看下这个翻译 https://my.oschina.net/javayou/blog/3126863
|
 |
2
crclz 2019-11-20 16:22:59 +08:00
NoSQL 能避免 Chatty 的通信，消除累计的往返延迟（一次往返 vs n 次往返）。这是一个很重要的点。
但是，更重要的是，GraphQL 让数据的请求的粒度更加细化：一个实体，一个请求。例如，我查询了一个订单信息，订单有多个商品。大部分 GraphQL API 会被设计成向数据库发起多个查询，分别获取商品，或者先获取商品 id 数组，再 batching ；而不是关联查询。在传统的架构下，这是性能的浪费。但是如果假如有 redis 缓存，那么这种细粒度的设计就赋予了向 redis 查询数据的能力：拿到商品 id 数组后，先查 redis。 当然，这种细粒度的设计也简化了查询接口的开发，降低了前后端的协调成本，这我觉得是非常重要的点。 |
|
3
StarkWhite OP @crclz 是的，有利有弊，但总体利大于弊，减少沟通成本、提高开发效率
|
 |
4
zicjin629 2019-12-23 18:31:37 +08:00
"先获取商品 id 数组，再 batching ；而不是关联查询。" 这个你不用 GraphQL 完全可以做到吧？完全只是个思路选择。事实上很多不用 GraphQL 的人就是这么查询的。
|
Select Language