GraphQL是为聚合统一而构建的 - thenewstack

21-11-12 banq

当组织达到一定规模时,他们会围绕团队进行组织。团队通常具有职能职责——营销、财务、工程等。API 遵循类似的功能对齐方式;我们看到提供营销功能(促销、产品描述等)、电子商务功能(购物车等)、财务功能(订单到现金等)的 API 集。这些 API 通常由专门的开发团队独立开发,即使在组织上它们可能在同一个工程组织中。

随着组织在其 API 旅程中逐渐成熟,并且随着 GraphQL 被用作下一波 API 技术,他们意识到必须将他们的 REST 用于 GraphQL API。关于将什么公开为 GraphQL 的决定可以是集中的,也可以由职能团队决定。随着团队和组织变得更大,一个常见的模式是将这些决策分散。因此,企业可能有一个营销 GraphQL 端点、一个电子商务 GraphQL 端点和一个财务 GraphQL 端点,每个端点都由各自的团队负责。

然而,现代数字体验不仅仅建立在一种功能性 GraphQL API 上。例如,电子商务网站可能会结合营销、电子商务和物流 GraphQL API,仅举几例。这些不同的 GraphQL API 如何整合到一个统一的 GraphQL 层中,从而构建这些数字体验?

关于这些功能性 GraphQL API 如何组合成一个统一层,有多种术语:模式拼接和联合是最常见的。

 

让我们首先阐明构建这个统一的 GraphQL API 需要什么:

  • 这一层应该没有业务逻辑。它应该主要是布线和装配层。换句话说,就计算机科学而言,这一层有责任将请求分散到正确的功能 GraphQL API 并收集结果以返回答案。
  • GraphQL 层必须调用具有正确身份验证和授权的功能性 GraphQL API。毕竟不同的功能可以选择实现自己的机制。
  • 它必须能够处理常见错误,包括无响应

当您查看上述注意事项时,该统一层所需的内容与构建任何其他一个功能性 GraphQL API 所需的内容之间只有一个区别:

功能性 GraphQL API 的后端可以是任何东西:REST、SOAP、数据库;但这一统一层的后端完全是 GraphQL。

就是这样!功能式 API 和统一的 GraphQL 层都需要能够将多个后端连接在一起:

  • 两者都需要在前端和后端处理身份验证和授权。
  • 两者都需要处理错误和性能问题。

 

在 StepZen 中,任何开发人员——无论是构建功能式 GraphQL API 还是在这一层——都使用四个概念:

  • 每个后端公开一个迷你 GraphQL 子图。这个子图可以通过内省自动生成,从一些预制的公共端点中选择,和/或通过将 @rest、@dbquery 和 @graphql 构造添加到手工编写的 GraphQL 模式文件 (SDL) 来编写。
  • 这些子图可以通过使用@materializer 构造将一个子图中的查询/变异与另一个子图中产生的数据连接在一起来连接在一起。
  • 一个 YAML 配置文件,包括对 API 和后端数据源的访问控制。该文件与上面的图表分开。
  • API 和配置交给 StepZen 运行,系统负责优化、缓存、错误处理等的标准方式。没有运行或管理的基础设施,我们保证您的 API 99.99% 的可用性。

使用这四个概念,开发人员可以利用之前对现有 API 和基础设施的所有投资。

与此同时,组织和前端团队可以获得所有 API 都使用一个 GraphQL API 的所有额外好处。

 

1
猜你喜欢