概览
我们可以合并我们的更改，但要首先验证这些更改不会破坏任何内容。毕竟，我们都是负责任的开发者！
在本课中，我们将
- 了解不同的模式检查
- 了解模式检查如何融入到更新supergraph的整体过程中
- 使用Rover CLI在本地上运行模式检查
- 在Studio中检查模式检查结果
什么是模式检查？
模式检查是一组预定义的测试，有助于识别由模式更新引起的潜在失败。它们检查诸如子图模式之间不兼容或者破坏现有的客户端操作等问题。通过模式检查，我们可以确保在部署到生产环境时我们的模式更改不会导致问题。
我们将讨论两种模式检查：构建检查和操作检查。
构建检查
构建检查验证一个子图的架构变更是否仍然可以与超图中的其他子图架构成功组合。
例如，如果在某个子图中添加了一个新类型，构建检查将确定这一添加是否与超图中的其他子图兼容。如果不兼容，我们需要调查错误并修复它。
注意: 我们的诗意板超图目前只有一个子图（菜谱），因此在此阶段构建检查对我们来说并不太相关！
操作检查
操作检查验证架构的改变不会破坏现有客户端发送到图形的任何操作。
例如，假设一个网络客户端定期发送一个GraphQL 查询来检索其主页的数据。如果架构变更涉及到在一个必需的 参数中添加一个字段到该查询，它可能会破坏客户端现有的操作（如果它不包含该参数）。操作检查帮助我们防止这种潜在的失败，列出了受影响的操作，并允许团队处理这些问题。
代码风格检查
代码风格检查分析您提出的架构变更是否符合格式化规则和其他GraphQL最佳实践。GraphOS提供了一套默认规则，您可以根据团队的习惯进行配置。您可以在Apollo 文档中查看规则列表。
一些常见的架构规范包括：使用SCREAMING_SNAKE_CASE书写枚举。
rover 子图检查
使用 Rover CLI 运行架构检查主要有两种方式。我们可以在终端本地运行架构检查（我们很快就会这样做）。我们还可以将架构检查集成到 CI 流中，以便在新的拉取请求上自动运行（我们将在下一课中做这个）。
要对 子图 执行架构检查，我们使用以下参数的 rover subgraph check 命令：
rover subgraph check <GRAPH_REF> \--schema <SCHEMA_FILE_PATH> \--name <SUBGRAPH_NAME>
注意: 图引用（或 图引用）告知 Rover 关于我们的 超级图。图引用以图的 ID 开头，后面跟一个 @ 符号，后面跟图 variant。
此命令首先运行构建检查，然后运行操作检查，然后运行 lint 检查，最后在命令行中输出结果。它还向 GraphOS 报告结果，因此我们可以从图 检查 页面查看它们。
运行架构检查
让我们试试吧！在我们上一课中，我们通过废弃一个 字段 并添加一个新字段来对架构做了变更，所以在将它们推送到架构注册表之前，让我们确保这些变更安全。
首先，让我们获取我们的 超级图 的引用。我们可以在 Studio 中找到此值，在图 README 的顶部。
接下来，让我们打开一个新的终端，粘贴 rover subgraph check 命令。确保将参数替换为 你的 自定义值。
rover subgraph check poetic-plates-supergraph@main \--schema schema.graphql \--name recipes
完成过程后，我们可以看到架构更改的报告。终端输出显示以下内容
Checking the proposed schema for subgraph recipes against poetic-plates-supergraph@mainCheck Result:Compared 2 schema changes against 123 operations┌────────┬──────────────────┬──────────────────────────────────────────────────────┐│ Change │ Code │ Description │├────────┼──────────────────┼──────────────────────────────────────────────────────┤│ PASS │ FIELD_DEPRECATED │ type `Ingredient`: field `text` deprecated │├────────┼──────────────────┼──────────────────────────────────────────────────────┤│ PASS │ FIELD_ADDED │ type `Ingredient`: field `detailedDescription` added │└────────┴──────────────────┴──────────────────────────────────────────────────────┘View full details at [Studio URL]
第一列指示每个更改是否通过或失败检查。第二列指示我们进行的更改类型，例如 FIELD_ADDED 和 FIELD_DEPRECATED。最后一列提供了更改的更详细描述，例如创建的确切类型以及类型下添加了哪些 字段
太棒了，我们没有出现任何错误！我们可以从输出表中的每一行都显示“通过”状态来看出，检查已经通过。我们还对比了架构变更与现有客户端操作的数量，没有发现任何破坏性的变更。操作，并且没有检测到任何破坏性的变更。
我们也可以在 Studio 中查看此架构检查的结果（以及任何之前的检查结果）！Rover 在其消息末尾添加了一个指向此特定检查的链接。
前往 Studio 中的您的 supergraph，然后导航到 检查页面。您将在这里看到相同的结果。
可选：失败的检查
为了乐趣，让我们看看如果我们的一项检查失败会发生什么。
打开 schema.graphql 文件，找到我们刚刚废弃的 text 字段，并移除 reason 参数。
text: String @deprecated
在终端窗口中再次运行架构检查。
rover subgraph check poetic-plates-supergraph@main \--schema schema.graphql \--name recipes
完成过程后，我们可以看到架构更改的报告。终端输出显示以下内容
Checking the proposed schema for subgraph recipes against poetic-plates-supergraph@mainThere were no changes detected in the composed API schema, but the core schema was modified.Operation Check [PASSED]:Compared 2 schema changes against 120 operations.┌────────┬──────────────────┬──────────────────────────────────────────────────────┐│ Change │ Code │ Description │├────────┼──────────────────┼──────────────────────────────────────────────────────┤│ PASS │ FIELD_DEPRECATED │ type `Ingredient`: field `text` deprecated │├────────┼──────────────────┼──────────────────────────────────────────────────────┤│ PASS │ FIELD_ADDED │ type `Ingredient`: field `detailedDescription` added │└────────┴──────────────────┴──────────────────────────────────────────────────────┘View operation check details at: [Studio URL]Lint Check [PASSED]:Resulted in 1 warning.┌─────────┬─────────────────┬──────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────┐│ Level │ Coordinate │ Line │ Description │├─────────┼─────────────────┼──────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────┤│ WARNING │ Ingredient.text │ 1269 │ When applying the @deprecated directive, always include the reason argument: @deprecated(reason: String). │└─────────┴─────────────────┴──────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────┘View lint check details at: [Studio URL]
我们可以看到，我们的 操作检查通过了，以及我们的lint检查也通过了，但有一个警告：应始终包括 @deprecated 指令 的 reason 参数。我们也可以在 Studio 中查看检查结果。
注意：默认情况下，所有 lint 规则都设置为“警告”。要查看和更改规则的严重性，请点击“查看配置”。可以在该页面上更改规则及其严重性的完整列表。
在我们忘记之前，让我们添加 reason 参数，并让我们的检查再次通过！
"Display text for the ingredient"text: String @deprecated(reason: "Use detailedDescription")
练习
将此框中的项目拖放到上面的空白处
操作
消耗者
构建
子图
废除
字段
关键要点
- 架构检查可以帮助在架构更新在生产环境中引起问题之前识别潜在失败。
- 构建检查验证，子图的架构更改在与其他子图架构成功组合之前仍能正常工作。
- 操作检查验证架构的更改不会破坏任何现有客户端向图发送的操作。
- 代码检查器验证架构遵循格式规则和约定。
- 要运行架构检查，我们使用
rover subgraph check命令。 - 我们可以在终端或Studio检查页面上检查架构检查的结果。
接下来
使用Rover和Studio等GraphOS工具，我们已经验证了我们的架构更改是安全的，并且没有破坏任何东西！ 🎉现在是我们将更改发布到我们的supergraph架构注册表的时候了。
分享您对这节课的疑问和评论
本课程目前正在
您需要GitHub账户才能发表以下内容。没有吗？ 请在我们的大航海论坛上发帖。