Allow interfaces with no fields, unions with no members

[benjie]

Follow up to:

• Allow empty object types #1228

This is again to help subschemas remain valid. Empty unions is fine (we already allow interfaces with no implementations, which is kind of the mirror), but empty interfaces makes it so people may want to use interfaces where unions should currently be used... Relevant:

• Proposal: remove union types and allow interfaces to have no fields #236

Incidentally I'm okay with deprecating unions... And adding @oneOf output types instead.

[benjie]

Pulled from this great comment (emphasis mine):

A Union is a way to say "I may return one of a few things at this location" - it should be defined locally to the field. For example, a Video type doesn't need to describe that it might appear alongside Photo for some specific fields, though a specific fields needs to describe that it might return Video | Photo.

An Interface is a way to say "I conform to this contract" - it should be defined locally to the thing which conforms, the Object type. For example, a User type should be able to say that it fulfills the contract of Profile such that any type current known or unknown can be used knowing that it fulfills the contract.

This also drives the requirement that Interfaces must define at least one field - otherwise the Interface would not actually describe a contract to be fulfilled. This concept of contract-less interfaces is often called "marker interfaces" and in my opinion (hopefully not an uncommon opinion) are a bad practice borrowed from limited object-oriented languages.
-- @leebyron

---

Whilst I agree with the above, I also think that the GraphQL spec generally avoids dictating best practices and instead focuses on compatibility. I think "don't use marker interfaces" is a best practice that people should generally adhere to, and I think allowing empty interfaces does cause confusion of interface vs union as raised by Caleb, but I think this problem lives in the space of "best practices" rather than "hard requirements" and there are benefits to allowing for empty interfaces - both in terms of future expansion and prototyping (these two things are both "Searchable", but I don't know what that means yet... but when I do it will be an interface contract rather than a union) and in terms of subschema extractions (both of these implement the Searchable interface... [not included]).

I think it warrants debate.