概述
我们已经看到了我们的 超图 组成 本地，并且我们的更改已准备好进入下一阶段。为了将我们的 recommendedPlaylists 功能添加到我们的 图 中，我们需要告诉 GraphOS 我们架构是如何变化的！
我们 可以 直接合并我们的更改并将它们发布到 GraphOS，但是让我们先暂停一下，并验证这些更改不会破坏任何东西。毕竟，我们是负责任的开发者！
在本课中，我们将
- 了解 架构检查 的类型
- 了解 架构检查 如何适应更新 超图 的整个流程
- 使用 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 <GRAPH_REF> \--schema <SCHEMA_FILE_PATH> \--name <SUBGRAPH_NAME>
该命令首先运行构建检查，然后运行 操作 检查，然后运行 linter 检查，最后在命令行中输出结果。它还会将结果报告给 Studio，以便我们可以从您的 图 的 检查 页面查看它们。
运行架构检查
让我们试一试！我们在上一课中通过向 实体 添加新 字段 来进行架构更改（Recipe.recommendedPlaylists），所以让我们确保这些更改在将它们推送到我们的架构注册表之前是安全的。
首先，让我们重新生成架构文件。在一个新的终端窗口中，运行
dotnet run -- schema export --output schema.graphql
我们应该看到我们的架构中增加了一些内容。
type Recipe @key(fields: "id") {"A list of recommended playlists for this particular recipe. Returns 1 to 3 playlists."recommendedPlaylists: [Playlist!]! @requires(fields: "name")id: ID!name: String @external}#...union _Entity = Recipe | Playlist
我们还需要我们的 图引用。 可以在 Studio 中找到此值，位于 图 的 README 页面的顶部，或者从我们在 Router/.env 文件中存储的位置获取它。
接下来，让我们打开一个新的终端并粘贴 rover subgraph check 命令。 请确保将参数替换为 您 自己的值。
rover subgraph check <APOLLO_GRAPH_REF> \--schema schema.graphql \--name soundtracks
该过程完成后，我们可以看到架构更改的报告。 终端输出显示以下内容
Checking the proposed schema for subgraph soundtracks against Music-Matcher@currentThere were no changes detected in the composed API schema, but the core schema was modified.Operation Check [PASSED]:Compared 1 schema changes against 2 operations.┌────────┬─────────────┬───────────────────────────────────────────────────┐│ Change │ Code │ Description │├────────┼─────────────┼───────────────────────────────────────────────────┤│ PASS │ FIELD_ADDED │ type `Recipe`: field `recommendedPlaylists` added │└────────┴─────────────┴───────────────────────────────────────────────────┘
第一列指示每个更改是否通过了检查。 第二列指示我们所做的更改类型，例如 FIELD_ADDED。 最后一列提供了更详细的更改说明，例如创建了哪种确切类型以及 字段 在该类型下添加了哪些内容。
太棒了，我们没有错误！ 我们可以看到检查已通过，因为输出表中的每一行都具有 PASS 状态。 架构更改也与现有客户端 操作 的数量进行了比较，并且没有检测到重大更改。
我们也可以在 Studio 中查看此架构检查（以及任何过去的检查）的结果！ Rover 在其消息末尾添加了指向此特定检查的链接。
转到您在 Studio 中的 超图，并导航到 Checks 页面。 您将在那里看到相同的反映结果。
可选：检查失败
为了好玩，让我们看看如果我们的检查之一失败了会发生什么。
打开 schema.graphql 文件并找到 Recipe.recommendedPlaylists 字段。 将小写字母 r 更改为大写字母 R，使其显示为 RecommendedPlaylists。
RecommendedPlaylists: [Playlist!]! @requires(fields: "name")
在终端窗口中，再次运行架构检查。
rover subgraph check GRAPHREF@GRAPHVARIANT \--schema schema.graphql \--name soundtracks
该过程完成后，我们可以看到架构更改的报告。 终端输出显示以下内容
Checking the proposed schema for subgraph soundtracks against Music-Matcher@currentThere were no changes detected in the composed API schema, but the core schema was modified.Operation Check [PASSED]:Compared 1 schema changes against 2 operations.┌────────┬─────────────┬───────────────────────────────────────────────────┐│ Change │ Code │ Description │├────────┼─────────────┼───────────────────────────────────────────────────┤│ PASS │ FIELD_ADDED │ type `Recipe`: field `RecommendedPlaylists` added │└────────┴─────────────┴───────────────────────────────────────────────────┘View operation check details at: [STUDIO LINK]Linter Check [PASSED]:Resulted in 1 warning.┌─────────┬─────────────────────────────┬──────┬─────────────────────────────────────────┐│ Level │ Coordinate │ Line │ Description │├─────────┼─────────────────────────────┼──────┼─────────────────────────────────────────┤│ WARNING │ Recipe.RecommendedPlaylists │ 45 │ Field names should use camelCase style. │└─────────┴─────────────────────────────┴──────┴─────────────────────────────────────────┘View linter check details at: [STUDIO LINK]
我们可以看到我们的 操作 检查通过了，代码整理检查也通过了，但有一个 警告： Field names should use camelCase style。 我们也可以在 Studio 中查看检查结果。
注意： 默认情况下，所有代码整理规则都设置为“警告”。 要查看和更改规则的严重性，请单击“查看配置”。 可以在该页面上更改规则的完整列表及其严重性。
在我们忘记之前，让我们恢复 recommendedPlaylists 更改，以使我们的检查再次通过！
recommendedPlaylists: [Playlist!]! @requires(fields: "name")
练习
将此框中的项目拖放到上面的空白处
代码整理
子图
操作
字段
构建
已弃用
rover subgraph check 命令需要的？主要要点
- 架构检查 有助于在架构更新导致生产问题之前识别这些更新可能导致的潜在故障。
- 构建检查会验证 子图 的架构更改是否仍然可以与其他 子图架构 成功组合。
- 操作 检查会验证架构的更改是否会破坏现有客户端发送到 图 的任何操作。
- 代码整理检查会验证架构是否遵循格式规则和约定。
- 要运行架构检查，我们使用
rover subgraph check命令。 - 我们可以通过终端或 Studio 的 Checks 页面检查架构检查的结果。
接下来
使用 Rover 和 Studio 等 GraphOS 工具，我们已验证我们的架构更改是安全的，不会破坏任何内容！ 🎉 现在该将我们的更改发布到超图的图注册表中了。
分享您有关本课程的问题和评论
本课程目前处于
您需要一个 GitHub 帐户才能在下面发布。 没有？ 请在我们的 Odyssey 论坛中发布。