Union input types

[calebmer]

Could we make union types of strictly input types an input type? Often I find places where having a union type as the argument to a GraphQL field could be useful. Especially for complex querying. For example an orderBy field could take a single ordering enum or an array of enums: orderBy: ID or orderBy: [FIRST_NAME, ID] with union input types.

Another example could be complex conditions. So for instance we could have the following (rough) type definition:

input PersonCondition {
  id: IntCondition
  firstName: StringCondition
  lastName: StringCondition
}

union IntCondition = Int | IntOperation | [IntOperation]

input IntOperation {
  operation: IntOperator
  value: Int!
}

enum IntOperator {
  EQUALS
  LESS_THAN
  GREATER_THAN
}

union StringCondition = String | StringOperation | [StringOperation]

input StringOperation {
  operation: StringOperator
  value: String!
}

enum StringOperator {
  EQUALS
  LESS_THAN
  GREATER_THAN
  SEARCH
}

Where here say the literal Int would be the same as an IntOperation with an operator of EQUALS. And the array of StringOperation could be joined together with ands when querying the database.

---

I don’t think union input types are useful for people who are handcrafting their schemas (although it may be), but union input types are incredibly useful for GraphQL as a service type products. That provide the user with a GraphQL schema and then allow that user to perform arbitrary queries against that schema. And here I don’t mean “arbitrary queries” in the sense that GraphQL allows the client to define the exact data it wants from the schema, but rather arbitrary queries to the backend. Whether that backend be a SQL database, NoSQL database, or something proprietary.

[sorenbs]

You are probably aware of graphql/graphql-js#207 already. As you say, this is probably mostly useful for generic backends, but I hope more compelling use cases will emerge so we can convince Lee that the utility outweighs the added complexity.

[ianks]

Continuing from #215

@IvanGoncharovIvan offered a solution that looks to this problem:

filtering: [{ field: "campaign_id", operator: "IN", value: ["1", "2", ...] }]

It looks like this:

filtering: {
  clicks: {
    LESS_THAN: 42 
  },
  campaign_id: {
    IN: ["1", "2"]
  }
}

Advantages of this are much better autocompletion and validation on the client side than when using unions of scalars.

This would work well in many cases, however, in this particular case, you end up having numOperators * numFields combinations. This comes out to be about 1100 combinations a single endpoint. On top of this, the filtering argument can exist on n endpoints. That is a lot work/maintenance. I do not think is a maintainable solution for this specific scenario.

[tgriesser]

Just opened #395 as an RFC to potentially address this need.

[leebyron]

Closing in favor of #395