Christian Legnitto

Do we want to reserve the trait for future extensibility? If we remove the requirement and later need it for implementation specifics, it would be a breaking change.

Interesting. We use https://github.com/graphql-rust/graphql-parser 's AST printing, sounds like a bug there possibly?

Minor nit, but we probably want to match the integration crate name with the integration file name with the flag name. That is, `serde_json` everywhere instead of `json`.

This is great work, thank you! ❤️

See https://github.com/graphql/graphql-spec/pull/584 for the RFC to support this I believe. I haven't seen where that RFC ended up though.

Also https://github.com/graphql/graphql-spec/issues/627.

I would love to handle this in a generic way. The core is explicitly json agnostic but the webserver integration crates were hardcoded to json as that is what 99%...

Yep, we should totally do this.

Not sure I understand this request. This is just so you can use the derive without breaking out into the `juniper::object` proc macro? What is the advantage over doing something...

This would probably get rid of duplicate code between `execute` and `execute_sync` too.