如何在GraphQL中编写对关系数据库运行良好的查询解析器?
使用this tutorial中的示例模式,假设我有一个包含users
和stories
的简单数据库。用户可以创作多个故事但故事只有一个用户作为他们的作者(为简单起见)。
在查询用户时,可能还需要获取该用户创作的所有故事的列表。一个可能的定义是GraphQL查询来处理它(从上面链接的教程中窃取):
const Query = new GraphQLObjectType({
name: 'Query',
fields: () => ({
user: {
type: User,
args: {
id: {
type: new GraphQLNonNull(GraphQLID)
}
},
resolve(parent, {id}, {db}) {
return db.get(`
SELECT * FROM User WHERE id = $id
`, {$id: id});
}
},
})
});
const User = new GraphQLObjectType({
name: 'User',
fields: () => ({
id: {
type: GraphQLID
},
name: {
type: GraphQLString
},
stories: {
type: new GraphQLList(Story),
resolve(parent, args, {db}) {
return db.all(`
SELECT * FROM Story WHERE author = $user
`, {$user: parent.id});
}
}
})
});
这将按预期工作;如果我查询特定用户,我将能够在需要时获得该用户的故事。但是,这并不理想。当具有JOIN
的单个查询足够时,它需要两次访问数据库。如果我查询多个用户,问题会被放大 - 每个额外的用户都会导致额外的数据库查询。我遍历对象关系时,问题会越来越严重。
这个问题已经解决了吗?有没有办法编写一个不会导致生成低效SQL查询的查询解析器?
答案 0 :(得分:8)
这种问题有两种方法。
Facebook使用的一种方法是将请求发生在一个标记中,并在发送之前将它们组合在一起。这样,您可以执行一个请求来检索有关多个用户的信息,而不是为每个用户执行请求。 Dan Schafer写了good comment explaining this approach。 Facebook发布了Dataloader,这是该技术的一个示例实现。
// Pass this to graphql-js context
const storyLoader = new DataLoader((authorIds) => {
return db.all(
`SELECT * FROM Story WHERE author IN (${authorIds.join(',')})`
).then((rows) => {
// Order rows so they match orde of authorIds
const result = {};
for (const row of rows) {
const existing = result[row.author] || [];
existing.push(row);
result[row.author] = existing;
}
const array = [];
for (const author of authorIds) {
array.push(result[author] || []);
}
return array;
});
});
// Then use dataloader in your type
const User = new GraphQLObjectType({
name: 'User',
fields: () => ({
id: {
type: GraphQLID
},
name: {
type: GraphQLString
},
stories: {
type: new GraphQLList(Story),
resolve(parent, args, {rootValue: {storyLoader}}) {
return storyLoader.load(parent.id);
}
}
})
});
虽然这并不能解决高效的SQL问题,但对于许多用例而言,它仍然可能已经足够好,并且可以让内容运行得更快。对于不允许加入的非关系型数据库来说,它也是一种很好的方法。
另一种方法是在解析函数中使用有关请求字段的信息,以便在相关时使用JOIN。 Resolve context具有fieldASTs
字段,该字段已解析当前已解析的查询部分的AST。通过查看AST(selectionSet)的子项,我们可以预测是否需要连接。一个非常简单和笨重的例子:
const User = new GraphQLObjectType({
name: 'User',
fields: () => ({
id: {
type: GraphQLID
},
name: {
type: GraphQLString
},
stories: {
type: new GraphQLList(Story),
resolve(parent, args, {rootValue: {storyLoader}}) {
// if stories were pre-fetched use that
if (parent.stories) {
return parent.stories;
} else {
// otherwise request them normally
return db.all(`
SELECT * FROM Story WHERE author = $user
`, {$user: parent.id});
}
}
}
})
});
const Query = new GraphQLObjectType({
name: 'Query',
fields: () => ({
user: {
type: User,
args: {
id: {
type: new GraphQLNonNull(GraphQLID)
}
},
resolve(parent, {id}, {rootValue: {db}, fieldASTs}) {
// find names of all child fields
const childFields = fieldASTs[0].selectionSet.selections.map(
(set) => set.name.value
);
if (childFields.includes('stories')) {
// use join to optimize
return db.all(`
SELECT * FROM User INNER JOIN Story ON User.id = Story.author WHERE User.id = $id
`, {$id: id}).then((rows) => {
if (rows.length > 0) {
return {
id: rows[0].author,
name: rows[0].name,
stories: rows
};
} else {
return db.get(`
SELECT * FROM User WHERE id = $id
`, {$id: id}
);
}
});
} else {
return db.get(`
SELECT * FROM User WHERE id = $id
`, {$id: id}
);
}
}
},
})
});
请注意,这可能会对例如碎片产生问题。然而,人们也可以处理它们,这只是更详细地检查选择集的问题。
graphql-js存储库中目前有PR,它允许通过提供“解决方案”来编写更复杂的逻辑以进行查询优化。在上下文中。