当组织达到一定规模时，他们会围绕团队进行组织。团队通常具有职能职责——营销、财务、工程等。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 的所有额外好处。