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次调用，其中1次获得个人信息，而1次获得朋友.

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?

推荐答案

通常来说，您控制的系统(即后端)中的网络流量非常快.向外部发送205ms(200ms网络，5ms数据)的请求可能在内部仅花费6ms(1ms网络，5ms数据).

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请求，因为第二个依赖于第一个结果，那么您正在查看(鉴于这些粗略的数字)410ms即可获取渲染屏幕所需的数据.

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(或整合数据的任何其他网关层)，您将在212ms内获得所有信息(到GraphQL服务器的延迟为200ms，每个内部调用的延迟为6ms).

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屋！