GraphQLUnionType as input type

[xpepermint]

I would need GraphQLUnionType to work also as an input type. I need to pass a list of different conditions to the server.

Example (start processing products where (A or B and C) - order is important):

mutation RootMutation {
   startProcessing({
      kind: "product",
      filter: [
         {kind: "A",  period: "1 min"}, // type1
         {operand: "or", kind: "B",  tag: "smart"}, // type2
         {operand: "and", kind: "C",  tag: "small"} // type2
      ]
   }){kind}
}

[leebyron]

Interesting - I'd like @dschafer to see this as well.

I know at FB we've stayed away from this sort of input flexibility as it leads to more complex and easy to mess up server side implementations and in some cases can lead to ambiguities where it's not possible to determine which type in the input you meant, but I definitely understand why this could be valuable.

[xpepermint]

Great!

[dschafer]

Yeah, we've definitely seen cases where this would be useful. We've represented these as input objects that basically simulate tagged unions, and have helper methods internally that validate the inputs (that only one field on the tagged union is set).

@lolopinto has thought a lot about this, I'd like to get his thoughts, but this seems like an idea we should pursue. My initial thought is that a GraphQLUnionType that only contains input types would be considered a valid input type?

[xpepermint]

Btw, having the interfaces concept for GraphQLInputObjectType would be great.

[sorenbs]

We have a use case for this as well. We are building a generic CRUD GraphQL api. one of the operations we are supporting is linking two objects like this:

mutation {
  createUser(name: "carl", cityId: "cityId")
}

We would like to support creating the city inline like this:

mutation {
  createUser(name: "carl", city: {name: "Berlin", knownFor: "cool GraphQL people"})
}

Ideally we would like the type of the city input field to be {id!} || {name!, knownFor}. It seems like input Union Types would support this.

[fson]

I've ran into another use case where unions for input types would be useful.

I'm adding a GraphQL mutation in Reindex for authenticating with a social access token (Facebook Login, Twitter etc). The problem is that different providers require different input parameters:

• OAuth 2 providers like FB and GitHub only require an access token.
• OAuth 1 providers, e.g. Twitter takes an access token, secret and user ID.

These difference mean that without union input types, I would have to create separate mutation for each login provider we support and plan to support in the future. This also wouldn't be very good for code reuse on the client-side, e.g. each provider would require a separate Relay mutation.

@leebyron mentioned union types can lead to ambiguities where it's not possible to determine the type. This gave me an idea: what if GraphQL input types would only support disjoint unions (like those supported in Flow)? This would avoid the potential ambiguities, yet allow expressing the input type for cases like I've described above like this:

union LoginInput = FacebookLoginInput | GithubLoginInput | TwitterLoginInput

input FacebookLoginInput = {
  provider: "facebook"
  accessToken: String
}

input GithubLoginInput = {
  provider: "github"
  accessToken: String
}

input TwitterLoginInput = {
  provider: "twitter"
  accessToken: String
  accessTokenSecret: String
  userID: String
}

It's possible to emulate these with nested input objects and runtime checks, as @dschafer described above, but being able to express them in the type system would enable better type checking and make the API more self-documenting than relying on out-of-band information ("always set only one of these fields").

[sorenbs]

@leebyron Any chance this would be considered in the future?

[leebyron]

Yes, I still think this idea is interesting, though the tricky part is definitely coming up with the right semantics and validation for disambiguating within input unions.

e.g.:

union MyUnion = Person | Place | Thing

input Person {
  name: String
  birthdate: Int
}

input Place {
  name: String
  lon: Float
  lat: Float
}

input Thing {
  name: String
  weight: Float
}

Should this be legal? If so, then what should GraphQL do with { name: "Santiago" }? Should that be legal? If so, what type does it use for coercion?

[leebyron]

Also, one of the design principles for GraphQL is to bias towards simplicity. Any time an idea can be expressed using less concepts we should use less concepts, even if that means being slightly more awkward.

Biasing towards simplicity lowers the barrier to entry for other implementers or adopters of GraphQL, the value of which should not be underestimated.

For example, @fson's example above is perhaps a fine example of how input unions could be useful, however I could also represent the same thing with:

input LoginInput {
  provider: String! # or maybe an enum
  accessToken: String
  accessTokenSecret: String
  userID: String
}

Does that make it a bit harder to describe that userID is only necessary when provider is "twitter"? Yes, I think so. But is it simpler? Yes, definitely! One type instead of four and one fewer concept.

[leebyron]

Part of the reason why this issue has not been a priority is there still is not a set of truly compelling examples where input unions would unlock the ability for GraphQL to express APIs that it cannot yet express today.

It's easy to come up with example use cases for any given idea, but as long as each of those examples can be reasonably represented with the existing features then they're not that compelling an argument for adding complexity.