Questions
9 of 10
Discuss Union types.
Difficulty: 6/10
union types, schema evolution, resolver design
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. They also differ from interfaces in that Object types declare what interfaces they implement, but are not aware of what unions contain them.
With interfaces and objects, only those fields defined on the type can be queried directly; to query other fields on an interface, typed fragments must be used. This is the same as for unions, but unions do not define any fields, so no fields may be queried on this type without the use of type refining fragments or inline fragments
Scenario Questions
0-2 years experience
- 1We need to add a new search result type that can be either a Book or an Author. How would you define a GraphQL union for this and what does the client need to do to differentiate the types?
- 2If a client queries a union field and the server returns an object that doesn't match any member type, what will happen and how would you fix it?
2-5 years experience
- 1During a recent feature rollout, some clients started receiving null for a union field that previously returned data. Walk me through how you'd debug the resolver and schema to find the cause.
- 2When you need to add a new type to an existing union that's used across many services, what trade‑offs do you consider, and how would you version the schema to avoid breaking existing clients?
5-8 years experience
- 1Our product aggregates data from three micro‑services, each exposing a different type in a shared union. How would you design the resolver layer to efficiently fetch and stitch these types while keeping latency low?
- 2Explain how you would handle pagination and caching for a union field that can return heterogeneous objects, and what pitfalls to watch out for at scale.
8+ years experience
- 1We are planning a migration from a monolithic GraphQL server to a federated architecture, and several unions are used across domain boundaries. What architectural decisions would you make to ensure unions remain compatible and maintainable across teams?
- 2How would you establish a long‑term strategy for evolving union types in a large organization, balancing backward compatibility, client SDK generation, and schema governance?
Follow-up Questions
- Can you show the SDL syntax for the union you just described?
- What are the trade‑offs between using an interface versus a union in this scenario?
- How would you write a test to verify the resolver returns the correct __typename?