概述
我们即将结束！在本课中，我们将
- 运行一些查询来测试我们的更改
- 发布新的
accounts模式到 GraphOS
测试我们的更改
我们有一些查询需要测试。我们将在 本地运行的资源管理器中运行每个 查询 访问 https://127.0.0.1:4000并确保我们能收到数据反馈。我们还会查阅一下 查询计划来验证正确的 字段来自 accounts 子图。
测试根字段
query GetMyProfile {me {idnameprofilePicture... on Host {profileDescription}}}
确保你的 标头设置为：
Authorization: Bearer user-1
你将得到
{"data": {"me": {"id": "user-1","name": "Eves","profilePicture": "https://res.cloudinary.com/apollographql/image/upload/odyssey/airlock/user-1.png","profileDescription": "I've been to 15 different planets and decided to make a home for myself and others in my favourites. Each planet and location has its own distinct environment, so read the description carefully. I have equipped them all with the necessary amenities."}}}
且 查询计划应显示这些类型和 字段来自 accounts 子图！
测试房源的房主
query GetListingHost {listing(id: "listing-1") {host {nameprofilePictureprofileDescription}}}
你将得到
{"data": {"listing": {"host": {"name": "Eves","profilePicture": "https://res.cloudinary.com/apollographql/image/upload/odyssey/airlock/user-1.png","profileDescription": "I've been to 15 different planets and decided to make a home for myself and others in my favourites. Each planet and location has its own distinct environment, so read the description carefully. I have equipped them all with the necessary amenities."}}}}
测试评论的作者
query GetListingReviewsAuthor {listing(id: "listing-1") {reviews {author {idname}}}}
且 查询计划应显示 房源记录和 评论 字段来自 monolith 子图，以及 作者 字段来自 accounts 子图！
不妨尝试其他一些查询并检查相应的 查询计划！
发布我们的子图架构
准备好将这些更改带入我们的 超级图？我们开始吧，你懂的！
在终端窗口，从根目录运行以下命令
rover subgraph publish <APOLLO_GRAPH_REF> \--schema ./subgraph-accounts/schema.graphql \--name accounts
请记住使用你自己的值替换 <APOLLO_GRAPH_REF>！
测试我们的更改
随时运行与刚才部分相同 操作（回顾第 5 课，我们使用 APOLLO_KEY=<APOLLO_KEY> APOLLO_GRAPH_REF=<APOLLO_GRAPH_REF> ./router --config router-config.yaml 在本地运行 路由器）来确保一切都运行正常！
让我们转到 架构建造器 页面，并向下滚动列表以查找 me 和 user 字段。我们可以看到 accounts 子图 现在与 monolith 列一起列出。
返回客户端
我们的客户端应用程序应该仍然在端口 3000 上运行。如果没有，请导航到客户端目录并运行 npm start。
然而，返回应用程序时，我们在主页上看到了错误！
当我们查看控制台中的错误时，我们会发现一条消息，这在该系列的第一门课程中可能会很熟悉。
Access to fetch at 'https://127.0.0.1:4000' from origin 'https://127.0.0.1:3000'has been blocked by CORS policy
在 航程 I中，我们了解了如何修改 路由器的 config.yaml文件，以允许客户端的请求到达我们的 超级图。现在，我们来将 CORS 选项添加到 config.yaml文件中，以允许我们位于 https://127.0.0.1:3000的客户端应用与我们的 路由器进行对话。
注意：您可以在 Apollo 文档中详细了解 CORS（以及它为何重要）。
CORS 配置
在服务器的 router目录中，打开 router-config.yaml。在文件底部，我们将添加以下配置：
include_subgraph_errors:all: true # Propagate errors from all subgraphsheaders:all:request:- propagate:named: "Authorization"cors:origins:- http://127.0.0.1:3000 # Allows any locally-running client to run against your Router- https://studio.apollographql.com # Allows Studio to still run queries against your Router
这些规则仍然会允许 Studio 的请求到达我们的 超级图，并且现在还允许前端应用发起的请求。
导航到 路由器当前正在运行的终端。停止服务器进程，然后重新启动。当我们刷新 https://127.0.0.1:3000时，我们会看到自己取回了数据！
随着时间的推移，当我们监控account子图的性能并认为它成功时，我们将达到一个点，我们可以安全地移除字段位于monolith子图中。然后，我们可以完全移除@override指令！
注意：如果你使用了渐进式覆盖，你将缓慢增加进入覆盖子图的流量，直至达到 100%。在那一点，你可以安全地在其他子图中移除字段。
关键要点
- 以增量方式拆分子图可以使团队更早地享受联合的好处。
- 使用
@override指令可以安全地在子图之间迁移字段。 - the路由器配置文件采用一个选项来定义 CORS 策略，它允许您指定的原点与您的路由器通信。
与 Airlock 团队联系
恭喜，我们正在建立一个完整的 超级图！还记得我们课程一开始让团队感到害怕和痛苦的庞然大物吗？让我们看看他们现在怎么说：
👩🏽🚀 会计团队表示：：
“能够专注于我们自己的 子图职责真是太好了！与之前相比，我们更快地进行更改和推送更新。对即将到来的新功能感到兴奋！”
👩🏽🏫 房源团队表示：：
“随着
accounts子图完成，整体架构变得更容易管理。我们很高兴将我们团队的域职责放在我们自己的子图上！有了 路由器设置和第一个子图开路，繁重的任务已经为我们完成，所以我们可以将它用作获取自己listings子图的蓝图。
功夫不负有心人，我们在开发人员体验方面取得了巨大飞跃和改善，这将为 Airlock 的未来创造美好的愿景！
结论
在本课程中，我们了解了如何从单块 图形迁移到 超图形。我们首先将原始图形转换为一个大型 子图，然后将其发布到 GraphOS。接着，我们使用与原始图形相同的网址安装并运行 路由器，这样客户端就不需要进行任何更改。
我们学习了如何通过识别实体、对实体进行分组，并整理出哪些类型和 字段属于哪里，从而准备并计划拆分 子图。我们从 accounts 子图开始，学习如何使用存根子图来入门。然后，我们使用 @override 指令来安全地迁移 字段从 monolith 子图到 accounts 子图。
在我们 超图形完成之前，还有四个 子图需要处理，你已经掌握了处理这些 子图所需的所有工具！
在 Voyage 系列的下一门课程中，我们将介绍如何将 Airlock 投入生产，以及如何使用 GraphOS 的 变体、模式检查和可观察性等功能。在 Voyage III：联邦投入生产中见！
分享你对本节课的问题和评论
你的反馈有助于我们提高！如果你遇到了困难或困惑，请告诉我们，我们会帮助你。所有评论都是公开的，并且必须遵循 Apollo 行为准则。请注意，已经解决或处理的评论可能会被移除。
你将需要一个 GitHub 帐号才能在下方发帖。没有 GitHub 帐号？ 改而发布在我们的 Odyssey 论坛中。