A good schema is client-driven, nullable-by-default at the edges, and evolvable without versions. It models the domain in terms clients actually use, not your database tables.
Make a field non-null (!) only when you can always return it. Over-using ! is a trap: if a non-null field errors, it nulls its whole parent object, turning a small failure into a large blank. Prefer nullable for anything that depends on a downstream service.
type User {
id: ID! # truly always present
email: String! # required in your DB -> safe as non-null
avatarUrl: String # comes from an external service -> nullable, so its failure is isolated
}
isPublished).input type and return a payload type — you can add fields later without breaking the signature.input CreatePostInput { title: String!, body: String! }
type CreatePostPayload { post: Post!, errors: [UserError!]! } # room to grow
type Mutation { createPost(input: CreatePostInput!): CreatePostPayload! }
GraphQL avoids /v2 URLs. You evolve additively: add fields freely, and retire old ones with @deprecated while clients migrate.
type User {
fullName: String!
name: String! @deprecated(reason: "Use fullName") # keep serving until clients move off
}
Removing or renaming a field is the only true breaking change, so design so you rarely need to. Also avoid leaking DB shape (expose fullName, not first_name/last_name if clients want one field).
These choices are what separate a schema that lasts years from one clients fight against. Interviewers use this to gauge API design maturity — especially the nullability/error trade-off and the additive-evolution mindset, which are unique to GraphQL.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate