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.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 }, }, };
乍一看,这似乎没问题。但这就是它有问题的原因:
您被迫在出现用户类型的每个解析器中调用mapToUser。忘记调用它或错误地调用它可能会导致 API 中的行为不一致。
GraphQL 的解析器系统旨在集中解决每种类型的方式。通过使用实用程序方法,您可以回避此功能并使您的代码不太直观。
如果您需要修改用户类型的解析方式(例如,添加新字段或处理错误),您将必须寻找调用 mapToUser 的每个位置,而不是更新单个解析器。
不要使用实用方法,而是为 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! }
在解析器中使用实用方法似乎是一种捷径,但它最终会破坏 GraphQL 的强大功能和优雅性。通过为您的类型定义解析器,您可以维护一个干净、一致且可扩展的 API。因此,停止在解析器中使用 utils,拥抱 GraphQL 提供的抽象——未来的你会感谢你的!
以上是为什么应该避免 GraphQL 解析器中的实用方法的详细内容。更多信息请关注PHP中文网其他相关文章!