0%

如何使用GraphQL-基础教程:架构

接上篇 —— 如何使用 GraphQL-基础教程:核心概念 —— 继续翻译How to GraphQL 系列教程

了解 GraphQL 的不同架构、用法以及后端和前端的主要组件,例如解析器函数和客户端库。

基础和进阶系列翻译已完成:

  1. 介绍
  2. GraphQL 比 REST 的优点
  3. 核心概念
  4. 架构
  5. 客户端
  6. 服务端
  7. 更多概念
  8. 工具和生态
  9. 安全
  10. 常见问题

GraphQL 仅作为 标准(specification) 发布。这意味着 GraphQL 实际上不过是一个详细文档,该文档详细描述了 GraphQL 服务端 的行为。

用例

在本节中,将介绍 3 种 GraphQL 服务端不同的架构:

  1. GraphQL 服务端 具有已连接的数据库
  2. GraphQL 服务端是许多 第三方或既有旧系统 前面的 _一层_,可以通过单个 GraphQL API 集成它们
  3. 可以通过相同的 GraphQL API 访问已连接的数据库和第三方或既有旧系统的混合方法

这三种架构都代表了 GraphQL 的主要用法,并展示了使用环境的灵活性。

1. 带有已连接数据库的 GraphQL 服务端

对于 尚未开发(greenfield) 项目,这种架构是最常见的。在设置中有一个实现 GraphQL 规范的单个 (Web)服务端。当查询到达 GraphQL 服务端时,服务端读取查询的负载并从数据库中获取所需的信息。这称为 解析(resolving) 查询。然后如官方规范中所述构造响应对象并将其返回给客户端。

重要的是要注意 GraphQL 实际上是 传输层无感知(transport-layer agnostic) 。这意味着它可以与任何可用的网络协议一起使用。因此可以实现基于 TCP,WebSockets 等的 GraphQL 服务端。

GraphQL 也不关心数据库或用于存储数据的格式。可以使用AWS Aurora之类的 SQL 数据库或MongoDB之类的 NoSQL 数据库。


具有一个已连接到数据库的 GraphQL 服务端的标准 greenfield 体系结构。

2. 集成现有系统的 GraphQL 层

GraphQL 的另一个主要用法是在一致的 GraphQL API 之后集成多个现有系统。这对于拥有既有旧基础架构和许多不同 API 的公司而言尤其引人注目,这些公司已经发展了多年,现在却承担了很高的维护负担。这些既有旧系统的一个主要问题是不能构建需要访问多个系统的新产品。

在这种情况下,可以使用 GraphQL 统一这些现有系统,并将它们的复杂性隐藏在一个不错的 GraphQL API 后面。这样,可以开发新的客户端应用程序,这些应用只需与 GraphQL 服务端会话即可获取所需的数据。然后 GraphQL 服务端负责从现有系统中获取数据并将其打包为 GraphQL 响应格式。

就像在上一个的架构中 GraphQL 服务端不关心所使用的数据库类型一样,这次也不关心需要查询所需数据的数据源。


GraphQL 允许在单个 GraphQL 接口后面隐藏现有系统的复杂性,例如微服务,既有旧基础架构或第三方 API。

3. 访问已连接的数据库和第三方或既有旧系统的混合方法

最后,可以将这两种方法结合起来,构建一个具有已连接数据库但仍可与既有旧系统或第三方系统通信的 GraphQL 服务端。

服务端收到查询后,它将解析该查询,并从已连接的数据库或某些集成的 API 中检索所需的数据。


这两种方法也可以组合在一起,并且 GraphQL 服务端可以同时从数据库和现有系统中获取数据-非常灵活并将所有数据管理的复杂点转移到服务端上。

Resolver Functions 解析器函数

但是我们如何通过 GraphQL 获得这种灵活性?如何适应这些完全不同的用法呢?

正如在上一章中了解到的,GraphQL 查询(或变更)的负载由一组 字段 组成。在 GraphQL 服务端实现中,每个字段实际上对应于一个称为 解析器(resolver) 的函数。解析器函数的唯一作用是获取对应字段的数据。

服务端接收到查询时,将调用查询的负载中指定的字段的所有函数。因此可以解析查询并能够为每个字段检索正确的数据。一旦所有解析器返回,服务端将以查询所描述的格式打包数据,并将其发送回客户端。


上面的屏幕快照包含一些已解析的字段名称。查询中的每个字段都对应一个解析器函数。当一个查询到来以获取指定数据时,GraphQL 将调用所有必需的解析器。

GraphQL 客户端库

GraphQL 特别适合前端开发者,因为它彻底解决了 REST API 遇到的许多不便和缺点,例如过度获取和获取不足。复杂点被转移到服务端,功能强大的机器可以处理繁重的计算工作。客户端不必知道其获取的数据实际来自哪里,并且可以使用一个一致且灵活的 API。

考虑一下 GraphQL 所带来的主要变化,即从一种命令式的数据获取方法变为一种纯粹的声明式获取方法。从 REST API 提取数据时,大多数应用必须执行以下步骤:

  1. 构造并发送 HTTP 请求(例如,使用 Javascript 中的 fetch
  2. 接收并解析服务端响应
  3. 在本地存储数据(仅存储在内存中或持久存储)
  4. 在 UI 中展示数据

使用理想的 声明式数据获取(declarative data fetching) 方法,客户端只需要执行以下两个步骤:

  1. 描述数据要求
  2. 在 UI 中展示数据

所有底层网络任务以及数据存储都被抽象化,主要部分变为数据依赖性的声明。

这正是 GraphQL 客户端库(例如 Relay 或 Apollo)能够执行的操作。它们提供了一种抽象,使开发者够专注于应用的重要部分,而不必重复处理基础结构。


前端记事本,不定期更新,欢迎关注!


👆 全文结束,棒槌时间到 👇