ariadne
ariadne copied to clipboard
mirumee
ApolloTracing in federation is not supported
I believe that apollotracing extension we have is not using the correct specs. It seems the tracing should be base64 encoded on protobuf and then put as value to the key ftv1 under extensions as described here https://www.apollographql.com/docs/federation/metrics/
Right now it just returns a json with the key tracing under extensions so apollo fails to parse it
The docs you are linking to seems to be only for federations.
We only support ApolloTracing v1 where tracing report is returned under extensions key for GraphQL playground to ingest and display. If they've released other versions of spec in the meantime (and they likely did seeing how they are monetizing this with Apollo Studio), new version of tracing extension will have to be implemented.
Some thing probably would have to be done tracing in federations.
Do you have any plans to implement this then considering Apollo is such a big player and I assume its going to be useful for a lot of people.
Not at the moment, I'm afraid.
But pull request is always welcome - if problem really is just different key to use in extensions, it should be simple enough to contribute.
Thanks for the comment. Well its more than that. The spec is slightly bit different. Will post any updates here if I do have the time to do it myself
FYI - I built a working implementation that I am using on my team right now that follows Apollo's new spec with protobuff but its not exhaustive in any sense (it only sends fields traces but nothing related to errors). But while working on it I stumbled across another potential issue that exists in the default Apollotracing extension in Ariadne which is documented here If I could get some clarification that would be great. I could probably upstream some stuff once I figure everything out
@rafalp I am really diving into the tracing part and I have a question which is kinda related. Can you confirm that this line is kind of a proxy check if its a default resolver or not. To me it seems it just checks if there is a resolver set for that field. If not then we can assume it is a default resolver there obviously because that segment of the field is still being resolved and run. So why two separate checks one with the line and another with is_default_resolver(resolver). I feel that line should be part of the is_default_resolver function
Hi @nilansaha @rafalp Phil from Apollo here 👋 ... would love to collaborate on helping get federation tracing support added to ariadne if you like. What can we do to help?
cc @abernix @mandiwise @michael-watson
Hello @nilansaha and @rafalp, I'm also from Apollo and have an example of basic support for federated tracing implemented via an Ariadne extension here:
https://github.com/apollosolutions/ariadne-federated-traces
I mostly write Python on a recreational basis only, so I'm sure it can be improved upon. But hopefully the code will be a useful point of reference for you. The InlineTraceExtension class is based on Apollo Server's ApolloServerPluginInlineTrace class (as well as the related TraceTreeBuilder class). Those classes provide a nearly line-for-line re-implementation of the Node plugin in Python.
Hi @prasek and @mandiwise, thank you so much for reaching out and providing example implementation! ❤️
I'll bring this up on our side next week so we can discuss where we want to go with that.
@rafalp , looks like this might be the last bit to make ariadne support Federation V2 fully... the sample implementation looks ok, should we test it against the performance benchmarks?
Closing this. We are following in Apollo's steps and deprecating Apollo Tracing in next release. Apollo's recommendation in tracing repo is to use new Apollo Studio format or OpenTelemetry, which we are also adding in next release
We suggest that people looking for formats for describing performance traces consider either the Apollo Studio protobuf-based trace format or a more generic format such as OpenTelemetry.