ios - Graphql 和往返。这只是一个 ios 应用程序问题吗？

Question

我正在重新审视 graphql，我试图理解为什么节省往返行程对开发人员有益。提出要求的成本这么贵吗？我来自网络开发背景。

让我们比较一下标准的 rest api 和 graphql api。

我需要检索用户的个人信息，以及他们的好友列表。传统的 rest api 可能需要 2 次调用，一次获取个人信息，一次获取好友。

使用 graphql，我可以通过一个请求获得相同的结果。

但是作为前端开发者，我希望我的页面有尽可能短的停滞期。我希望尽可能快地只呈现页面的一部分，而不是等待一次性获得我需要的所有信息然后再呈现页面。

根据我的理解，graphql 的创建部分是为了解决移动应用程序 api 问题。与并行请求相比，ios 应用程序是否有一些东西可以使一次加载所有数据更有用？还是我还缺少其他东西？

Answer 1

所以一般来说，您控制的系统(即您的后端)内的网络流量很快。一个到外部世界可能需要 205 毫秒(200 毫秒网络，5 毫秒数据)的请求，在内部可能只需要 6 毫秒(1 毫秒网络，5 毫秒数据)。

如果你想为你的应用构建一个屏幕，并且需要发出两个 REST 请求，因为第二个取决于第一个的结果，你正在查看(给出这些粗略的数字) 410 毫秒获取渲染屏幕所需的数据。

使用 GraphQL(或任何其他整合数据的网关层)，您可以在略高于 212 毫秒的时间内获得所有内容(GraphQL 服务器延迟 200 毫秒 + 每次内部调用延迟 6 毫秒)。

在您可以并行发出所有请求的情况下(即它们不依赖于来自其他请求的数据)，性能优势并不那么明显，但您会发现这些情况实际上非常好随着应用的复杂性增加，这种情况很少见。

GraphQL 的一般经验法则是您的初始查询获取足够的数据以使页面正常运行，如果有不太重要的内容，您始终可以使用另一个查询获取。

除了性能优势之外，让移动设备发出更少的网络请求在电池生命周期方面也是一个巨大的胜利。网络使用成本很高，应尽可能避免。