7. 字段洞察
5米

概述

目标就在眼前！让我们完成 我们开始的弃用。

在本课程中，我们将

  • 检查 在
  • 了解两种类型的 度量：字段执行和引用 s
  • 标记更改为 检查安全
  • 了解 CI/CD 工作流是如何进行的

检查我们弃用字段的用法

让我们转到 Studio 并导航到 洞察 页面，然后选择 字段 选项卡。

默认情况下，每个 都会显示 总请求度量，也被称为 请求操作，即在某给定期间所属字段的 数量。你可以使用页面上的筛选项来改变此时间段。

此度量有助于我们了解此特定 正在被使用到的频率，这正是我们要用来监控我们弃用字段的用量。我们希望此度量持续下降。

https://studio.apollographql.com

The Fields page overview in Studio

注意：还有另一种类型的度量，称为 字段执行。要查看此度量，你需要向 发送大量的请求。你可以在 执行和请求 之间的差异上了解更多信息 在 Apollo 文档中。

现在，根据自上次向 发送 以来的时间，您可能无法在此页面上看到 任何度量！我们仍然处于教程阶段，所以没有太多实际生产流量进入我们的 。

让我们进行下一步，在这里获取一些数字，以便在 拥有更多流量的情况下，我们可以了解它会是什么样子！

下面的代码沙盒包含一个脚本，它接收一个 URL，并在一段时间内向其发送请求。我们将使用它向我们的超图发送伪造流量。

继续输入您的 URL（您可以在 的 README 页面的顶部找到）。然后，单击按钮触发此脚本！

注意：目前，我们的 Poetic Plates API 没有针对恶意查询或拒绝服务 (DoS) 攻击的任何保护。在未来的某门课程中，我们将介绍更多技术来保护您的 。同时，您可以 查看 Apollo technote以了解有关速率限制、设置超时、分页等的更多信息。

检查字段用量

好了，返回我们的 页面！

  1. 在顶部，让我们搜索 text在我们的 schema 中。

  2. 从 Fields 页面的 指标中我们可以看到，我们已弃用的 text 仍在使用中。（这是我们刚才费尽心思点击的结果！）。

    https://studio.apollographql.com

    Filtering schema fields to find the text field usage

我们希望确保此 的使用量降至零。API 消费者在使用此字段时应该已经看到弃用警告，但我们还需要在其他渠道（例如 变更日志、社区群组或目标电子邮件中）对此进行发布。我们需要给他们足够的时间在其 API 中进行更改！

随着时间的推移，此特定 的使用量指标应该逐渐下降。如果没有呢？那么，我们已经设置了客户端感知，因此我们可以准确地看到哪些客户端没有遵循我们的建议！我们可以联系他们，并鼓励他们修复查询，以便在我们最终移除该字段后避免出现任何重大更改。

移除已弃用的字段

让我们假装已经过了足够的时间，我们感觉很愿意删除 ！

  1. 回到 recipes 存储库，打开 schema.graphql 文件。

  2. 找到已弃用的 text 位于 Ingredient 类型中，并将其删除。

    schema.graphql
    - "Display text for the ingredient"
    - text: String @deprecated(reason: "Use detailedDescription")

  3. 每做一次模式更改之后做什么？模式检查！在你的终端中运行 rover subgraph check 命令（用你自己的参数替换下面的参数！）

    rover subgraph check <GRAPH_REF> \
      --schema <SCHEMA_FILE_PATH> \
      --name <SUBGRAPH_NAME>

    检查评估建议的 更改是否会影响在特定时间段内在模式下执行的任何 操作。默认情况下， 配置为对在过去七天内已执行的操作运行检查。

    如果你没有在这部分和上一部分之间休息七天，那么你的操作检查很可能失败了！ 😱

    Checking the proposed schema for subgraph recipes against poetic-plates-001@main
    Compared 1 schema changes against 7 operations
    ┌────────┬───────────────┬─────────────────────────────────────────┐
    │ Change │     Code      │               Description               │
    ├────────┼───────────────┼─────────────────────────────────────────┤
    │ FAIL   │ FIELD_REMOVED │ type `Ingredient`: field `text` removed │
    └────────┴───────────────┴─────────────────────────────────────────┘
    View full details at [Studio URL].
    error[E030]: This operation check has encountered 1 schema change that would break operations from existing client traffic.
        The changes in the schema you proposed are incompatible with graph poetic-plates-supergraph@main. See https://apollo.graphql.net.cn/docs/studio/schema-checks/ for more information on resolving operation check errors.

  4. 让我们通过访问 Studio 的 检查 页面，然后单击最新的检查来调查错误。

  5. 基于对我们的 执行的历史 ，我们看到的警告是删除这个 可能会导致客户端出现严重更改。在我们（假装的）情况下，我们已经决定继续进行此更改！所以我们可以继续并覆盖此错误。

操作检查：将更改标记为安全

  1. 在“受影响操作”列表中。可能会出现多个操作，具体取决于您发送给的查询使用text 。

  2. 单击覆盖按钮。

  3. 单击将更改标记为安全。这告诉流程，可在将来的检查中安全忽略此更改。

  4. 使用覆盖，我们可以在 Studio 中重新运行检查，方法是单击重新运行检查。

这一次，检查将使用我们针对此操作设置的新配置，并且不再会因我们删除text字段而发出警报。 🥳

部署更改

让我们使用我们之前设置的精彩工作流，将这些代码和模式更改部署出去！

为我们的更改创建拉取请求

  1. 在终端窗口中创建一个新分支。（您可以为其命名任何您喜欢的名称，我们将我们的名称命名为remove-ingredient-text。

    git checkout -b remove-ingredient-text

  2. 添加schema.graphql我们对其进行更改的文件。

    git add schema.graphql

  3. 提交更改。

    git commit -m "Remove Ingredient.text field"

  4. 然后将它们推送上去！

    git push -u origin remove-ingredient-text

  5. 我们将跳回到 GitHub，为此分支创建一个针对main的拉取请求。

  6. 创建拉取请求后，我们的模式检查工作流将自动触发。我们可以单击作业以查看更多详细信息并了解工作流的运行情况。

  7. 如果作业已通过，我们就成功了！我们有信心将更改合并到main。

Railway 部署

让我们在 Railway 上关注我们的自动部署。跳到 Railway，并检查部署是否成功！

发布到 GraphOS

现在我们的已准备好更改，我们可以运行发布模式工作流！

  1. 返回 GitHub 仓库并单击操作。

  2. 从左侧的工作流列表中发布架构工作流。

  3. 单击运行工作流按钮，确保分支设置为main，然后单击运行工作流启动作业。

  4. 单击作业查看更多详细信息，看看我们的工作流实际运行的情况。

  5. 如果作业已通过，这意味着它已成功运行发布命令，所以我们可以在 Studio 中查看以确认我们的更改已成功应用！

我们向发送作为最终确认。前往资源管理器，运行前面对相同查询：

query GetRandomRecipeIngredients {
  randomRecipe {
    ingredients {
      text
      detailedDescription
    }
  }
}

我们收到一个错误！用于text 现在无效，因为它不再是我们架构的一部分。

我们已成功将从我们的架构中删除！

query GetRandomRecipeIngredients {
  randomRecipe {
    ingredients {
      detailedDescription
    }
  }
}

如果我们删除text字段，我们就可以顺利地找回正确的数据 🎉

练习

在以下哪种情况下，你可能想要覆盖操作检查失败？

关键要点

  • 请求操作按时段列出已包含某一具体的的数量。
  • 我们可以在 Studio 中覆盖一个失败的检查。
  • 检查会针对模式验证历史操作，以保证更新不会为客户端引入重大变更。

结论

您已完成！恭喜您学会如何使用 GraphOS 轻松、安全、自信地启动模式变更 😌

本课程中，我们介绍了模式中弃用的具体情况。我们学习了在我们的更新可能导致生产环境出现问题之前，如何使用发现潜在故障。我们在本地和我们的 CI/CD 管道中使用了来集成模式检查并发布我们的。我们还学习了如何在 Studio 中查看模式检查和的结果，以及如何将更改标记为可用于检查。通过模式注册表，我们可以记录每一次子图模式更改。

有了这些工具和知识，我们就可以展开 Poetic Plates 中规模更大的功能。为何不通过添加另一个来增添活力？在下一课程GraphOS：壮大您的 API中，我们将解决这些问题以及更多内容！

上一个

在此课程里分享你的问题和意见

本课程目前处于

测试版
.你的反馈可以帮助我们提升！如果你遇到困难或困惑，请告诉我们，我们会帮助你。所有评论都是公开的，必须遵循 阿波罗行为守则。请注意，已解决或已处理的评论可能会被删除。

在下面发表评论，你需要一个 GitHub 帐户。还没有吗？ 改为在我们的 Odyssey 论坛中发表评论。