Union types in GraphQL

[michaelcompton]

@abhimanyusinghgaur

Mutation operations

NOTE : These won’t be supported initially. They can be supported later if a need is felt for them. Just writing them out here, so that we know this is possible.

The auto-generated CRUD API should not have any add mutations for the union type, it should only have update and delete mutations.

I don’t even know if this is possible - doesn’t really look sensible to me. How could I even use

input UpdateHomeMemberInput {
	updateDogInput: [UpdateDogInput!]
	updateParrotInput: [UpdateParrotInput!]
}

What would an update with a filter and this data payload mean? If it means match all the things that match the filter and if they are a dog, use the dog update, but if they are a parrot, use the parrot update … then that’s just a complicated way of saying what you can already say in a single mutation request with updateDog and updateParrot.

@abhimanyusinghgaur

			homeMemberTypes: [dog, parrot] # means we don't want to query humans
			dogFilter: {
				# means in Dogs, we only want to query "German Shepherd" breed
				breed: { allofterms: "German Shepherd"}
			}
			# not specifying any filter for parrots means we want to query all parrots

At the moment queryDog with no args means query all dogs (unfiltered) but this way of doing it is the opposite queryHomeMember with no args would mean query nothing. I think this should be the other way around. Maybe even not: { dogFilter: null } would mean no dogs can match. - pretty sure the semantics at the moment is that queryDog(filter: null) is interpreted as the filter is null, so everything matches.

This brings me to another thought - if there is no addHomeMember mutation, how can I query for HomeMembers ? It looks like in the way it’s presented that the union types only make sense as the types of fields … which means that the only way access them should be by following an edge inside a type to a union. So the query type on it’s own doesn’t make sense to me - seems to only make sense as a filter on the fields inside a type.

Also doesn’t make semantic sense here - for example in your schema everything that’s a dog, or parrot becomes an instance of type HomeMember, but I don’t think that’s the intention of unions. I think the intention is that a particular parrot or dog might be the member of a particular home because it’s linked through the members field of a particular home.

Feels like the ± translations should be pretty fine. The hard part here is going to be auth. I don’t think it’s right to have no answer to auth at all - we wouldn’t want to paint ourselves into a corner where auth couldn’t be applied or wasn’t safe. I think we should consider what the implications and possible solutions are, even if we don’t deliver it in a first version.