Rafał Pitoń

Construction option (like we are already doing with `args_filter`) is the way to go here IMHO. This option should default to `should_trace`.

Yeah, we should drop `trace_default_resolver` at same time, but it would be good to have both at same time for deprecation period. For now we could have both options but...

Looks like @tomchristie has started work on the pub sub library: [Broadcaster](https://github.com/encode/broadcaster) It looks promising, and would potentially allow us to limit our implementation to just abstraction layer for resolvers...

Hi! Correct GraphQL middleware needs to be either an callable or an object with method named `resolve`. Your function is valid middleware, but your object is not. Here is example...

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...

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...

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...

Can you explain what you mean by query whitelisting or how this compares to query persistence that Apollo documents on their docs?

I don't think this is the case. [Docs](https://www.apollographql.com/docs/apollo-server/performance/apq/) describe this as caching mechanism for query strings where client sends hash generated from query it intents to run and if server...

It doesn't. To be honest such requirement sounds like you would want to implement regular restful API instead of GraphQL which's primary selling point is yielding control on what data...