我正在重新审视 graphql，我试图理解为什么节省往返对开发人员有好处。提出请求的费用这么贵吗？我有网络开发背景。
让我们将标准 REST API 与 graphql API 进行比较。
我需要检索用户的个人信息及其朋友列表。传统的 REST API 可能需要 2 次调用，一次获取个人信息，一次获取好友。
使用 graphql，我可以通过一个请求得到相同的结果。
但作为一名前端开发人员，我希望我的页面有尽可能短的停滞期。我想尽可能快地只渲染页面的一部分，而不是一次性等待我需要的所有信息然后渲染页面。
现在根据我的理解，graphql 的创建部分是为了解决移动应用程序 API 问题。 iOS 应用程序是否有什么东西可以让一次性加载所有数据比并行请求更有利？或者我还有什么遗漏的吗？
所以一般来说，您控制的系统（即后端）内的网络流量很快。向外界发出的请求可能需要 205 毫秒（200 毫秒网络，5 毫秒数据），但在内部可能只需要 6 毫秒（1 毫秒网络，5 毫秒数据）。
如果您想构建应用程序的屏幕，并且需要发出两个 REST 请求，因为第二个请求取决于第一个请求的结果，那么您需要（考虑到这些粗略数字）410ms 来获取所需的数据渲染你的屏幕。
使用 GraphQL（或任何其他整合数据的网关层），您将在略高于 212 毫秒的时间内获得所有内容（GraphQL 服务器延迟 200 毫秒 + 每个内部调用 6 毫秒）。
在您可以并行发出所有请求的情况下（即它们不依赖于其他请求的数据），性能优势并不那么明显，但您会发现这些情况实际上非常罕见，因为您的应用程序的复杂性不断增加。
GraphQL 的一般经验法则是，您的初始查询会获取足够的数据以使页面正常运行，如果有不太重要的内容，您始终可以使用另一个查询来获取该内容。
除了性能优势之外，让移动设备发出更少的网络请求对于电池寿命来说也是一个巨大的胜利。网络使用成本高昂，应尽可能避免。
在使用 GraphQL 而不是 REST API 之前，需要了解 GraphQL 相对于 REST 的优势
GraphQL 是一种查询语言 它使用您定义的类型系统
GraphQLIntGraphQLStringcustomType休息
GraphQL
query == result