我正在重新审视 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 是一种查询语言，并且
它使用您定义的类型系统GraphQLInt、GraphQLString、customType...
休息
GraphQL
query == result，性能更好【讨论】：