99designs / 99designs/gqlgen

Optimized batch loading without blocking

未关闭
#518 28 条评论 21 个 reaction 已指派 0 人 在 GitHub 查看
accepted execution performance
主要语言
Go
星标
10.8k
派生
1.3k
平均合并
2 天 36 分钟
30 天内合并 PR
26

描述

I'm trying to understand how `gqlgen` can optimize batch loading lazily/concurrently, given that all resolvers are synchronous — i.e. they return the value itself, instead of a thunk (future).

I was reading through the code example for data loading to try to understand how `dataloaden` works. In the its code, I noticed that `Load(key)` simply calls `LoadThunk(key)()`. Then I noticed this line in the readme: "This method will block for a short amount of time, waiting for any other similar requests to come in". Is this how gqlgen assumes it will work?

If you look at the [graphql-go project](https://www.github.com/graphql-go/graphql), all resolvers can return either values or thunks. This means the entire GraphQL tree can be resolved to thunks, which can then queue up all the keys they need so that when the thunks are called, all the objects can be fetched at once.

Can someone fill me in on how gqlgen is supposed to handle this? A resolver like this:

```
func (r *rootQueryResolver) Things(ctx context.Context, uids []*string, limit *int) ([]*models.Thing, error) {
// ...
}
```

...cannot defer any work at all; it has to return. The only way to batch this is to execute all the resolvers concurrently in goroutines, then have some kind of queue that keeps track of when they've all resolved their keys — or just wait for an arbitrary interval. That seems wrong to me, and all the attendant synchronization sounds like it would be super inefficient.

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。