模拟图功能以解除客户端开发的限制

随着您的组织构建其supergraph，您可能会发现您的客户端团队经常等待子图所有者对其模式进行约定的更改。在这段时间里，您可以在开发您的客户端和子图的同时，模拟您的supergraph的部分，从而使团队能够并行工作，而不会互相阻塞。

首先，就您的模式达成一致

为了有效地模拟您的supergraph的部分，客户端和后端团队都需要在该部分的整体治理策略和审批过程中就其结构达成一致。这些团队在不同处新增/删除/更改模式之间的对齐可以帮助您的模式更有用且富有表现力。

创建新的模式

如果您正在创建全新的图和相应的模式，首先熟悉模式最佳实践是非常重要的，例如在Apollo Odyssey、Principled GraphQL和企业指南中描述的。

对于新模式，我们推荐使用GitHub用户setchy提供的这个例子来模拟整个新模式。这将为您的客户端团队提供一个本地的（或托管的）模式实例，以便他们可以进行查询并开始使用模拟数据创建模拟UI组件。

要使用此示例，您需要将您的模式发布到Apollo GraphOS。有关将模式发布到GraphOS的好处细节，见下文。

要开始使用示例，请运行以下命令：

git clone https://github.com/setchy/apollo-server-4-mocked-federation
cd apollo-server-4-mocked-federation
npm install
cp .env.template .env

然后，编辑.env文件以从GraphOS Studio获取适当的值，并运行以下命令以启动服务器：

npm run dev

这个示例使用@graphql-tools/mock包来生成模拟。您可以按照包的文档页面中的说明来自定义示例的行为。

然后此网关既可以用于本地（如本地客户端开发），也可以作为托管网关供客户端开发人员使用。

数据是模拟的，但它不需要服务器团队进行任何工作来支持，并将与存在于GraphOS Studio中的模式相匹配。由于我们使用GraphOS Studio来处理模式，因此模式更改将自动提取，以确保客户端开发人员正在处理最新版本。

修改现有模式

修改现有模式的过程与新模式的创建过程类似，特别是在规划方面。当您添加新功能时，尽早达成设计共识非常重要，特别是对于需要大量后端工作的功能（例如，机器学习）。

为了模拟提议的更改（例如添加新类型/字段），我们建议使用Apollo解决方案架构团队创建的这个示例。该示例需要现有的GraphQL API正在运行。它通过允许你的subgraph的“修补”或修改版本地运行具有模拟数据，同时使用远程API进行所有其他数据。

要使用此示例，您需要将您的模式发布到GraphOS。有关将模式发布到GraphOS的详细信息，请参见下面的说明。

开始，运行

1
mkdir mocked_gateway
2
export APOLLO_KEY=key_from_studio #replace with the actual key from GraphOS Studio
3
cd mocked_gateway
4
touch proposed.graphql
5
npx github:@apollosolutions/apollo-faker-demo --graphref <yourgraph>@<variant> --remote https://yourapi.com/graphql

然后，使用proposed.graphql文件修改提议的更改。通过@graphql-tools/mock包，有可用的配置选项，您可以在示例的README文件中设置这些选项（第5步）阅读有关说明。

为何使用GraphOS作为模拟服务器？

现在，您已经有一个新的模式或对现有模式的更改，将此模式发布到Apollo GraphOS对于以下原因很重要：

• GraphOS Studio提供对您的模式以及模式模拟视图的集中视图。
• 通过发布到GraphOS，上述示例可以在更改后自动更新，使所有开发者都可以引用已部署的示例版本。
• 对于使用代码生成工具的客户团队（特别是Apollo客户端库中的团队），可以使用GraphOS作为模式源，从而实现更简单的开发。

我们建议使用您的新/现有生产 图ID 的一个 变体。如果您正在考虑对架构变更进行模拟，这也确保提出的变更在使用 架构检查对生产流量时不会中断。