Accept requests where `query` is a parsed AST representation

[terion-name]

Hello.

When using apollo or weaver graphql tools (as proxies and gateways), they are parsing input graphql and sending already parsed request. This works ok with node-js or scala servers, but with php server (this one) it breaks with GraphQL query body is expected to be string, but got array at /app/vendor/webonyx/graphql-php/src/Utils/Utils.php:231.
Why this queries are not supported (while reference implementation supports it) and is there a way to make it work? In other words, is there a way to map this structure to DocumentNode?

Example request body:

{
  "query": {
    "kind": "Document",
    "definitions": [
      {
        "kind": "OperationDefinition",
        "operation": "query",
        "variableDefinitions": [],
        "selectionSet": {
          "kind": "SelectionSet",
          "selections": [
            {
              "kind": "Field",
              "name": {
                "kind": "Name",
                "value": "municipalityByDomain",
                "loc": {
                  "start": 28,
                  "end": 48
                }
              },
              "arguments": [
                {
                  "kind": "Argument",
                  "name": {
                    "kind": "Name",
                    "value": "domain",
                    "loc": {
                      "start": 49,
                      "end": 55
                    }
                  },
                  "value": {
                    "kind": "StringValue",
                    "value": "foo",
                    "block": false,
                    "loc": {
                      "start": 57,
                      "end": 62
                    }
                  },
                  "loc": {
                    "start": 49,
                    "end": 62
                  }
                }
              ],
              "directives": [],
              "selectionSet": {
                "kind": "SelectionSet",
                "selections": [
                  {
                    "kind": "Field",
                    "name": {
                      "kind": "Name",
                      "value": "id",
                      "loc": {
                        "start": 72,
                        "end": 74
                      }
                    },
                    "arguments": [],
                    "directives": [],
                    "loc": {
                      "start": 72,
                      "end": 74
                    }
                  }
                ]
              },
              "loc": {
                "start": 28,
                "end": 80
              }
            }
          ]
        }
      }
    ]
  },
  "variables": {},
  "context": {
    "graphqlContext": {}
  }
}

[terion-name]

For now I've handled it like this, but it more seems like a hack and I'm not sure, that it will work corretly in all cases:

protected function convertGraphQL($input)
    {
        if (is_array($input)) {
            foreach ($input as $k => $v) {
                $input[$k] = $this->convertGraphQL($v);
            }
            if (isset($input['kind'])) {
                $class = "\GraphQL\Language\AST\\" . $input['kind'] . "Node";
                if (isset($input['loc'])) {
                    $input['loc'] = Location::create($input['loc']['start'], $input['loc']['end']);
                }
                return @ new $class($input);
            } else {
                return new NodeList($input);
            }
        }
        return $input;
    }

[vladar]

You can try this instead for now:

use GraphQL\Utils\AST;
// ...
if (is_array($input)) {
    return AST::fromArray($input);
}

But we should implement it in the core lib eventually. PR is welcome!

[terion-name]

@vladar thank you, more solid than my manual attempt)

[spawnia]

As discussed in graphql/graphql-over-http#176 (comment), at least Apollo Server does not actually support this. Also, there are some problems with this approach noted in graphql/graphql-over-http#176 (comment).

I am closing this issue for now, but am open to reviving the discussion when concrete examples of this actually running in the wild come up - as well as a solid plan to make it bulletproof.