Graphql 和往返.这只是一个ios应用程序问题吗? [英] Graphql and round trips. Is this just an ios app issue?

问题描述

我正在重新审视 graphql，并试图理解为什么节省往返行程对开发人员有益.提出请求的成本是否如此昂贵?我来自网络开发背景.

I'm taking another look at graphql, and I'm trying to understand why saving round trips is a benefit to developers. Is the cost of making a request so expensive? I'm coming from a web development background.

让我们将标准的 rest api 与 graphql api 进行比较.

Lets compare a standard rest api with a graphql api.

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

I need to retrieve a users personal info, and a list of their friends. Traditional rest api might require 2 calls, one to get the personal info, and one to get the friends.

使用 graphql，我通过一个请求得到相同的结果.

With graphql, I get the same results with one request.

但作为前端开发人员，我希望我的页面具有尽可能短的停滞期.我想尽可能快地只渲染页面的一部分，而不是一次性等待我需要的所有信息然后渲染页面.

But as a frontend developer, I want my page to have the shortest possible stagnant period. I would like to render only a portion of the page as fast as possible, rather than wait for all the information I need in one go to then render the page.

现在据我所知，graphql 部分是为了解决移动应用程序 api 问题而创建的.与并行请求相比，ios 应用程序是否有一些东西可以使一次加载所有数据更有益?或者还有什么我遗漏的吗?

Now from my understanding, graphql was partly created to solve mobile application api issues. Is there something about ios apps that makes it more beneficial to load all the data at once, as opposed to parallel requests? Or is there something else that I'm missing?

推荐答案

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

So generally speaking, network traffic inside the system you control (i.e. your backend) is fast. A request that make take 205ms (200ms network, 5ms data) to the outside world, might take just 6ms (1ms network, 5ms data) internally.

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

If you want to build a screen of your app, and that requires making two REST requests because the 2nd depends on the result of the first, you're looking at (given these crude numbers) 410ms to get the data you need to render your screen.

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

With GraphQL (or any other gateway layer that consolidates the data), you'd get everything in slightly over 212ms (200ms latency to GraphQL server + 6ms for each internal call).

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

In scenarios where you could make all your requests in parallel (i.e. they don't depend on the data from other requests), the performance benefits aren't quite as apparent, but you'll find that these situations are actually pretty rare as the complexity of your app grows.

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

The general rule of thumb with GraphQL is that your initial query fetches enough data for the page to be functional, if there's less important content you can always fetch that with another query.

除了性能优势之外，让移动设备发出更少的网络请求也是电池寿命方面的一大优势.网络使用成本高昂，应尽可能避免使用.

Alongside the performance benefits, letting mobile devices make fewer network requests is a big win when it comes to battery life. Network usage is expensive, and should be avoided as much as possible.

这篇关于Graphql 和往返.这只是一个ios应用程序问题吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！