在鸡尾酒会上邂逅 GraphQL | CSS-Tricks

GraphQL 和 REST 是两种用于构建网站使用的 API 的规范。REST 定义了一系列唯一的标识符（URL），应用程序使用这些标识符来请求和发送数据。GraphQL 定义了一种查询语言，允许客户端应用程序精确指定它们需要从单个端点获取的数据。它们是相关的技术，并且用于大致相同的事情（实际上，它们可以并且经常共存），但它们也截然不同。

这有点枯燥，是吗？让我们用一种更有趣的方式来解释它，这可能有助于您更好地理解，也许还能让您对 GraphQL 有一点兴奋！

🍹 您正在参加一个鸡尾酒会

您参加这个酒会是为了建立您的专业人脉，因此，您自然希望收集一些关于周围人的数据。附近有五位其他与会者。

他们的名牌上写着

Richy REST
Richy REST 的朋友
Richy REST 的雇主
Georgia GraphQL

作为您充满活力、社交和外向的自我，您径直走到 Richy REST 面前，说道：“你好，我是 Adam Application，您是？” Richy REST 回应道

{
  name: "Richy REST",
  age: 33,
  married: false,
  hometown: "Circuits-ville",
  employed: true
  // ... 20 other things about Richy REST
}

“哇，信息量太大了，”您心想。为了避免任何尴尬的沉默，您记得 Richy REST 特别提到他受雇于人，于是问道：“您在哪里工作？”

奇怪的是，Richy REST 并不知道自己在哪里工作。也许 Richy Rest 的雇主知道？

您向 Richy REST 的雇主问了同样的问题，他很高兴地回答了您的询问！他这样回应道

{
  company: "Mega Corp",
  employee_count: 11230,
  head_quarters: "1 Main Avenue, Big City, 10001, PL"
  year_founded: 2005,
  revenue: 100000000,
  // ... 20 other things about Richy REST Employer
}

此时，您已经筋疲力尽。您甚至不想见 Richy Rest 的朋友！那可能需要永远的时间，耗尽您所有的精力，而且您没有时间。

然而，Georgia GraphQL 一直礼貌地站在那里，所以您决定与她交流。

“你好，你叫什么名字？”

{   
  name: "Georgia GraphQL"
}

“您来自哪里，您多大了？”*

{
  hometown: "Pleasant-Ville",
  age: 28
}

“您有多少爱好和朋友？您的朋友叫什么名字？”

{
  hobbies_count: 12,
  friends_count: 50,
  friends: [
    { name: "Steve" },
    { name: "Anjalla" },
    // ...etc
  ]
}

Georgia GraphQL 令人难以置信，她表达清晰、简洁明了、切中要害。您 100% 想交换名片，并希望在未来的项目中与 Georgia 合作。

这个轶事概括了开发人员使用 GraphQL 而不是 REST 的体验。GraphQL 允许开发人员用简洁的查询表达他们的需求，并相应地仅接收他们指定的内容。这些查询是完全动态的，因此只需要一个端点。另一方面，REST 具有预定义的响应，并且通常需要应用程序利用多个端点来满足完整的数据需求。

隐喻结束！让我们谈谈实际情况。

为了进一步扩展鸡尾酒会隐喻中提出的基本概念，让我们专门解决使用 REST 时经常出现的两个限制。

1. 获取相关资源时需要多次请求

数据驱动的移动和 Web 应用程序通常需要相关的资源和数据集。因此，使用 REST API 检索数据可能需要向多个端点发出多个请求。例如，请求 Post 实体和相关的作者可能需要向两个不同的端点发出两个请求。

someServer.com/authors/:id
someServer.com/posts/:id

多次请求 API 会影响应用程序的性能和可用性。对于低带宽设备（例如智能手表、物联网、旧款移动设备等）来说，这也是一个更严重的问题。

2. 数据获取过多和获取不足

使用 RESTful API 时，数据获取过多或不足是不可避免的。使用上面的示例，端点 domainName.com/posts/:id 获取特定 Post 的数据。每个 Post 都由属性组成，例如 id、body、title、publishingDate、authorId 等。在 REST 中，始终返回相同的数据对象；响应是预定义的。

在只需要 Post 标题和正文的情况下，就会发生数据获取过多——因为发送到网络上的数据比实际使用的数据多。当需要整个 Post 以及其作者的相关数据时，就会发生数据获取不足——因为发送到网络上的数据比实际使用的数据少。数据获取不足会导致因向 API 发出多个请求而过度使用带宽。

使用 GraphQL 进行客户端查询

GraphQL 引入了一种真正独特的方法，为客户端应用程序提供了极大的灵活性。使用 GraphQL，查询被发送到您的 API，并且只返回您需要的内容——不多也不少——在一个请求中。查询结果以与查询相同的形状返回，确保响应结构始终可预测。这些因素使应用程序能够运行得更快并且更稳定，因为它们可以控制获取的数据，而不是服务器。

“结果以与查询相同的形状返回。”

/* Query */
{
  myFriends(first: 2) {
    items {
      name
      age
    }
  }
}

/* Response */
{
  "data": {
    "items": [
      { "name": "Steve", "age": 27 },
      { "name": "Kelly", "age": 31 }
    ]
  }
}

现实检验 ✅

现在，在这一点上，您可能认为 GraphQL 就像用武士刀切黄油一样容易。对于前端开发人员来说，这可能是现实——特别是那些使用 GraphQL API 的开发人员。但是，当涉及到服务器端设置时，就有人需要来完成繁琐的工作。我们的朋友 Georgia GraphQL 为了成为她现在如此出色的专业人士付出了很多努力！

在服务器端构建 GraphQL API 需要时间、精力和专业知识。也就是说，对于那些准备迎接挑战的人来说，这并不是无法处理的事情！有许多不同的方法可以从抽象的各个层面开始着手。例如

无辅助：如果您真的想亲自动手，可以借助一些软件包来构建 GraphQL API。例如，喜欢 Rails？请查看 graphql-ruby。喜欢 Node.js？请尝试 express-graphql。
有辅助：如果完全维护您的服务器/自行托管是优先事项，那么像 Graph.cool 这样的工具可以帮助您开始 GraphQL 项目。
即时：厌倦了编写 CRUD 样板代码并希望快速开始？8base 提供了一个即时的 GraphQL API 和无服务器后端，并且完全可扩展。

总结

REST 在实现高度可用的特定于资源的 API 方面，是 Web 服务的一项重大飞跃。也就是说，其设计没有考虑到当今互联设备的激增，所有这些设备都具有不同的数据约束和要求。这种疏忽很快导致了 GraphQL（Facebook 于 2015 年开源）的普及，因为它为前端开发人员提供了巨大的灵活性。使用 GraphQL 是一种非常棒的开发体验，无论对于单个开发人员还是团队而言。