webonyx / graphql-php

PHP implementation of the GraphQL specification based on the reference implementation in JavaScript
https://webonyx.github.io/graphql-php
MIT License
4.64k stars 565 forks source link

Include aliases in query plan #1072

Open crissi opened 2 years ago

crissi commented 2 years ago

Running lookAhead with queryplan with this query:

$resolveInfo->lookAhead(['group-implementor-fields'])->queryPlan();
query  {
  caseById(id: 7317) {
    default: schemesCount
    closed: schemesCount(status: CLOSED)
    approved: schemesCount(status: APPROVED)
  }
}

Gives us:

{
  "fields": {
    "schemesCount": {
      "type": "Int",
      "fields": [],
      "args": {
        "status": "APPROVED"
      }
    }
  }
}

I suspect all fields should be included somehow in the result!

spawnia commented 2 years ago

I think the purpose of the query plan is to allow the server to make decisions on how to resolve the query efficiently. Given aliases are given by the client and transparently handled by the execution engine of this library, they do not seem useful to include.

crissi commented 2 years ago

yes, but since each alias can have different arguments like in my example.

Here it just returns the argument of the last schemesCount property.

spawnia commented 2 years ago

Right, that is misleading. args should really be a list with multiple args passed to the different aliases - same with fields actually. Perhaps a better structure would be:

{
  "fields": {
    "schemesCount": {
      "type": "Int",
      "aliases": [
        {
          "fields": [],
          "args": {}
        },
        {
          "fields": [],
          "args": {
            "status": "APPROVED"
          }
        },
        {
          "fields": [],
          "args": {
            "status": "CLOSED"
          }
        },
      ]
    }
  }
}
crissi commented 2 years ago

maybe include the alias name in there for good measure

jeroenschieven commented 1 year ago

We are having the same issue. We use the queryPlan to dynamically build an ElasticSearch query. Some fields have quite some possible arguments, therefore we want to be able to alias those fields.

Unfortunately, the only alternative for now is duplicating these fields.