我们已经实现了我们的解析器 和我们的 数据源,我们也将其连接到服务器。现在,是时候找出所有东西是否协同工作以真正提供实时数据了。
您可以追踪您的 查询 的旅程一直回到客户端,并期望在浏览器中看到实时数据,但实际上有一个通往服务器的秘密捷径: GraphOS Studio 浏览器!它允许您连接到当前运行在 localhost:4000
的服务器,并帮助您快速构建查询以进行测试。
我们的服务器仍在运行,因此您应该在终端中看到一条消息,指出服务器确实正在运行,我们可以开始 查询 使用浏览器提供的链接。
要打开浏览器 Apollo Sandbox,您可以 cmd+click
终端中提供的 URL(从启动服务器开始)以在浏览器中打开它,或者您也可以在这里打开它: https://127.0.0.1:4000。
我们可以使用我们从发射 I 中的示例 查询 来测试我们新的 解析器:
query GetTracks {tracksForHome {idtitlethumbnaillengthmodulesCountauthor {idnamephoto}}}
让我们继续运行它... 我们得到了解析器返回的数据!🎉 我们还可以看到,我们只得到了我们查询的确切数据,没有额外的数据,即使我们的 REST 终端没有这样结构化。这意味着解析器已经完成了它的任务,我们也完成了!
在 GraphOS Studio 浏览器中,测试与我们在第一部分中使用的 tracksForHome
查询相同的查询(或复制上面的查询并将其粘贴到浏览器中)。运行查询并复制粘贴最后一个 tracks
条目。
让我们再次点击 查询 按钮。您注意到第二次响应有多快吗?第一个大约用了半秒,然后这个只用了几毫秒就返回了。这得益于我们的 RESTDataSource
的内置资源缓存。
仅仅是为了比较,您可以看一下 fetch
下面的实现。一个新的 字段 被称为 tracksforHomeFetch
被添加到我们的模式中。 解析器 正在使用 node-fetch
而不是 RESTDataSource
。对于每一次调用,响应都需要相同的时间,大约半秒。效率要低得多,现在我们真正地看到了为什么我们应该继续使用 RESTDataSource
实现!
注意: 不要将下面的两个代码片段复制到您的项目中;您可以 在存储库的 fetch-example-AS4
分支的 final
文件夹中找到完整的 fetch 代码示例。
const typeDefs = gql`type Query {tracksForHome: [Track!]!tracksForHomeFetch: [Track!]!}# ...`;
const resolvers = {Query: {tracksForHome: () => {// ...}tracksForHomeFetch: async () => {const baseUrl = "https://odyssey-lift-off-rest-api.herokuapp.com";const res = await fetch(`${baseUrl}/tracks`);return res.json();},},Track: {// using fetch instead of dataSourcesauthor: async ({ authorId }, _, { dataSources }) => {const baseUrl = "https://odyssey-lift-off-rest-api.herokuapp.com";const res = await fetch(`${baseUrl}/author/${authorId}`);return res.json();// return dataSources.trackAPI.getAuthor(authorId);},},}
RESTDataSource
的查询和使用简单 fetch 方法的查询,在浏览器中展示了哪些内容?分享您关于本课的问题和评论
您的反馈有助于我们改进!如果您遇到困难或困惑,请告诉我们,我们会帮助您。所有评论都是公开的,必须遵守 Apollo 行为准则。请注意,已解决或已处理的评论可能会被删除。
您需要一个 GitHub 帐户才能在下方发布。没有帐户? 请在我们的 Odyssey 论坛中发布。