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