Simplfy concurrent resolver logic

[vektah]

Before tackling #275 directly a little cleanup on concurrent resolvers is required. There currently isn't anywhere to add the required checks at the object level.

This pulls the concurrency logic out of individual graphql.Defer functions and moves it up into the object where we can put this bubbling logic. It also moves the recover function into the middleware stack, removing some duplicated code.

[dvic]

@vektah @mathewbyrne shouldn't each item in an array also be resolved in parallel? (see line here) If not, how would one otherwise benefit from using dataloader implementations? Or am I missing something?

I noticed this when I upgraded to 0.4.x, which caused approximately a 10x increase in the number of SQL queries.

[vektah]

@dvic this PR hasn't made it to a tagged release yet, are you seeing this behaviour in 0.4.4?

Thanks for the heads up, I will do some more testing.

[dvic]

@vektah No, the behavior is introduced with this commit, 0.4.4 works fine (produces the same amount of queries as previous versions). It's because of the sync resolving of array elements (done here). This commit changes the behavior so that resolving a field blocks on returning a graphql.Marshaler, while previously this was not the case.

By the way: I have tried a parallel version of the for loop in question (commenting out rctx.PushIndex({{.index}}) and rctx.Pop()) and the number of queries is back to normal again. So it's definitely the cause of the problem.

[dvic]

@vektah should I open a ticket for this?

[vektah]

If you like, I'm hoping to look at it tomorrow.