我在我们再看一下graphql，我试图理解为什么节省往返是开发商的利益。 正在请求如此昂贵的费用是多少？ 我是从一个Web开发背景的。
让我们比较标准的REST API与graphql API。
我需要检索用户的个人信息，以及他们的朋友名单。 传统的REST API可能需要2个呼叫，一个获得个人信息，以及一个让朋友们。
随着graphql，我得到一个请求相同的结果。
但作为一个前端开发者，我想我的页面有最短的停滞期。 我想渲染只有尽可能快的页面的一部分，而不是等待我需要一鼓作气然后渲染页面的所有信息。
现在，从我的理解，graphql被部分创建解决移动应用程序API的问题。 是否有一些关于iOS应用，使得它更有利于在一次加载所有数据，而不是并行请求？ 还是有别的东西，我失踪？
所以一般来讲，你控制系统内的网络流量（即后端）快。 使请求采取205ms（200ms的网络，5ms的数据），到外面的世界，可能只需6毫秒（1毫秒的网络，5ms的数据）在内部。
如果你想建立自己的应用程序的屏幕，并且需要做两个REST请求，因为第二个取决于第一个结果，你看（考虑到这些数字原油）410ms得到你需要渲染你的数据屏幕。
随着GraphQL（或整合数据的任何其他网关层），你会得到略高于212ms一切（200ms的延迟到GraphQL服务器+ 6ms的每个内部调用）。
在情况下，您可以让所有并行的请求（即不依赖于其他请求的数据），性能优势不是很明显，但你会发现，这些情况是因为实际上是相当罕见您的应用程序的复杂性增加。
与GraphQL一般的经验法则是，你的初始查询获取足够的数据页是功能性的，如果有，你可以随时获取与另一个查询不太重要的内容。
除了性能优势，让移动设备使更少的网络请求是一个巨大的胜利，当涉及到电池寿命。 网络使用价格昂贵，而且应避免尽可能。
使用的，而不是REST API GraphQL之前需要理解GraphQL超过REST的好处
GraphQL是一种查询语言，它使用您定义的类型系统GraphQLInt ， GraphQLString ， customType ...
休息
GraphQL
query == result ，性能更好 
