Outstanding questions about GraphQL

[rmosolgo]

1. Mutations. I heard that mutations are just "root calls with side effects". That makes sense. How do you provide inputs to that root call? For example, if you're creating a new account and you need to send over the person's data, how would you pass that? (I vaguely remember a special <input> object with keys and values. Was that plain JSON? Do other calls take JSON inputs?)

2. Aliasing edges. I remember aliasing fields with field as other_name. I've implemented that. Can you also alias connections? If so, what's an example of that?

3. Type system. Seems like the type system + required documentation brought a LOT of stability and discoverability to a GraphQL api. I'm ready to try implementing that, but I want to make sure I understand the system. Here's what I remember:

   • You can inspect an object's type with __type__, for example node(4) { __type__ { name } }
   • __type__ exposes name, description and ... what else? I imagine different objects expose different things.
   • You can query types directly with type(User)

   My remaining questions are:

   • What fields can you get a from a node's __type__?
   • What fields can you get from a connection's __type__?
   • Do fields expose a __type__? (eg node(4) { name { __type__} } or something?)
   • Can you inspect calls that are defined on connections or edges? Do calls expose their arguments & argument types?
   • Can you list root calls? Can you inspect individual root calls?

[leebyron]

1. JSON, correct. We have a concept called query variables:

some_mutation(<data>) { ... }

Where we can send the query string along with a query data JSON object of variable name keys to payload values.

2. Absolutely. Connections are also Objects returned from fields.

me() {
  name as funky_name,
  friends.first(10) as ten_friends {
    edges { ... }
  }
}

3. __type__ exposes the entire type system introspection. A type has a name, but also a list of all it's fields. fields is a list of Field objects which themselves have name and a return type and a list of calls which themselves have name and the type of information they accept, etc, etc, etc. The entire type system is exposed this way.

Can you inspect calls that are defined on connections or edges? Do calls expose their arguments & argument types?

Yep, the entirety of what is query-able is inspectable via the type schema. We build all of our tools for working with GraphQL in GraphQL.

What fields can you get a from a node's type?
What fields can you get from a connection's type?

Nodes and Connections are both Objects. All objects have a __type__ field.

Do fields expose a type? (eg node(4) { name { type} } or something?)

Fields you can think of as an accessor function to get a Value. Object Values all have a __type__ field. Scalar Values (string, number, etc) do not.

Can you list root calls? Can you inspect individual root calls?

Absolutely. There's a special root call called schema() which returns the entire type system including all known root calls and all known types.

[leebyron]

I should also note that this is all prototypal GraphQL. We're working on both syntax and behavior to get to a publicly usable version of GraphQL, so some of these details may change slightly in the open source version we're working towards.

[leebyron]

One thing to clear up here that is a common thread in your questioning: there's no difference between a field that returns an object and a field that returns a connection in GraphQL. A connection is just an interface any object can fulfill which presents a few expected fields like "edges". Obviously the implementation of fulfilling a connection request is the interesting part, but from the type system and query's point of view, there's no special difference between a connection and any other object.

[schrockn-zz]

It's also worth nothing the the schema of the variable into a mutation is verified at runtime and exposed in the type system. You can't just throw arbitrary garbage in there.

[rmosolgo]

💥 thanks guys!

Very interesting about query variables. I guess they're declared alongside they query, like QueryFragments.

Thanks for the clarifications regarding __type__. Sounds like I should just gather everything I can and then worry about massaging it into place when the spec is ready :P It's amazing how much more discoverable that will be.

@leebyron yeah, I hear you about the sameness btw connections and other fields. I have been thinking about them as fundamentally different but I see what you mean that they're really the same.

Thanks again for taking the time!