Add support for Wildcards

[ollyde]

We need to sync our models from server to client. So also need to convert them from JSON exactly. With GraphQL this is becoming very painful.

Here's what we have to do for the hundreds of models in the project.

Then for each query we need to remember to add these fields otherwise it breaks.

A simple "*" wildcard would solve a lot of issues with GraphQL, the option is already supported on Apollo GraphQL web browser, just one little step to make it feasible.

[rivantsov]

question - when we use * in a query, how deep it is supposed to go, for fields that return objects or lists of objects?

[ollyde]

All objects and properties.

[rivantsov]

but then, there might be circular refs in object types. ParentObj has a list of child objects, and child has a ref to parent. You are in infinite loop

[ollyde]

@rivantsov it's already solved on Apollo with a button :-) There are easy ways to prevent that.

[rivantsov]

can you please explain more? with an example, of query with * , against types with circular refs?

[ollyde]

It's fairly simple what we need, attached a screenshot from a GraphQL explorer. We could write a meta data API but that is just faff. I'm honestly surprised this wasn't supported in GraphQL from day 1, since many folks using it have the same use case as me, specially with TypeScript etc.

[lennyburdette]

It's really important to note that this new UI in Apollo Studio is a convenience for adding all available fields to the operation body. But the operation sent to the server still explicitly references each field (even if they're added recursively).

One critical property of GraphQL is that the client will never receive fields it doesn't explicitly ask for. If GraphQL had a wildcard field selector, and you added a field to the schema, the client would start receiving data it didn't know about when the operation was authored. If that new field is slow, the whole operation will take an unexpected latency hit.

I can certainly sympathize with wanting your authoring experience to be more convenient, but adding a wildcard field selector violates some of the key constraints of the query language so I'd look at solving this problem elsewhere.

[ollyde]

@lennyburdette thanks for the input!

Most of GraphQL projects I've seen are doing exactly what I'm doing because of type safety. Many of my fellow developers complain about the exact same thing "Why can't we simply parse an object via wildcard?"

We're not asking to wildcard from the root, only for "objects". I think it's so close!

I might have to write some scruffy data field fetching API if the GraphQL team can't get the vision here. The next project we'll be going back to Rest if it's not resolved because of these long quires and bugs they introduce.

Another example.

I have a UserModel that is the same on the server and client, very common use case. It should be possible for user {*} to just fetch the fields here; what is the issue?

[BoD]

Could Fragments help a bit?

[ollyde]

@BoD no.

[lennyburdette]

Previous discussion: #127

[ollyde]

@lennyburdette I see it was closed with no answer 🙈 this is such a simple thing that people are requesting.

[michaelstaib]

GraphQL is specifically designed to be explicit. In general, this is not a good feature to have in the query engine since it makes the execution unpredictable. In tooling wildcards can easily be implemented in the way apollo studio or others do it. Think about the implications for clients that use wildcards and get data they will never do anything with.

[ollyde]

@michaelstaib most of the time it's usually a 1:1 relationship to database object vs. request serialization. So the data is already there in nearly all the cases I have seen.

I'll repeat myself here, we're not asking to change GraphQL we just asking for a continence method with control. It's up to the user where they place it, if they place it inside a large root tree, that's on them!

I'm sure saving a few bytes is most cases does not make a difference. I mean loading the profiles here was like 30 large requests worth of data for example. For the additional queries it should be on the user where they use the wildcard.

Right now GraphQL is awful to manage on large projects that have type safety, especially with schema additions or changes. On the +14 projects I'm managing, most of our bugs come from developers missing variables from serialized objects that make GQL requests.

[rivantsov]

I would side with @OllyDixon
His case is legit - I guess the client app loads ALL stuff, and turns it into object graph, and then operates it, shows in UI pages. The data is preloaded, it is I guess more efficient to load all and show parts in different areas, rather than run multiple queries on the fly to ask for slightly different things.
The queries I guess are stored in separate files and part of codebase, so you have to modify them whenever you change the object model. We should not say 'it's a bad practice to query all' - it depends.
Just like with SQL, there's * wildcard. Yes, it is considered a bad practice to use it in production queries, but there are cases when this is the least of 2 or more evils. And by the way, it is very helpful in manual querying, even when tools like SMS can generate the list for you, but it is not always usable (with multiple tables and joins).
Basically, if somebody willingly (!) wants to do something potentially (!) inefficient, we (GraphQL folks) should not be like 'oh this is stupid, we forbid it'. Programmers are not idiots, not all of them, they know what they are doing most of the time, we should trust them.
Edit: the question still remains about object/list fields; I guess they should NOT be included. I guess if you add a child list of objects, it is a big model change, so it's worth fixing queries manuall