实现解析器 - GraphQL 教程 - Apollo GraphQL 中文

10. 实现解析器

10m

概述

我们添加了User 接口以及 Host 和 Guest 实体到 accounts 子图模式，但它们需要随附解析器！在本课中，我们将：

复制相关的数据源s
为根字段实施解析器
实施接口的__resolveType 解析器
为实体实施__resolveReference 解析器函数
从monolith 子图返回实体的一个表示

创建数据源

目前，我们的accounts 子图还没有连接任何数据源。但是，我们知道它需要accountsAPI 数据源来获取用户和帐户信息。

让我们来看看datasources/accounts.js在monolith目录中的文件。复制文件并将其粘贴到subgraph-accounts/datasources目录中。这让我们可以在accounts 子图中访问数据源
当你在那里时也可以删除占位符datasources.js文件在subgraph-accounts/datasources目录中。
打开subgraph-accounts/index.js并在顶部添加导入：
subgraph-accounts/index.js
const AccountsAPI = require("./datasources/accounts");

然后，找到我们返回 contextValue 对象以供解析程序使用的行。在 dataSources 对象中设置 AccountsAPI

subgraph-accounts/index.js

return {
  ...userInfo,
  dataSources: {
    accountsAPI: new AccountsAPI(),
  },
};

在初始化 AccountsAPI 时不要忘记包含 cache 以启用 RESTDataSource 缓存。
subgraph-accounts/index.js
return {
...userInfo,
dataSources: {
accountsAPI: new AccountsAPI({ cache }),
},
};

太好了，我们现在可以在解析程序中使用此数据源了！

const { ApolloServer } = require('@apollo/server');
const { startStandaloneServer } = require('@apollo/server/standalone');
const { buildSubgraphSchema } = require('@apollo/subgraph');

const { readFileSync } = require('fs');
const axios = require('axios');
const gql = require('graphql-tag');

const { AuthenticationError } = require('./utils/errors');

const typeDefs = gql(readFileSync('./schema.graphql', { encoding: 'utf-8' }));
const resolvers = require('./resolvers');
const AccountsAPI = require('./datasources/accounts');

async function startApolloServer() {
  const server = new ApolloServer({
    schema: buildSubgraphSchema({
      typeDefs,
      resolvers,
    }),
  });

  const port = 4002;
  const subgraphName = 'accounts';

  try {
    const { url } = await startStandaloneServer(server, {
      context: async ({ req }) => {
        const token = req.headers.authorization || '';
        const userId = token.split(' ')[1]; // get the user name after 'Bearer '

        let userInfo = {};
        if (userId) {
          const { data } = await axios.get(`https://127.0.0.1:4011/login/${userId}`).catch((error) => {
            throw AuthenticationError();
          });

          userInfo = { userId: data.id, userRole: data.role };
        }

        const {cache} = server;

        return {
          ...userInfo,
          dataSources: {
            accountsAPI: new AccountsAPI({cache}),
          },
        };
      },
      listen: {
        port,
      },
    });

    console.log(`🚀 Subgraph ${subgraphName} running at ${url}`);
  } catch (err) {
    console.error(err);
  }
}
startApolloServer();

`解析 Query 和 Mutation 字段`

首先解决我们根字段的解析程序

打开 accounts 子图中的 resolvers.js 文件，并删除使用模板提供的默认查询及其解析程序函数 _todo
subgraph-accounts/resolvers.js
const resolvers = {
- Query: {
- _todo: () => "TODO",
- },
};

查找 resolvers 适用于 Query.user、 Query.me 和 Mutation.updateProfile 在 monolith/resolvers.js 文件中（或您可以将它们复制到下面）。我们将把它们粘贴到 resolvers 映射中 accounts subgraph.

subgraph-accounts/resolvers.js

Query: {
  user: async (_, { id }, { dataSources }) => {
    const user = await dataSources.accountsAPI.getUser(id);
    if (!user) {
      throw new Error("No user found for this Id");
    }
    return user;
  },
  me: async (_, __, { dataSources, userId }) => {
    if (!userId) throw new AuthenticationError(authErrMessage);
    const user = await dataSources.accountsAPI.getUser(userId);
    return user;
  },
},
Mutation: {
  updateProfile: async (
    _,
    { updateProfileInput },
    { dataSources, userId }
  ) => {
    if (!userId) throw new AuthenticationError(authErrMessage);
    try {
      const updatedUser = await dataSources.accountsAPI.updateUser({
        userId,
        userInfo: updateProfileInput,
      });
      return {
        code: 200,
        success: true,
        message: "Profile successfully updated!",
        user: updatedUser,
      };
    } catch (err) {
      return {
        code: 400,
        success: false,
        message: err.message,
      };
    }
  },
},

`解析接口`

接下来让我们解决 User 接口，它需要一个 resolveType。我们实际上已经有一个在 monolith subgraph 中定义好了，因此我们需要做的就是将该函数复制到 accounts subgraph.

subgraph-accounts/resolvers.js

User: {
  __resolveType(user) {
    return user.role;
  }
},

`解析实体`

正如我们在Voyage I 中介绍过的，向 entity 贡献字段的 subgraphs 使用一种特殊的 resolver，称为引用 resolver 来解析实体。此函数使 router 可以直接访问每个 subgraph 贡献的 entity 字段。

每个引用 解析器都有一个名称 __resolveReference。它是带有三个 参数的函数：
reference： 实体表示对象，它由 路由器传入，其中包括实体的 __typename和 @key 字段。这告诉 子图正在请求哪个 实体实例。如我们曾在 探索之旅 1中讨论的，这就像 路由器可以用来在 子图之间引用同一个对象的通行证！
context：在为特定 操作执行的所有 解析器之间共享的对象，就像在一般解析器中一样。（请注意，按照惯例，我们将此 __resolveReference 参数称为 context，而不是在其他 解析器中使用的 contextValue！）
info：有关 操作执行状态的信息，包括 字段名称和从根到字段的路径，就像普通 解析器中一样。

我们将为 Host和 Guest实体在 accounts 子图中实现引用解析器。

在 resolvers对象中，为 Host类型添加一个引用解析器：
subgraph-accounts/resolvers.js
Host: {
__resolveReference: (user, { dataSources }) => {
return dataSources.accountsAPI.getUser(user.id);
},
},
我们正在使用 accountsAPI 数据源的 getUser方法，并向其传递用于检索该用户信息的用户的 id。

我们为 Guest类型添加一个类似的引用解析器。

subgraph-accounts/resolvers.js

Guest: {
  __resolveReference: (user, { dataSources }) => {
    return dataSources.accountsAPI.getUser(user.id);
  },
},

完美，这些实体有自己的引用解析器！

const { AuthenticationError, ForbiddenError } = require("./utils/errors");
const resolvers = {
  Query: {
    user: async (_, { id }, { dataSources }) => {
      const user = await dataSources.accountsAPI.getUser(id);
      if (!user) {
        throw new Error("No user found for this Id");
      }
      return user;
    },
    me: async (_, __, { dataSources, userId }) => {
      if (!userId) throw new AuthenticationError(authErrMessage);
      const user = await dataSources.accountsAPI.getUser(userId);
      return user;
    },
  },
  Mutation: {
    updateProfile: async (
      _,
      { updateProfileInput },
      { dataSources, userId }
    ) => {
      if (!userId) throw new AuthenticationError(authErrMessage);
      try {
        const updatedUser = await dataSources.accountsAPI.updateUser({
          userId,
          userInfo: updateProfileInput,
        });
        return {
          code: 200,
          success: true,
          message: "Profile successfully updated!",
          user: updatedUser,
        };
      } catch (err) {
        return {
          code: 400,
          success: false,
          message: err.message,
        };
      }
    },
  },
  Host: {
    __resolveReference: (user, { dataSources }) => {
      return dataSources.accountsAPI.getUser(user.id);
    },
  },
  Guest: {
    __resolveReference: (user, { dataSources }) => {
      return dataSources.accountsAPI.getUser(user.id);
    },
  },
  User: {
    __resolveType(user) {
      return user.role;
    },
  },
};

module.exports = resolvers;

我们已用解析器覆盖了所有 accounts模式字段。在测试我们的更改之前，还有一件事...

`monolith 子图`

在前面的课程中，我们提到我们可以在字段中包含其他 accounts 子图，具体来说是： Listing.host、 Booking.guest和 Review.author。我们将暂时保留这些字段在 monolith模式中（最终，它们将迁移到各自的 listings、 bookings和 reviews 子图中），但我们可以更新解析器。

目前，这些字段的每一个解析器都使用 Accounts API。例如：

monolith/resolvers.js

Listing: {
  host: ({ hostId }, _, { dataSources }) => {
    return dataSources.accountsAPI.getUser(hostId);
  },
  // other resolvers
}

我们想要开始消除对 Accounts 服务的依赖（毕竟，这就是 accounts 子图的用处！）。因此，我们将删除这些对 accountsAPI的调用并返回实体表示。

`返回实体表示`

如果您回想起航行 I，实体表示形式是一个对象，路由器使用它从另一个子图表示一个特定的实体。它包含一个 __typename属性以及实体的主键字段的值。在我们的示例中，Host和 Guest的主键字段都是id。

我们将为 monolith 子图中的以下每个解析器返回实体表示形式：

Listing.host，它返回Host类型
Booking.guest，它返回Guest类型
Review.author，它返回User类型

要开始处理，请打开 resolvers.js文件（位于monolith目录中）。

`Listing.host`

让我们查找一下 Listing.host 解析器。我们将删除函数的主体，它当前调用 accountsAPI 数据源。我们现在希望这个解析器返回 Host 实体的表示。

monolith/resolvers.js

Listing: {
  host: ({ hostId }) => {
    return { id: hostId };
  },
}

在这里，我们解构了 parent 参数（它是一个 Listing 对象) 以检索 hostId 属性。此 hostId 用于作为主键字段 id的值。

注意：我们不需要在此实体表示中包含 __typename 字段。路由器会自动得知如何获取 __typename 字段（因为 __typename 是元-字段，根据 GraphQL 规范，它会包含在所有对象中)。

`Booking.guest`

让我们对 Booking.guest 解析器执行相同的操作。在 resolvers.js 文件中查找解析器并替换函数的主体，以便它返回一个对象作为实体表示。

monolith/resolvers.js

Booking: {
  // other Booking resolvers
  guest: ({ guestId }) => {
    return { id: guestId };
  },
}

类似于 Listing.host 解析器，在这里我们解构了 parent 参数（Booking 对象）以检索 guestId 属性。该 guestId 被用作主键字段 id 的值。

`Review.author`

最后，我们有 Review.author 解析器，我们对其的处理会略有不同。

在模式中， Review.author 字段返回 User 接口，它是一种抽象类型。因此， Review.author 解析器需要指定返回类型是 Host 还是 Guest，并在其实体表示中将其包含为 __typename。

为了确定类型，我们需要看看特定业务领域的逻辑。我们知道，只有房客才能为房源和房东撰写评论。类似地，只有房东才能为房客撰写评论。知道这一点，我们可以调查 Review 对象的形状并确定哪个属性可能有助于我们完成该逻辑。以下是评论的样例：

{
  "id": "review-1",
  "authorId": "user-2",
  "targetId": "listing-1",
  "bookingId": "booking-1",
  "targetType": "LISTING",
  "text": "Wow, what an experience! I've never stayed in a cave before, so I was a little unprepared. Luckily, this listing had all the amenities I needed to feel safe and prepared for anything.",
  "rating": 4
}

我们可以使用评论的 targetType 属性（它将是 LISTING、GUEST 或 HOST）来确定评论作者的类型。如果用户正在撰写有关房源或房东的评论，我们可以放心地认为该用户是房客！

查找 Review.author 解析器在 resolvers.js 文件中，并用以下内容替换它：

monolith/resolvers.js

Review: {
  author: (review) => {
    let role = '';
    if (review.targetType === 'LISTING' || review.targetType === 'HOST') {
      role = 'Guest';
    } else {
      role = 'Host';
    }
    return { __typename: role, id: review.authorId, role };
  },
},

注意：我们已将解析器的第一个参数 (parent) 重命名为 review 以明确参数的类型。

现在，在调用 Review.author() 解析器 之后，User.__resolveType() 函数将是下一个在 解析器 链中被调用的函数。该函数要求其 parent 对象中包含一个名为 role 的属性，以便确定其应返回的实现类型（Host 或 Guest）。
另一种方法是删除 User.__resolveType 函数，因为 monolith 子图 中所有返回 User 类型的 字段 已迁移到 accounts 子图。

而对于所有解析器而言，它们返回的都是实体表示，到此为止了！

`练习`

将此架构用于以下代码挑战

interface Book {
  isbn: ID!
  title: String!
  genre: String!
}

type PictureBook implements Book @key(fields: "isbn") {
  isbn: ID!
  title: String!
  genre: String!
  numberOfPictures: Int
  isInColor: Boolean
}

type YoungAdultNovel implements Book {
  isbn: ID!
  title: String!
  genre: String!
  wordCount: Int
  numberOfChapters: Int
}

type LibraryMember @key(fields: "id") {
  id: ID! @external
  faveBook: Book!
}

代码挑战！

为 LibraryMember.faveBook 编写解析器以返回实体的表示形式。每本书的底层对象都包含一个 hasPictures 属性，您可以用它来判断它是一个 PictureBook 还是一个 YoungAdultNovel。

`要点`

任何子图向实体贡献字段的都需要针对该实体定义一个 __resolveReference 解析器函数。
一个实体表示形式是一个包含实体的 __typename和 @key 字段的对象。
一个接口需要一个 __resolveType 解析器。

`下一步`

哇，这就是关于解析器的所有内容了！在下一课中，我们将在本地测试我们的更改是否正常工作，然后再在 GraphOS中发布新的子图！

上一个

下一个

`分享你对此课程的问题和评论`

您的反馈有助于我们改进！如果您陷入困境或困惑，请告诉我们，我们会帮助您的。所有评论都是公开的，并且必须遵守 Apollo 行为准则。请注意，已解决或处理的评论可能会被删除。

您需要一个 GitHub 帐户才能在下面发帖。没有吗？改为在我们的 Odyssey 论坛中发帖。