Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DSL: Compose query with all nested fields included #316

Open
iwconfig opened this issue Apr 6, 2022 · 5 comments
Open

DSL: Compose query with all nested fields included #316

iwconfig opened this issue Apr 6, 2022 · 5 comments
Labels
type: feature A new feature

Comments

@iwconfig
Copy link

iwconfig commented Apr 6, 2022

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
Copy link
Author

iwconfig commented Apr 6, 2022

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
Copy link
Collaborator

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 leszekhanusz added the type: feature A new feature label Apr 9, 2022
@leszekhanusz
Copy link
Collaborator

leszekhanusz commented Apr 9, 2022

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
Copy link
Author

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! 👍

@phrfpeixoto
Copy link

I would greatly appreciate this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature A new feature
Projects
None yet
Development

No branches or pull requests

3 participants