Repository navigation
DSL: Compose query with all nested fields included #316
Description
Activity
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 modulemakes 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.
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.fieldsto somehow select each field and any children they might parent. But I find it confusing as some objects containsof_typeattribute 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_allmethod, 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.Reacted by amard33pAlso 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)
Reacted by iwconfigOkay, I see! Yes, a
select_allmethod 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! 👍
I would greatly appreciate this
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.fieldsto somehow select each field and any children they might parent. But I find it confusing as some objects containsof_typeattribute 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.