Is your feature request related to a problem? Please describe.
PR #70 (relating to issue #69) adds support for GraphQL by detecting an operation name field in the request. I believe that there are additional nuances to GraphQL we should address before calling our support "complete"

• Reading through Serving over HTTP it appears as though we would be missing GraphQL icons on valid outgoing requests as "operation name" is optional. This was the case when I ran the code against my team's soon-to-be-released app.
• We have the opportunity to parse the "variables" collection to give users a more full-featured summary of the request; perhaps we could tweak the "request" tab to be more GraphQL specific (including operation name, variables and query) in the cases where we detect it's needed.
• Reading through The Anatomy of a GraphQL Query we could probably detect the operation type (query, mutation, or subscription) without too much effort.

Additional context
PR #70 attempts to parse plain text requests to detect a operationName field and if present, the GUI receives the GraphQL icon. It looks like there are several cases where an operationName will be absent, but we would want to include the icon.

• a GET request like http://myapi/graphql?query={me{name}} is valid GraphQL
• the operation name would only appear in a GET when there are multiple operations

  If the query contains several named operations, an operationName query parameter can be used to control which one should be executed

• for a POST

  If the "query" query string parameter is present (as in the GET example above), it should be parsed and handled in the same way as the HTTP GET case.

• also, we should be sensitive to the content type and only use GSON if it is "application/json"

  If the "application/graphql" Content-Type header is present, treat the HTTP POST body contents as the GraphQL query string.

Describe the solution you'd like
GraphQL (like SOAP before it) exposes a single HTTP endpoint, perhaps we could register that with the ChuckerInterceptor and avoid introspecting the request looking for an operation name?

Also, we parse the request with GSON for all outgoing network calls, in-line with the actual network call. Knowing that a particular URL is a non-GraphQL endpoint would allow us to skip this step. Perhaps we could defer this work to the HttpTransactionDatabaseRepository as we will be on a background thread away from the actual network call?

Do you want to develop this feature yourself?
I could easily see several user stories to extend the GraphQL support, each of which would add value and could be independently worked by people. I would be happy to work with you on coming up with several new issues, and would also be glad to work on any of them.