发布于 2026-01-06 3 阅读
0

为什么选择 GraphQL?面向开发者的 API 演进指南;DEV 全球展示挑战赛,由 Mux 呈现:展示你的项目!

为什么选择 GraphQL?面向开发者的 API 演进指南

由 Mux 主办的 DEV 全球展示挑战赛:展示你的项目!

大家好,我是 Maneshwar。我目前正在开发FreeDevTools online,这是一个**汇集所有开发工具、秘籍和 TLDR 的平台**——一个免费的开源中心,开发者可以在这里快速找到并使用各种工具,而无需在互联网上到处搜索。

在 API 领域,有两种技术一直占据着讨论的主导地位:GraphQL 和 REST。

两者各有优缺点,但了解何时以及为何使用其中一种而不是另一种,可以对您的开发工作流程产生巨大的影响。

本文深入探讨了GraphQL 存在的原因、何时使用它以及它与 REST 的比较——所有这些都用简单的术语和现实世界的例子进行了解释

GraphQL 的独特之处是什么?

GraphQL 由 Facebook 于 2012 年创建,并于 2015 年开源,其目的是为了解决 REST API 的常见低效问题

它不仅仅是另一个 API 标准;它是一种查询语言,允许客户端请求他们需要的确切内容,不多也不少。

这样就消除了 REST API 中常见的过度获取(获取过多数据)和获取不足(获取不足数据)的问题。

以下是GraphQL成为开发者梦想的原因:

  • 精确数据获取:客户端可以精确指定他们需要的数据,从而减少过度获取和获取不足的情况。
  • 单一端点:与通常需要向不同端点发出多个请求的 REST 不同,GraphQL 在一个请求中聚合来自多个来源的数据。
  • 强类型模式: API 具有自文档化特性,并采用定义良好的模式,从而确保稳定性和可预测性。

这样一来,应用程序运行速度更快维护更轻松,整体上也为开发者带来了更好的体验

GraphQL 的主要特性

  1. 高效的数据获取:客户端可以精确指定所需的数据,从而减少不必要的数据传输。
  2. 单一端点:与使用多个端点的 REST 不同,GraphQL 使用单个端点来处理所有查询。
  3. 强类型模式:GraphQL API 由模式定义,从而确保类型安全性和自文档化。
  4. 实时数据:支持订阅实时更新。
  5. 数据聚合:轻松地将来自多个来源的数据合并到单个响应中。

何时应该使用 GraphQL?

GraphQL 并非万能灵药,但在某些情况下表现出色。

以下是一些 GraphQL 可以显著提升API 性能和灵活性的实际应用案例:

移动和 Web 应用的性能优化

  • 避免过度获取或获取不足:使用 REST 时,您经常会获得比您需要的数据更多的数据(过度获取),或者需要发出多个请求才能获得您需要的所有数据(获取不足)。
  • GraphQL 通过允许您在单个查询中仅请求所需的字段来解决这个问题。
  • 更快的加载速度:GraphQL 通过减少通过网络传输的数据量来提高性能,尤其适用于移动应用和低带宽环境。

实时仪表盘

  • GraphQL 支持订阅,允许客户端在数据发生变化时接收实时更新。
  • 这非常适合聊天应用、实时仪表盘或通知等应用。

API聚合与版本控制

  • 管理多个 API?与其费力地维护不同的 REST 端点,不如公开一个 GraphQL API,从各种服务中提取数据。
  • 此外,与 REST 严格的版本控制不同,您可以在不破坏现有客户端的情况下演进模式。

优化性能并降低延迟

  • GraphQL 消除了过度获取(获取不必要的数据)和获取不足(完成任务需要多次请求)。
  • 这样可以加快响应速度降低带宽使用率,使其非常适合对性能要求极高的应用。

开发者体验

  • 自文档化:GraphQL 的模式充当文档,使开发人员更容易理解和使用 API。
  • 强大的工具Apollo ClientGraphiQL等工具提供卓越的开发者体验,包括自动完成、错误高亮显示和查询测试。

GraphQL 与 REST:主要区别

虽然 REST 应用广泛且易于理解,但 GraphQL 提供了一种更现代、更灵活的API 设计方法。让我们来详细了解一下它们的一些关键区别

特征 休息 GraphQL
数据获取 多个端点,通常会导致过度获取或获取不足。 单端点设计,客户端仅请求所需数据。
表现 可能需要多次往返服务器。 一次请求即可获取所有数据,减少网络开销。
缓存 内置HTTP缓存机制。 没有内置缓存,但可以使用第三方库来弥补。(例如 Apollo、Relay)
模式 没有模式;文档通常是单独的。 强类型模式,自文档化。
学习曲线 对于熟悉HTTP的开发人员来说,很容易理解。 由于其独特的查询语言和概念,学习曲线较为陡峭。
文件上传 原生支持。 原生不支持;需要使用变通方法。
实时更新 需要额外设置(例如,WebSocket)。 内置支持通过订阅实现实时更新。
API演进 需要版本控制(例如,/v1,/v2) 模式可以在不破坏客户端的情况下进行演进。
自我记录 需要单独的文档(Swagger、Postman) 模式充当实时文档。

一个简单的例子:获取用户个人资料数据

REST 方式(多请求)

想象一下,一个移动应用程序需要显示用户的个人资料,包括他们的基本信息、最近发布的帖子和粉丝数量。

  1. 请求GET /user/123→ 返回基本用户详细信息(姓名、电子邮件、个人简介)。
  2. 请求GET /user/123/posts→ 获取最新帖子。
  3. 请求GET /user/123/followers/count→ 获取粉丝数量。

这意味着需要发出三个独立的请求。请求越多,延迟越高,并且当包含不必要的数据时,还会浪费带宽。

GraphQL 之道(单请求)

借助 GraphQL,客户端只需一次查询即可获取所需内容

query {
  user(id: "123") {
    name
    email
    bio
    posts(limit: 3) {
      title
      content
    }
    followersCount
  }
}
Enter fullscreen mode Exit fullscreen mode

一次请求即可获取所有必要数据,无需额外字段或冗余 API 调用,从而降低延迟并提高性能。

理解 GraphQL Schema

GraphQL模式定义了客户端可以请求哪些数据。它充当客户端和服务器之间的契约,确保结构化和高效的数据检索。

模式通常使用模式定义语言 (SDL)编写,这使得它们易于阅读和理解。模式由对象类型组成,每个对象类型都包含字段,用于指定哪些数据可用。

GraphQL 模式示例:

type Query {
  user(id: ID!): User
}

type User {
  name: String
  email: String
  bio: String
  posts(limit: Int): [Post]
  followersCount: Int
}

type Post {
  title: String
  content: String
}
Enter fullscreen mode Exit fullscreen mode

这里:

  • Query定义可用的查询。
  • User类型包含诸如name、、emailposts之类的字段followersCount
  • Post类型包括titlecontent

GraphQL 操作:查询、变更和订阅

1️⃣查询

GraphQL查询等同于 REST GET请求——它们获取数据而不修改数据。

2️⃣突变

变更允许客户端创建、更新或删除数据,类似于 REST 的POST、PUT、PATCH、DELETE方法。

更新用户个人简介的示例 mutation:

mutation {
  updateUser(id: "123", bio: "Exploring GraphQL!") {
    name
    bio
  }
}
Enter fullscreen mode Exit fullscreen mode

3️⃣订阅

GraphQL订阅利用 WebSocket 实现实时更新。与需要手动轮询的查询不同,订阅会在数据发生变化时自动推送更新。

订阅示例,用于监听新帖子:

subscription {
  newPost {
    title
    content
  }
}
Enter fullscreen mode Exit fullscreen mode

这样可以保持客户端更新,而无需重复请求

何时应该坚持使用 REST?

GraphQL功能强大,但在某些情况下REST仍然是一个可靠的选择

  1. 简单 API:如果您的 API 数据要求简单明了,那么 REST 的简洁性可能更合适。
  2. 缓存需求:REST 内置的 HTTP 缓存比 GraphQL 的第三方解决方案更强大。
  3. 文件上传:REST 原生支持文件上传,而 GraphQL 需要额外的设置。
  4. 传统系统:如果您正在使用现有的 REST API,除非有充分的理由,否则迁移到 GraphQL 可能并不值得。许多大型公司,例如 Facebook、GitHub 和 Netflix,都使用 GraphQL 来增强其 API 的效率和灵活性

结论

GraphQL 为 REST 提供了一种现代化的替代方案,它允许客户端从单个端点精确获取所需内容。这可以带来更快的应用程序运行速度、更便捷的维护以及更佳的开发者体验。然而,GraphQL 的学习曲线较为陡峭,并且需要对后端进行更改,因此评估它是否符合您的 API 需求至关重要。

你使用过 GraphQL 吗?你是否在某些项目中更倾向于使用 REST?欢迎在评论区分享你的想法!

🚀关注我们,获取更多 API 深度解析!

延伸阅读

说到 REST 和 GraphQL,您是否正在使用 REST 并希望记录您的 API?我只返回了清理后的文本,没有任何额外的注释:

免费开发者工具

我一直在开发FreeDevTools

一系列以 UI/UX 为中心的工具,旨在简化工作流程、节省时间并减少搜索工具/资料时的阻力。

欢迎任何反馈或投稿!

它是线上的、开源的,任何人都可以使用。

👉 快来看看:FreeDevTools
⭐ 在 GitHub 上给它点个星:freedevtools

让我们一起把它做得更好。

文章来源:https://dev.to/lovestaco/why-graphql-a-developer-friend-guide-to-api-evolution-51j5