As per GraphQL spec:
GraphQL Unions represent an object that could be one of a list of GraphQL Object types, but provides for no guaranteed fields between those types.
Means, one can’t assume anything about the fields in member types of a union. If there are common fields in two types, then you should be using interfaces in your schema design to represent that abstraction.
Just for counter-example, I can add one more type to the union Bar like this, which doesn’t have a field foo:
type Foo {
m: [Bar!]!
}
union Bar = Blub | Blabla | MyType
type MyType {
myField: String
}
type Blub {
foo: Foo!
}
type Blabla {
foo: Foo!
}
The schema is still valid GraphQL, but now you can’t really apply @hasInverse because there is no field named foo in type MyType.
So, @hasInverse doesn’t make semantic sense with unions.