In GraphQL SDL, what is the difference between an interface type and a union type?

## GraphQL has exactly two abstract output types Most fields in a schema have a concrete type: `phase: TrialPhase!` will always be that enum, `site: Site!` will always be that object type. An **abstract type** says something weaker — the value will be *one of* several object types, and which one is decided while the request executes. GraphQL spells that two ways, interfaces and unions, and they differ in one respect that drives every other difference: **an interface declares fields; a union declares none.** ## The interface: a contract each implementer restates ```graphql interface RegistryRecord { id: ID! registeredOn: String! } type Trial implements RegistryRecord { id: ID! registeredOn: String! phase: TrialPhase! } ``` An interface is a named set of field declarations. It must declare at least one field. An object type opts in with an `implements` clause, and opting in obliges it to declare every one of those fields on itself — there is no inheritance in the SDL text, the declarations are physically repeated. That obligation is checked when the server builds the schema, so a type that quietly omits `registeredOn` produces a build-time schema error, not a surprise at runtime. The payoff is on the client side. Because `id` and `registeredOn` are declared *on the interface*, a field typed `RegistryRecord` can be asked for them directly, whatever concrete type comes back. A registry timeline that shows "what was registered, and when" over trials, sites and protocols is one selection, not three. An object type may implement several interfaces at once (`type Trial implements RegistryRecord & Auditable`), and an interface may have any number of implementers. Since the October 2021 edition of the specification, an interface may itself implement another interface, which lets you express a narrower contract that refines a broader one; older servers may not support that, so check before relying on it. ## The union: a set whose members share nothing ```graphql union SearchResult = Trial | Site | Investigator ``` That is the whole declaration. There is no field list, because the union makes no claim that its members have anything in common — only that this one field may return any of them. Registry search is the archetype: a query box over a clinical-trial registry returns trials, sites and investigators, and those three genuinely share no meaningful field. The rules are short and worth knowing exactly: - Members must be **object types**. An interface, another union, a scalar, an enum or an input object may not be a member. - A union must have at least one member, and a member may not be listed twice. - Members declare nothing. `Trial` has no idea it is in `SearchResult`; the union names it, not the other way round. Because the union declares no fields, there is nothing to select on it directly except the meta-field that reports the concrete type name. Every real field has to be requested per member type. That is the practical cost of a union, and it is the difference an interviewer is usually listening for. ## Membership is declared from opposite ends This is the second-order difference, and it is the one that shows up in a design review. An interface is opted *into* by the implementer, so a part of the schema you have not written yet can add an implementer without anyone touching the interface — the set is open. A union is a closed list, edited in exactly one place, so the set is only as open as the team that owns that one line. Neither is better; they are different governance shapes for "this field may return several things". ## Both are output-only, and neither is the other Interfaces and unions are output types. Neither can appear where an input type is required. A union cannot be implemented, and an interface cannot be a union member — the two mechanisms do not compose in that direction. What they do share is that the concrete type of each returned value has to be worked out by the server during execution, and that clients get at concrete-type fields by narrowing to a specific type; both of those are their own topics, and neither changes the SDL-level distinction here. ## The one-line test Ask whether the alternatives share fields a client should be able to read *without caring which one it got*. If yes, that shared set is an interface, and the interface is worth its cost. If the only thing the alternatives have in common is that this single field may return any of them, it is a union, and inventing an interface to unify them will produce a contract full of fields that are meaningless for half the implementers.