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 = {
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
},
},
};
乍一看，这似乎没问题。但这就是为什么它有问题：
1. 重复的逻辑
您被迫在出现用户类型的每个解析器中调用maptouser。忘记调用它或错误地调用它可能会导致 api 中的行为不一致。
2. 打破抽象
graphql 的解析器系统旨在集中解决每种类型的方式。通过使用实用程序方法，您可以回避此功能并使您的代码不太直观。
3. 失去灵活性
如果您需要修改 user 类型的解析方式（例如，添加新字段或处理错误），则必须查找调用 maptouser 的每个位置，而不是更新单个解析器。
更好的方法：杠杆式旋转变压器
不要使用实用方法，而是为 graphql 类型定义解析器。以下是重写上面示例的方法：
const resolvers: Resolvers= { 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); }, }, };
为什么这更好
- 一致性：用户解析器确保所有用户实例都以相同的方式解析，无论它们出现在架构中的哪个位置。
- 集中逻辑：只需在一处更改用户的解析方式。
- 利用 graphql 的优势：通过采用解析器系统，您可以与 graphql 的核心设计原则保持一致并充分发挥其潜力。
结论
在解析器中使用实用方法似乎是一种捷径，但它最终会破坏 graphql 的强大功能和优雅性。通过为您的类型定义解析器，您可以维护一个干净、一致且可扩展的 api。因此，停止在解析器中使用 utils，拥抱 graphql 提供的抽象——未来的你会感谢你的！
