graphql-python / gql

A GraphQL client in Python
https://gql.readthedocs.io
MIT License
1.55k stars 179 forks source link

DSL: Compose query with all nested fields included #316

Open iwconfig opened 2 years ago

iwconfig commented 2 years ago

Hello!

I'm building my query dynamically. I want to select all the nested sub fields (children, grand children etc). Is there a way to accomplish this with gql?

I'm not very fluent in graphql but I do know it's possible to build infinite nested queries, so is it even possible/easy to prevent that from happening?

I've experimented with looping through ds.Content._type.fields to somehow select each field and any children they might parent. But I find it confusing as some objects contains of_type attribute while others do not and I don't know why that is.

Might I be better off doing an introspection with

{
  __schema {
    types {
      name
      fields {
        name
      }
    }
  }
}

and determine any children by simply parsing the json data? Seems redundant.

iwconfig commented 2 years ago

After sleeping on this I realize this wish for "all the data in one simple shot" goes quite against the principles of GraphQL with it's declarative nature. Especially considering this technology emerged from the limitations of REST. So a possible solution to this might not be that easy, but the DSL module makes me think it might not be that hard.

Although I will certainly take advantage of this declarative approach, I would still be very happy if there was a way to sort of get "every bit of information" out of a schema. Sometimes I encounter schemas containing a lot of queries, types and fields with ambiguous documentation, so in order to figure everything out it would help to get all the data I have access to. The actual data.

Writing out every type, field name and every single child manually in such a situation is a horrible task I'd like to avoid.

leszekhanusz commented 2 years ago

I'm building my query dynamically. I want to select all the nested sub fields (children, grand children etc). Is there a way to accomplish this with gql?

Not out of the box, but you can definitely do it yourself by analyzing all the possible children fields of each field in the schema.

I'm not very fluent in graphql but I do know it's possible to build infinite nested queries, so is it even possible/easy to prevent that from happening?

The only way to prevent it would be to provide a limit of nesting levels but you need to understand that even in that case, the quantity of results might completely explode very fast even with few levels. Imagine something like this for example:

users {
  name
  friends {
    name
    friends {
      name
      friends {
        name
      }
    }
  }
}

I've experimented with looping through ds.Content._type.fields to somehow select each field and any children they might parent. But I find it confusing as some objects contains of_type attribute while others do not and I don't know why that is.

If I recall correctly, it is used for lists and for non-nulls (!), in that case a type is linked to an inner type.

Might I be better off doing an introspection and determine any children by simply parsing the json data? Seems redundant.

Yes, that's redundant as all the introspection data is already present in the schema you have.

Writing out every type, field name and every single child manually in such a situation is a horrible task I'd like to avoid.

I completely understand and we might want to provide a select_all method, which takes a nesting level as argument. In that case, for me the biggest downside is that you cannot provide any arguments to any of the selected fields, but that might still be useful in some cases.

leszekhanusz commented 2 years ago

Also you could take a look at the get_introspection_query_ast method which uses the DSL module to create an introspection query with the number of nested levels of your choice (in that case the fields are known, tough)

iwconfig commented 2 years ago

Okay, I see! Yes, a select_all method would be very useful I think. Even better if the method could at least distinguish those fields that do require arguments and list them for later investigation.

I will explore this further. Thanks for your input, much appreciated! :+1:

phrfpeixoto commented 1 month ago

I would greatly appreciate this