GraphQL provides schema-level validation, but schema validation is not enough for most production applications.

Consider:

input RegisterInput {
  email: String!
  age: Int!
  password: String!
}

GraphQL can validate that:

• email is supplied as a string.
• age is supplied as an integer.
• password is supplied as a string.
• Required fields are present.

But GraphQL does not automatically know that:

• The email must have a valid email format.
• The user must be at least 18.
• The password must contain a particular combination of characters.
• The email must be unique in the database.

Those are business or application validation rules.

A production resolver or service layer should therefore perform additional validation.

Conceptually:

GraphQL validation
        ↓
Type-safe input
        ↓
Application validation
        ↓
Authorization
        ↓
Business logic
        ↓
Persistence

Keeping business validation out of the schema where possible prevents the schema from becoming an inappropriate replacement for the domain layer.

At the same time, the schema should still communicate important constraints through types. For example, if a value is always required, representing it as String! is better than leaving it nullable and relying entirely on runtime validation.