首页 > web前端 > js教程 > 正文

为什么应该避免在 GraphQL 解析器中使用实用方法

霞舞
发布: 2024-12-05 08:33:47
转载
780人浏览过

为什么应该避免在 graphql 解析器中使用实用方法

graphql 彻底改变了我们获取和塑造数据的方式,在客户端和服务器之间提供了一个干净的抽象层。它的核心功能之一是解析器,它允许我们定义模式中的每个字段如何获取其数据。在某些情况下,开发人员可能会通过依赖解析器中的实用方法无意中削弱 graphql 的优势。这种做法不仅违背了 graphql 的设计初衷,还引入了不必要的复杂性和潜在的 bug。

让我们深入探讨为什么会出现这个问题以及如何做得更好。

旋转变压器的力量

在 graphql 中,会为类型的每个实例调用解析器,无论该类型出现在架构中的位置。这种抽象确保了解析数据的逻辑在整体上保持一致。例如:

schema {
  query: query
}

type query {
  project(id: id!): project
  user(id: id!): user
}

type project {
  id: id!
  name: string!
  owner: user!
}

type user {
  id: id!
  name: string!
  email: string!
}
登录后复制

这里,user 类型在两个地方使用:直接在 query 中用于获取用户,以及作为所有者嵌套在 project 类型中。借助 graphql 的解析器系统,我们可以定义单个 user 解析器来处理 user 字段的解析方式,确保 user 出现的任何地方的行为一致。

utils 的问题

当您引入实用方法来在解析器之外塑造数据时,您就打破了这种抽象。考虑这个例子:

// utils.ts
function maptouser(userdata: datasourceuser) {
  return {
    id: userdata.id,
    name: userdata.full_name,
    email: userdata.contact_email,
  };
}

// resolvers.ts
const resolvers: resolvers<context> = {
  query: {
    project: async (_, { id }, { datasources }) => {
      const project = await datasources.projectapi.getproject(id);
      return {
        ...project,
        owner: maptouser(project.owner), // utility method called here
      };
    },
    user: async (_, { id }, { datasources }) => {
      const user = await datasources.userapi.getuser(id);
      return maptouser(user); // utility method called here
    },
  },
};
登录后复制

乍一看,这似乎没问题。但这就是为什么它有问题:

ChatGPT Website Builder
ChatGPT Website Builder

ChatGPT网站生成器,AI对话快速生成网站

ChatGPT Website Builder 165
查看详情 ChatGPT Website Builder

1. 重复的逻辑

您被迫在出现用户类型的每个解析器中调用maptouser。忘记调用它或错误地调用它可能会导致 api 中的行为不一致。

2. 打破抽象

graphql 的解析器系统旨在集中解决每种类型的方式。通过使用实用程序方法,您可以回避此功能并使您的代码不太直观。

3. 失去灵活性

如果您需要修改 user 类型的解析方式(例如,添加新字段或处理错误),则必须查找调用 maptouser 的每个位置,而不是更新单个解析器。

更好的方法:杠杆式旋转变压器

不要使用实用方法,而是为 graphql 类型定义解析器。以下是重写上面示例的方法:

const resolvers: Resolvers<Context> = {
  Query: {
    project: async (_, { id }, { dataSources }) => {
      return dataSources.projectAPI.getProject(id);
    },
    user: async (_, { id }, { dataSources }) => {
      return dataSources.userAPI.getUser(id);
    },
  },
  User: {
    id: (user) => user.id,
    name: (user) => user.full_name,
    email: (user) => user.contact_email,
  },
  Project: {
    owner: (project, _, { dataSources }) => {
      return dataSources.userAPI.getUser(project.ownerId);
    },
  },
};
登录后复制

为什么这更好

  1. 一致性:用户解析器确保所有用户实例都以相同的方式解析,无论它们出现在架构中的哪个位置。
  2. 集中逻辑:只需在一处更改用户的解析方式。
  3. 利用 graphql 的优势:通过采用解析器系统,您可以与 graphql 的核心设计原则保持一致并充分发挥其潜力。

结论

在解析器中使用实用方法似乎是一种捷径,但它最终会破坏 graphql 的强大功能和优雅性。通过为您的类型定义解析器,您可以维护一个干净、一致且可扩展的 api。因此,停止在解析器中使用 utils,拥抱 graphql 提供的抽象——未来的你会感谢你的!

以上就是为什么应该避免在 GraphQL 解析器中使用实用方法的详细内容,更多请关注php中文网其它相关文章!

相关标签:
最佳 Windows 性能的顶级免费优化软件
最佳 Windows 性能的顶级免费优化软件

每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。

下载
来源:dev.to网
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
最新问题
开源免费商场系统广告
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板
关于我们 免责申明 举报中心 意见反馈 讲师合作 广告合作 最新更新 English
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号 技术交流群
PHP中文网订阅号
每天精选资源文章推送
PHP中文网APP
随时随地碎片化学习

Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号