Naming conventions

GraphQL types use PascalCase (User, BlogPost). Fields use camelCase (firstName, createdAt). Enum values use SCREAMING_SNAKE_CASE (PUBLISHED, DRAFT). Input types are conventionally suffixed with 'Input' (CreateUserInput). These conventions are not enforced by the spec but are widely adopted across the ecosystem.

// GraphQL schema design best practices

// 1. Use non-null by default, nullable for optional fields
type User {
  id: ID!            # always present
  name: String!      # required
  bio: String        # nullable — may not be set
}

// 2. Use connections for pagination (Relay spec)
type Query {
  users(first: Int!, after: String): UserConnection!
}
type UserConnection {
  edges: [UserEdge!]!
  pageInfo: PageInfo!
}
type UserEdge {
  cursor: String!
  node: User!
}

// 3. Use input types for mutations
mutation { createUser(input: CreateUserInput!): User! }

// 4. Use enums instead of strings for fixed sets
enum OrderStatus { PENDING SHIPPED DELIVERED CANCELLED }

Designing for relationships

Unlike REST, GraphQL schemas explicitly model relationships between types. A User type might have a posts: [Post!]! field, and a Post type might have an author: User! field. This bidirectional relationship lets clients query in either direction. Use connection types (edges/nodes pattern) for paginated lists following the Relay specification.

Nullability decisions

Making fields non-null (!) is a contract with your clients — you guarantee the field will always have a value. Be conservative: start with nullable fields and only add ! when you are certain the field will never be null. Non-null fields that return null cause the entire parent object to be nullified, which can cascade up the query tree.