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

我再次看看graphql，并试图理解为什么节省往返旅程对开发人员有利。请求的成本如此昂贵？我来自Web开发背景。Graphql和往返。这只是一个iOS应用程序问题？

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

我需要检索用户个人信息和他们的朋友列表。传统的休息API可能需要2个电话，一个获取个人信息，另一个获取朋友。

使用graphql，我得到了一个请求相同的结果。

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

现在从我的理解中，graphql部分是为了解决移动应用程序API问题而创建的。是否有关于ios应用程序的一些信息，使其更有利于一次加载所有数据，而不是并行请求？还是还有别的东西我失踪了？

来源

2017-02-27 l2silver

因此，一般来说，您所控制的系统内部的网络流量（即，你的后端）很快。向外界请求205ms（200ms网络，5ms数据）的请求在内部可能只需要6ms（1ms网络，5ms数据）。

如果你想建立自己的应用程序的屏幕，并且需要做两个REST请求，因为第二个取决于第一个结果，你看（考虑到这些数字原油）410ms来获得你需要渲染你的屏幕的数据。使用GraphQL（或合并数据的任何其他网关层），您可以将所有内容略微超过212毫秒（对于每个内部调用，GraphQL服务器的延迟时间为200毫秒+ 6毫秒）。

在情况下，您可以让所有并行的请求（即不依赖于其他请求的数据），性能优势不是很明显，但是你会发现，这些情况实际上是随着应用程序复杂性的增长，这种情况非常罕见。

与GraphQL一般的经验法则是，你的初始查询获取足够的数据页是功能性的，如果有，你可以随时获取与另一个查询不太重要的内容。

除了性能优势，让移动设备使更少的网络请求是一个巨大的胜利，当涉及到电池寿命。网络使用费用很高，应尽可能地避免。

来源

2017-02-27 12:54:58

谢谢，这正是我一直在寻找答案！ – l2silver

使用，而不是REST API GraphQL前一个需要通过REST

GraphQL了解GraphQL的好处是一种查询语言和它使用您定义的类型系统GraphQLInt，GraphQLString，customType ...

REST

多次往返 - 慢
超载数据
许多端点

GraphQL

1端点
陈述句：类型，查询，突变你一个电话
没有underfetching，希望数据的
确切形状没有数据的超取
query == result，更好的性能nce

来源

2017-02-27 06:16:49

嘿pOk8，据我所知，这些都是一些graphql和休息之间的差异，但我还是不明白就是为什么越来越往返是一件坏事，如果这意味着获得一些信息更快。 – l2silver

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

回答

相关问题