Add execution path information to Info variable

[ekampf]

• Added path variable to ResolveInfo to be used for tracing and error information
• Added extensions to ExecutionResult to allow adding extension data to graphql results

The path information. is useful for implementing Tracing (in a separate PR under graphql-server-core) and better error information as specified in issues #127 and #131

[ekampf]

@syrusakbary I think this is ready for your review

[ekampf]

@syrusakbary ?

[brentmclark]

Looks great, and nice work on the test!

[pobed2]

This is awesome, @ekampf! @syrusakbary, any thoughts on merging this PR?

[ekampf]

@syrusakbary ping

[syrusakbary]

The PR looks great! I'm a bit worried about the performance in big outputs, but I guess is better try and see :)

[ekampf]

yey! :)

[joealcorn]

@ekampf thanks for this, and to @syrusakbary & @brentmclark too of course!

I see you implemented a TracingMiddleware but reverted it before the merge. I've got a fork here with that functionality re-instated as it hasn't been added to graphql-server-core yet, but I'm interested in doing so.

If possible I'd like to get a bit of background on graphql-server-core. How all the different packages interact is something that has taken me a while to figure out. I'm using graphene 2.0.1, graphene-django 2.0 and graphql-core 2.0.1, but as far as I can tell graphql-server-core is not used. Does anybody have an insight into how it fits in here?

[olasitarska]

@joealcorn just came across an exact same question after few hours of digging around and trying to figure out which package does what :) Looks like we're trying to do the same thing, and came to the same conclusions. Let me know if you need any help and I'd be quite happy to collaborate on this!

[ekampf]

@joealcorn @olasitarska to my understanding, graphql-core deals with parsing and executing GraphQL queries, while graphql-server-core deals with exposing that functionality under http.
It seemed more logical to me to have the TracingMiddleware there..
Here's an unfinished PR you're welcome to help test - https://github.com/ekampf/graphql-server-core/tree/feature/tracing

[joealcorn]

I have no numbers, but I would hazard a guess that many (most?) people using graphql-core are using django & graphene-django who won't be able to benefit from this (as it doesn't appear to use graphql-server-core).

Perhaps the tracing middleware could be extracted to a separate library and installed alongside grapqhl-core as an extra? Like pip install graphql-core[tracing]

In the meantime my fork appears to work well (seems to be reporting correctly at least) which uses your work @ekampf

[ekampf]

@joealcorn why not have graphene-django use graphql-server-core ?
For starters it can just import the middleware from it and use it in GraphQLView but I think on the longer term, GraphQLView is largely a duplication of server-core's function (even has the same function names) so it would be ideal to de-duplicate that code...

Did you use the tracing middleware with Apollo Optics? it works?

[joealcorn]

why not have graphene-django use graphql-server-core ?

I assume that's the long term plan and probably a good direction to go. If memory serves I'm stuck on an old version of graphene/graphene-django for a while (old django version) so that may not work for me just yet.

Did you use the tracing middleware with Apollo Optics? it works?

Yes, it seems to work fine with apollo engine (formerly optics). I had to make some small tweaks (like changing from ms to ns)

Here's a screenie of the trace view working:

[ekampf]

@joealcorn woa! awesome!
can you PR your changes into my branch and then lets submit a PR to the main library?

[joealcorn]

@ekampf Good idea, I will get on that later this week