与RESTful相比,GraphQL GET请求的响应时间较慢

天下没有免费的午餐。

GraphQL提供了许多有用的特性,但这些特性总是会带来一些开销。尽管REST端点可以有效地从某个源提取数据并将其返回到客户端,即使是对于相对较小的数据集,GraphQL也可以 有 进行一些额外的处理以解决和验证 每个字段 在回应中。更不用说解析和验证请求本身所需的处理了。这种开销只会随着返回数据的大小而增大。

如果要向REST端点引入其他功能(请求 和 响应验证、对部分响应的支持、对单个响应字段进行别名的能力等)镜像GraphQL后,您会看到两者之间的性能差距缩小。尽管如此,这还是有点像苹果和橙子的比较,因为GraphQL服务会经历某些动作,因为这就是 spec 说要做。

TLDR:您的REST示例很简单,也不那么复杂

在灯塔里,它正在创造一个 AST 用于解析graphql请求和模式。然后,它会传递所有指令,以此类推,以了解您试图做什么。它还必须验证您的查询,看看您是否可以在模式上实际运行它。

根据您在应用程序中如何定义它,它需要经过很多步骤。然而,这可以通过多种不同的方式来减少,比如对graphql的解析 schema can be cached 你可以 cache the result 使用 deferred fields (可能不会加快这个例子的速度)。你可以在 performance section 医生的名字。

如果您使用的是某种REST标准,并且REST还必须解析数据,那么您没有指定REST的设置方式。如果您添加了更多的特性,那么将有更多的代码需要运行,因此加载速度会更高。

从Lighthouse v4开始,我们通过延迟加载模式中最少需要的字段和类型,显著提高了性能。这将带来3到10倍的性能提升,这取决于模式的大小。

对于这样一个简单的查询,您可能仍然无法击败任何一个REST端点。Lighthouse将开始关注更多跨多个关系连接的嵌套查询。

尝试启用 opcache 在服务器上。这将我的gql响应时间从200ms减少到20ms