Query all fields of a type in a simple expression [wildcard]

[AhmadAudeh]

Let us say this is the type :

type Human {
  id: String
  name: String
  homePlanet: String
}

Then to query all the fields the query is :

query HumanNameQuery {
   Human {
     id
     name
     homeplanet
    }
 }

Should be something like this exist ??

query HumanNameQuery {
   Human {
     *
   }
 }

[rmosolgo]

I think this was left out of GraphQL on purpose. Although it seems convenient at first, it may actually lead to some maintainability troubles down the road. Consider some possibilities:

• A field is removed.

  Let's say the database changes and Human.homeplanet doesn't exist anymore. Any query Human { * } would execute successfully, but the client may encounter an error because it depends on homeplanet, which is gone now.

  By requiring an explicit list of fields, you get notified right away that a query is invalid -- you don't have to trace the error down through the client or UI.

• A field is added.

  Imagine that Human.friends is added, which returns a list of other Human objects. Does Human { * } include those objects? If so, any client which requests Human { * } but doesn't need friends has caused a lot of waste!

  It's better to request exactly which fields you need so that the server doesn't do any extra work. This also allows backend developers to implement resource-intensive fields without the fear that they would be requested by accident.

For those two reasons, it's better to make the client request fields explicitly!

[dschafer]

Yep, this was indeed deliberately omitted for the reasons @rmosolgo mentioned!

In places where we've needed things like this (a good example might be a Date type where you pretty much always want to fetch year, month, and day), we could create a fragment DateFields on Date { year, month, day } and use that everywhere that we would have used * before.

[AhmadAudeh]

@rmosolgo : thanks for your explanation, it makes sens.
@dschafer : seems a usable solution, I will try that, thanks.

[amunna]

Interesting reasoning to remove the "*". It's nice to explicitly mention the search fields but it wouldn't hurt to have an "wild card" option just to explore the fields. To me this is just limiting the possibilities with search and doesn't make sense to me.

[acjay]

@amunna I agree that it's awkward sometimes to issue a bunch of queries to explore an API, rather than have an easy way to see a sample of all of the data. But this seems to me like an issue that should be solved in clients like GraphiQL. It could automatically expand a * to be all fields that can be called without arguments. Which, by the way, is another wrinkle. GraphQL doesn't currently assign any special meaning to fields with or without arguments, so it's a little arbitrary that introducing a wildcard in the language itself would create that difference.

[MorganConrad]

@rmosolgo Your point#2 (adding a field) is a red herring. If the client cares about performance, they can still be explicit in their fields. If it is just an exploratory client who doesn't care about performance, they could use "*" (were it supported). Exactly how SQL has done it for a long time.

Your point#1 has some validity, but, again, if the client really cared, they could be explicit.

[felipe-costa-bb]

One more to disagree with the absence of the possibility of a wildcard like '*' to retrieve all fields. This feature is very useful if you are exploring an API.

[tomprogers]

I want a wildcard so that I can fetch a dictionary from the server. This is not exploratory, it's a real case that comes up when internationalizing a web application.

I don't know the names of the fields, so this is not solvable using fragments.. Converting the structure to an array of key:value on the server and then back into a dictionary on the client is painful when using apollo tooling, and also makes it much clearer that I'm just working around arbitrary shortcomings of GQL semantics.

query {
  user {
    firstname
    lastname
    preferredLanguage
  }
  
  languages {
    code
    label
  }
  
  strings {
    * // I want strings to be a dictionary of key:value pairs
  }
}

[juancampa]

@tomprogers for those cases you might want to model your strings field as a list of key-value pairs

[PSAustin]

We need to return some very deep, fully hydrated, object graphs. Without this feature that task is very laborious. This could even be a deal breaker for our current project where we were planning to use GraphQL.

[stubailo]

I think this is a duplicate of: #101

The ideal solution here IMO is to introduce a way to return objects, rather than make all objects able to be queried without specifying fields.

[jlouis]

GraphQL currently has the property that the client is explicit in everything it queries. This suggestion would mean we lose this property. Thus, it has to be done with a lot of care: clients using * will eventually open themselves up to getting lots of data they didn't ask for. Also, the server has no way of knowing which fields might be good candidates for deprecation, if the * query is used.

You can always define scalar JSON and just return a blob of JSON in place of a query. You cannot query inside the structure, but it can be arbitrary, deeply nested objects returned from it.

Currently, the best bet is to model it with a parameter to the query:

query Q($locale : LocaleCode) {
    user(login: "foo") {
        givenName(locale: $locale)
        familyName(locale: $locale)
        fullName(locale: $locale)
    }
}

Personally, I think what is needed is some kind of "implicit parameters", so you can define an implicit binding over a Selection Set. That means, for every subquery, you have access to the implicit parameter, if it has not been overridden. In turn, you can set a locale high up the query and then have everything under in scope pick up the implicit param naturally.

This is akin to digging out a Accept-Language header from the HTTP query and stuffing it into the context of the GraphQL execution, using it as a default value.

As I've said elsewhere: GraphQL is a programming language. You send small programs to the server for it to interpret, and that language could as well contain a let-bind construct of some kind.

[acjay]

@jlouis

As I've said elsewhere: GraphQL is a programming language. You send small programs to the server for it to interpret, and that language could as well contain a let-bind construct of some kind.

^ This.

I wrote about this in detail: http://artsy.github.io/blog/2018/05/08/is-graphql-the-future/