概述
我们已经看到了我们的 超级图 构成 本地，并且我们的更改已准备好进入下一阶段。我们 可以 只将我们更新的模式发布到 GraphOS（我们在 两者 listings 和 reviews）, 但是让我们先暂停一下，并首先验证这些更改不会破坏任何东西。毕竟，我们是负责任的开发者！
在本课中，我们将
- 了解 模式检查 的类型
- 了解 模式检查 如何融入更新 超级图 的整个过程
- 使用 Rover CLI 在本地运行模式检查
- 检查 Studio 中模式检查的结果
什么是模式检查？
模式检查 是一组预定义的测试，有助于识别模式更新引起的潜在错误。它们检查是否存在诸如 子图模式 之间的冲突或破坏现有客户端 操作 之类的错误。有了 模式检查，我们可以确保我们的模式更改在部署到生产环境时不会导致问题。
我们将讨论三种类型的 模式检查：构建检查、操作 检查和 linter 检查。
构建检查
构建检查 验证 子图 的模式更改是否仍然可以与 超级图 中的其他 子图模式 成功地组合。
例如，如果在一个 子图 中添加了一个新类型，构建检查将确定该添加是否与 超级图 中的其他子图兼容。如果不是，我们需要调查错误并修复它。
操作检查
操作检查 验证模式的更改是否会破坏现有客户端发送到 图 的任何 操作。
例如，假设一个 Web 客户端定期发送一个 GraphQL 查询 来检索其主页的数据。如果模式更改涉及在该 查询 中的 字段 中添加一个 必需 的 参数，它可能会破坏该客户端的现有 操作，因为它没有包含该参数！操作检查有助于我们防止这种潜在的错误，列出受影响的操作并允许团队解决它们。
Linter 检查
Linter 检查 分析您的提议的模式更改，以查找格式规则和其他 GraphQL 最佳实践的违规。 GraphOS 提供一组默认规则，您可以对其进行配置以适合您的团队的约定。您可以查看 Apollo 文档中的完整规则列表。
一些常见的模式约定包括：以 字段 名称 camelCase、类型名称 PascalCase 和枚举 SCREAMING_SNAKE_CASE 编写。
使用 Rover 运行检查
我们可以使用 Rover 直接从命令行运行这些检查。Rover 会评估我们本地更改对我们已在生产环境中拥有的内容的影响。它的输出将告诉我们所有我们需要知道的信息——以及我们需要修复什么！——在我们发布更改之前。
运行模式检查：rover subgraph check
要对 子图 执行模式检查，我们使用 rover subgraph check 命令，以及以下参数：
rover subgraph check <APOLLO_GRAPH_REF> \--schema <SCHEMA_FILE_PATH> \--name <SUBGRAPH_NAME>
该命令运行 模式检查，然后将结果报告给 Studio，以便我们可以从我们 图 的 检查 页面查看它们。
对 reviews 运行检查
让我们从检查 reviews 中的更改开始。 子图。
在 reviews 目录中打开一个新的终端，粘贴 rover subgraph check 命令。确保您将参数替换为 您 自己的值。
rover subgraph check <APOLLO_GRAPH_REF> \--schema ./src/schema.graphql \--name reviews
该过程完成后，我们可以看到模式更改的报告。终端输出显示以下内容
Checking the proposed schema for subgraph reviews against Airlock@currenterror[E029]: Encountered 1 build error while trying to build subgraph "reviews"into supergraph "Airlock@current".Caused by:INVALID_FIELD_SHARING: Non-shareable field "Listing.id" is resolvedfrom multiple subgraphs: it is resolved from subgraphs "listings" and "reviews"and defined as non-shareable in subgraph "listings"The changes in the schema you proposed for subgraph reviews are incompatiblewith supergraph Airlock@current. See https://apollo.graphql.net.cn/docs/federation/errors/for more information on resolving build errors.
那么，这个 INVALID_FIELD_SHARING 错误是什么呢？嗯， reviews 子图 声明 Listing 作为一个 实体，但据我们了解的模式注册表， listings 子图 没有！最初定义 Listing 类型的是子图，所以这看起来有点问题。
让我们仔细看看。我们也可以在 Studio 中查看此模式检查（以及任何过去的检查）的结果。（Rover 在其消息结尾添加了指向此特定检查的链接。）
转到 Studio 中的 超级图 并导航到 Checks 页面。你会在那里看到相同的反映结果。
当我们点击检查时，我们可以看到有关它可能发现的任何问题的更多细节。
看起来我们正在处理一个操作顺序问题。模式注册表不知道我们对 listings 子图 所做的更改，所以让我们对我们的 listings 子图 运行相同的检查。
在 listings 上运行检查
在你的终端中，导航到 listings 目录，并运行以下命令。确保你指定了自己的 图引用。
rover subgraph check <APOLLO_GRAPH_REF> \--schema ./src/schema.graphql \--name listings
当我们运行此命令时，我们应该看到以下输出。
There were no changes detected in the composed API schema, but the core schema was modified.
回顾一下，我们对 listings 模式只做了一件事：我们将 Listing 类型更改为 实体。让我们跳回到 Studio 并查看 Checks 页面上的新条目。
点击此检查并选择 Build 来自 TASK 面板。然后，从 WORKFLOW 面板下，点击按钮 View schema。
这给了我们两种选择：我们可以查看我们检查过的 listings 子图模式，或者我们可以查看将与最新更改组合的整个 超级图模式。现在让我们只点击 listings 子图模式 选项。
此选项向我们展示了我们检查过的完整的 子图模式。我们可以看到我们为 Listing 实体 指定的 @key 指令 和主键 字段 在这里。
为了解决我们在 reviews 子图 上运行检查时出现的错误，我们只需要在发布子图时遵循特定的顺序：首先，我们将发布对 listings 子图 的更改，这些更改将 Listing 注册为 实体 类型。然后我们可以继续发布我们的 reviews 子图 更改，我们的错误将消失！让我们在下一课（也是最后一课）中解决这个问题。
练习
将项目从此框拖放到上面的空白处
Linter
子图
Build
Operation
Field
Deprecated
rover subgraph check 命令需要的？关键要点
- 模式检查 有助于在模式更新在生产环境中造成问题之前识别它们可能造成的潜在故障。
- Build 检查验证 子图 的模式更改是否仍然可以成功地与其他 子图模式 组合。
- Operation 检查验证模式的更改是否不会破坏现有客户端发送到 图 的任何操作。
- Linter 检查验证模式是否遵循格式规则和约定。
- 要运行模式检查，我们使用
rover subgraph check命令。 - 我们可以通过终端或 Studio 检查页面查看模式检查的结果。
接下来
使用 GraphOS 工具（如 Rover 和 Studio），我们已验证我们的模式更改是安全的，并且不会破坏任何东西！🎉 接下来，我们将发布我们的子图模式。
分享您对本课的疑问和评论
本课程目前处于
您需要一个 GitHub 帐户才能在下面发布。没有？ 请改为在我们的 Odyssey 论坛中发布。