Hasura GraphQL Engine for Dynamic APIs with PostgreSQL 简介

一般来说，在过去的几年里，REST API 在处理快速变化的技术需求时一直受到批评，因为它不够灵活。 回想起来，许多人认为 GraphQL 的创建是为了满足 API 开发对额外灵活性和效率的需求。 因此，减轻了 REST API 的缺陷。 由于 Facebook 从 HTML5 应用程序过渡到更强大和更原生的设置，GraphQL 在过去五年中越来越受欢迎和采用，这是有充分理由的。 在这篇博客中，我们将深入研究 GraphQL 现象，PostgreSQL 以及稍后对 Hasura GraphQL 引擎的全面介绍。 在一个片段中，Hasura GraphQL 引擎-PostgreSQL 关系和生态系统。

GraphQL：Facebook 的叛乱

尽管许多人认为 GraphQL 是作为对 REST API 的反叛而创建的，但这可能与事实相去甚远。 具有讽刺意味的是，它的创建只是为了满足 Facebook 的内部需求。 最初由 Facebook 团队设计和开源，GraphQL 经常被混淆为一种数据库技术。 从本质上讲，尽管存在误解，但 GraphQL 在技术上是一种用于 API 而非数据库的查询语言。 因此，它降低了构建 API 的复杂性，将所有请求抽象到单个端点。 与传统的 REST API 不同，GraphQL 是声明性的，这意味着无论请求什么都会返回。 尽管为了获得更多上下文，我们需要退后一步，重新审视 REST API。

REST 架构

通常，API 是指定软件组件应如何交互的规则、例程或协议。 Representational State Transfer (REST) 基本上是一种 API 设计架构，通常在 Web 服务的实现中使用，其中一切都被视为“资源”。 不幸的是，RESTful 方法一直局限于处理单一资源。 因此，如果需要数据并且来自两个或更多资源，例如帖子和用户，则需要多次往返服务器以收集所需的一切。 此外，REST 面临“过度”和“不足”获取的问题。 所有这一切都不理想，尤其是随着更多数据驱动的应用程序的出现，这些应用程序处理结合了相关资源的大型数据集。 这可以解释 Facebook 面临的困境。

因此，需要采用更灵活和渐进的方法的 API 架构。

创造另一种选择

或者， GraphQL 不会根据资源 URL、辅助键或表来考虑数据，而是根据对象图和使用NSObjects或JSON 的模型来考虑数据。 具体来说，GraphQL 不需要每个用例的专用端点，因为不同的功能和用例可以在单个“图形”中表示。 使用 GraphQL 查询语言，您可以准确描述响应应该是什么样子，因此不需要额外的服务器往返。 作为一种应用层查询语言，它旨在解释来自服务器/客户端的字符串，并以稳定、可理解和可预测的格式返回该数据。 它只是一个更好地整合数据的工具。

简单、稳定和高效。

事实是，并非所有项目都需要 GraphQL，尽管它定义明确的模式，所以我们确信我们不会过度获取。 但是，如果我们的企业产品依赖于来自多个来源的数据，例如 MySQL、Postgres 和其他 API，那么 GraphQL 是更好的选择。 GraphQL 以简单而自豪，尤其是在数据检索方面，因为数据是在一个公共端点或调用下收集的。 本质上，由于客户端得到了他们真正需要的东西，这有效地减少了客户端发出的每个请求的大小，从而产生高性能的应用程序。 由于 GraphQL 统一了原本需要多个端点的数据，因此它简化了复杂的重复检索，从而提高了查询效率。 因此，随着时间的推移，它的简单性带来了更多的后端稳定性、规划、构建、执行和持续运行。

GraphQL 的优势

简而言之，GraphQL 允许通过易于理解的查询来提取数据，允许快速开发轻量级和快速的应用程序，因为数据可以更直接地访问而不是通过服务器。 此外，它允许通过一个查询检索多个资源，而无需使用多个 URL 或资源链，同时对所有数据使用一个端点。 请记住，数据是使用基于图形的方案在服务器上定义的，因此作为一个包而不是通过多次调用交付。 这允许在 API 开发期间聚合 API 响应的操作提升。

这反过来又减轻了前端开发团队的负担，促进了 API 版本控制，简化了维护，并节省了数据传输需求。 此外，它在接收数据时允许更多的可预测性，支持声明性数据获取并减轻过度获取和获取不足。 本质上，当客户端下载的信息多于应用程序中实际需要的信息时，就会发生过度获取，而获取不足意味着特定端点没有提供足够的信息，因此需要客户端发出额外的请求来获取所需的信息。

从技术上讲，GraphQL 是一个可以定义的包装器，这意味着您不必完全替换 REST 系统。 从本质上讲，这意味着 GraphQL 与以 REST 为中心的 API 兼容的系统兼容。 此外，GraphQL 允许前端和后端的无缝和独立开发。 这是因为一旦架构被明确定义，前端和后端的团队都知道数据的明确结构。 许多全栈工程师认为所有这些好处都是有利的。 最后，GraphQL 具有惊人的彻底自省和自我记录的能力。

API 开发中的 GraphQL 用例

GraphQL 被认为非常强大，被寻求稳定可读性、快速速度和索引的全栈开发人员使用。 具体来说，GraphQL 在需要高数据吞吐量的 API 开发中很有用。 事实上，它最大限度地减少了通过网络传输所需的数据量。 这对移动用户、低功率设备和邋遢的网络非常有利。 这也是 Facebook 设计 GraphQL 的最初原因之一。 与想象相反，GraphQL 不仅适用于庞大的复杂数据库，它还可以创建相对简单的数据库，效率更高。

此外，它可以应用在各种独特的前端框架和平台上，提供一个使用一个 API 维护的异构环境，以满足所有用户的需求。 此外，它有助于快速特性开发，因为它显着提高了全栈开发团队的特性速度。 它通过减少团队之间所需的通信来实现这一点，同时开发新功能，因为前端开发人员可以发出 API 请求，例如，引入新功能或更改现有功能，而无需等待后端开发人员交付。 当我们开始介绍 Hasura GraphQL 引擎时，这个快速的 GraphQL 总结应该足够了。 虽然让我们接触 PostgreSQL 以获得更多的上下文。

什么是 PostgreSQL？

作为一个免费的社区驱动的关系数据库管理系统，PostgreSQL 不属于任何一家公司。 Postgres 被认为是可用的最强大、内部一致的 RDBMS，它是用 C 编写的，并支持多种编程语言，例如 C/C++、JavaScript、Java、Python、R、Go、Lisp、.Net 等。在大多数人中越来越受欢迎全栈开发人员，PostgreSQL 比它的姊妹 MySQL 功能更丰富，因其特性、可扩展性和性能而受到欢迎。 PostgreSQL 在要求围绕复杂过程、复杂设计、定制集成和数据完整性的项目中很受欢迎。

Postgres 对全栈开发人员的优势

一般来说，全文搜索、JSON 列、逻辑复制等特性使 Postgres 在 MySQL 上占上风。 这对于典型商业数据库的性能需求是最佳的，同时允许将多个数据库系统合并为一个以减少开销和成本。 此外，它的键值存储（JSON / JSONB 列类型）的最新功能使其成为 NoSQL 数据库的合适替代品。 此外，它支持集群或主从架构，使其非常适合类似云的环境。 此外，它流行的 foreign-data-wrapper 扩展允许在必要时直接从 PostgreSQL 内部查询外部源。 具体来说，它最适合需要执行复杂查询、数据仓库和动态数据分析的系统。

事实上，PostgreSQL 更好地支持 MySQL 不支持的某些特性。 例如，检查约束、丰富的数据类型（如数组、地图、JSON）、更丰富的地理空间支持（PostGIS）和更丰富的全文支持。 此外，它还支持非阻塞索引创建、部分索引、公用表表达式和更多动态分析功能。 尽管如此，PostgreSQL 为客户端/服务器通信加密的连接提供原生 SLL 支持，以及名为 SE-PostgreSQL 的内置增强功能，它提供基于 SELinux 策略的额外访问控制。

PostgreSQL 具有许多企业级产品的丰富功能，适用于数据需要身份验证且读/写速度对项目成功至关重要的大型系统。 此外，它还支持专有解决方案中通常可用的多种性能增强器。 其中包括：没有读锁的并发性、SQL 服务器和地理空间数据支持等等。

Postgres 架构的另一个主要优势是其独特的可扩展性。 它允许用户在不更改核心系统代码的情况下添加数据类型、索引访问方法、服务器编程语言、外部数据包装器 (FDW) 和可加载扩展等功能。 它利用现代多核处理器架构，因此随着内核数量的增加，其性能几乎呈线性增长。 这很重要，一般来说，全文搜索、JSON 列、逻辑复制等特性让 Postgres 在 MySQL 上占据上风。 这对于典型商业数据库的性能需求是最佳的，同时允许将多个数据库系统合并为一个以减少开销和成本。 此外，它的键值存储（JSON / JSONB 列类型）的最新功能使其成为 NoSQL 数据库的合适替代品。 此外，它支持集群或主从架构，使其非常适合类似云的环境。 此外，它流行的 foreign-data-wrapper 扩展允许在必要时直接从 PostgreSQL 内部查询外部源。 具体来说，它最适合需要执行复杂查询、数据仓库和动态数据分析的系统。

PostgreSQL 的缺点

一般来说，如果您喜欢 ANSI SQL 标准，请考虑使用 PostgreSQL，但如果您更喜欢 ODBC 标准，则选择 MySQL。 不幸的是，Postgres 偶尔会在实时、“永远在线”的生产环境中表现不佳。 Postgres 的另一个缺点是它的复制是在存储引擎级别实现的。 这使得它比 MySQL 的复制更昂贵，后者更成熟并在“查询引擎级别”实现。

Hasura GraphQL 引擎介绍

由于我们已经简要介绍了 GraphQL API 开发和 PostgreSQL，我们应该有足够的上下文来介绍 Hasura GraphQL 引擎。 基本上，Hasura 只是 PostgreSQL RDBMS 的 GraphQL 引擎，提供了一种简化的引导和管理 GraphQL API 开发的方法。 回想起来，Hasura 是目前唯一可以立即将 GraphQL 即服务添加到现有基于 PostgreSQL 的应用程序的现成解决方案。 本质上，绕过了编写处理 GraphQL 的后端代码的耗时任务。

哈苏拉简体

让我们花一点时间进一步简化 Hasura。 基本上，API 是允许您请求信息（查询）并因此通过发送 JSON 或 XML 数据进行响应的接口。 该数据库通常托管并从服务器获取。 这就是 Hasura 进来简化事情的地方。 事后看来，Hasura GraphQL 引擎是一个通过 Postgres 数据库处理 GraphQL 查询的服务器。 这有效地减少了您的应用程序投入生产所需的时间，让您只需单击几下即可轻松创建、查看和修改数据库表。 因此，这允许全栈开发人员在更短的时间内在 PostgreSQL 上构建可扩展的 GraphQL 应用程序。 这为开发人员节省了数周的前期编码时间，并且可以防止有问题的数据泄漏错误进入生产环境。

Hasura 在 API 开发中解决了什么问题？

通常，Hasura 简化了大规模生产使用期间的 API 生命周期管理，尤其是对于复杂的 API。 最重要的是，GraphQL 引擎吸引了利用现有 PostgreSQL 数据库进行企业 API 开发项目积压的全栈开发人员。 理想情况下，由于 GraphQL 允许闪电般快速的 API 开发周期，Hasura 为组织提供了一种简化的方式来逐步迁移到 GraphQL，而不会影响现有的应用程序、数据库或用户。 除了轻量级和高性能之外，该引擎还带有一个管理 UI，允许您探索您的 GraphQL API 并直观地管理您的数据库模式和数据。

哈苏拉的优势

首先，Hasura 有一个可靠、稳定的模型来管理数据库更改或“迁移”。 这是有利的，因为数据库模式管理通常很棘手。 例如，诸如以下任务； 跟踪随时间的变化并将模式更改与 API 增强（模式管理）相关联。 此外，诸如维护可以部署新数据库或回滚更改的脚本之类的日常工作可能会被证明是乏味的，并且会导致难以诊断的错误或中断。 作为一个积极的方面，Hasura 数据库迁移组件是纯 SQL，因此可移植到 Hasura 工具集之外。 总而言之，Hasura 具有出色的模式管理功能，您无需编写代码来处理 Web 套接字连接。

其次，Hasura GraphQL 引擎可以通过单个查询轻松获取所需数据。 它允许您将视图添加为与表或其他视图的关系。 此外，它还允许编写具有模式拼接的自定义解析器，以及在数据库事件上触发的无服务器功能或微服务 API 的集成。 这可以派上用场，并有助于构建 3factor 应用程序。 事实上，Hasura 是一款极其轻量级的引擎。 回想起来，即使每秒处理超过 1000 个请求，它也只消耗高达 50MB 的 RAM。 可观的投资回报！

具体来说，Hasura 进一步促进了细粒度的 API 数据级授权和身份验证。 它允许通过 webhook、JWT、Auth0 或自定义实现连接到首选身份验证提供程序。 因此，用户的角色规范，定义谁可以访问不同的数据，例如，管理员，匿名用户等。通常，它的粒度访问控制系统是基于类似于 GraphQL 模式的数据库表结构。 此外，自定义权限规则是根据数据库操作和值严格定义的。

最后，Hasura 出色地支持使用简单的类似 SQL 的偏移/限制模型的高效分页。 例如，它使用访问控制模型来限制给定查询返回的行数。 它的模型允许按角色调整限制。 例如，施加更高请求率的用户被限制为更小的行限制。 这样可以避免给数据库和 GraphQL 引擎带来压力。 此外，值得注意的是，Hasura 不仅限于使用 GraphQL。 您仍然可以针对 Hasura 管理的 Postgres 表运行 REST 或其他非 GraphQL 微服务。 这可以通过 Hasura 的自动模式拼接来实现。 这允许将非 Hasura GraphQL 服务和后端合并为一个统一的模式，将新的 Hasura 管理的 API 与旧的 API 和数据相结合。

哈苏拉用例

Hasura 引擎适用于高性能环境，提供速度，同时在现有数据库上自动执行 GraphQL-Postgres。 因此，这为已经使用 Postgres 的公司提供了一种通过将现有表链接到“图表”来迁移到 GraphQL 的压力较小且渐进的方式。 Hasura 有效地处理模式拼接，使您可以轻松应用自定义业务逻辑。 借助远程 GraphQL 模式，Hasura 可以用作自定义业务逻辑的网关，允许您以自己喜欢的语言写入 GraphQL 服务器，然后将数据公开给单个端点。 此外，Hasura 具有出色的查询和突变语法，内置实时查询，称为 GraphQL 中的订阅。

几个 Hasura 限制

不幸的是，Hasura 的访问控制系统模型不能完全适用于每个应用程序。 例如，它不完全支持单个输入参数级别的 API 访问授权。 更不用说它仅限于在大多数情况下需要迁移的 Postgres 数据库。 尽管可以忽略不计，但 GraphQL API 针对格式错误的请求返回的错误消息在 Hasura 上非常不友好。 否则，正如我们在 Hasura GraphQL 引擎介绍中所见，Hasura 几乎没有什么不能做的。

结论

总之，随着 GraphQL 的发展，它将进一步简化企业内部的 API 开发，以在 Web 规模上构建。 随着 GraphQL 在各行各业中的广泛快速采用，Hasura 有可能使用所选的行业标准技术 GraphQL 和 Postgres 进一步自动化 API 的创建和管理。 Hasura简化了 CRUD（创建、读取、更新和删除）GraphQL 后端的创建。 更重要的是，如果您从头开始使用以 GraphQL 为中心的 API 和 Postgres，而无需编写后端代码，Hasura 是迄今为止最好的也是唯一的选择。 有关 GraphQL 和 Hasura 企业可能性的任何疑问或咨询，请随时与我们联系。 这就是我们对 Hasura GraphQL 引擎的介绍。