graphql查询mysql_graphql查询方案优化
graphql查询方案优化
起因
graphql API对外提供完整的接口文档，按需取数据的功能，对于接口联调和前端开发同学看来绝对是神器，但对于初看graphql的后台同学看来，这个取数据怎么取？对于一个两层结构的列表数据，我对列表中的每一项都取一次二级数据？这后台抗得住吗？
举个例子：我们有这样一个应用场景，我们要取一个用户列表，列表中每一项展示有3个字段id、name、friends，friends字段是一个数组，结果集中要做二层展开，展开成id、name，结果集如下:
{
"data": {
"userList": [
{
"id": "1",
"name": "Dan",
"friends": [
{
"id": "2",
"name": "Marie"
},
{
"id": "3",
"name": "Jessie"
}
]
},
{
"id": "2",
"name": "Marie",
"friends": [
{
"id": "1",
"name": "Dan"
}
]
},
{
"id": "3",
"name": "Jessie",
"friends": [
{
"id": "1",
"name": "Dan"
}
]
}
]
}
}
DB中数据结构如下，我们这里使用json文件存储数据，
用户信息表
{
"1": {
"id": "1",
"name": "Dan"
},
"2": {
"id": "2",
"name": "Marie"
},
"3": {
"id": "3",
"name": "Jessie"
}
}
用户关系表
{
"1":[
2,
3
],
"2":[
1
],
"3":[
1
]
}
DB层对外提供fakeDB.getAll获取用户列表接口，fakeDB.getFriendsInfo获取用户朋友信息接口，HTTP层再做一层封装，对外提供userBiz.getAll获取用户列表接口，userBiz.getFriendsInfo获取用户朋友信息接口，这样graphql中阶层获取数据请求数据的方式是先调用userBiz.getAll接口获取用户列表，再依次对每个用户调用一遍userBiz.getFriendsInfo接口获取列表每一项的friends字段，日志输出结果如下:
get all
get friends info1
get friends info2
get friends info3
这样列表项有多少项，就需要发起多少个userBiz.getFriendsInfo接口的HTTP调用，如果返回数据列表项再加大，数据层级再加深，HTTP调用的数量将会变得非常大，有没有办法减少HTTP调用呢，graphql实际上已经提供了解决方案
解决方案
graphql引入dataloader组件，提供合并请求的能力，dataloader的原理很简单，他利用nodejs的next tick机制，需要额外后台额外增加一个批量获取用户朋友信息的HTTP接口，修改graphql的schema，使其使用dataloader的方式，dataloader的具体配置详见附件代码，日志输出结果如下:
get all
get batch friends info 1,2,3
可见对列表项中的每一项获取friends信息合并成了一个HTTP请求
总结
这里假设的场景是一个graphql中间层调用HTTP接口的合并，如果使用graphql作为server端接口标准，同样可以使用dataloader合并sql层的访问