Object types and input types in NestJS - Step-by-Step Execution

Concept Flow - Object types and input types

Define ObjectType class

↓

Define InputType class

↓

Use ObjectType for output

↓

Use InputType for input validation

↓

Resolver methods use InputType as args

↓

Resolver methods return ObjectType instances

This flow shows how NestJS GraphQL ObjectType and InputType classes are defined and used in resolvers for output and input respectively.

Execution Sample

NestJS

import { ObjectType, Field, InputType } from '@nestjs/graphql';

@ObjectType()
class User {
  @Field()
  name: string;
}

@InputType()
class CreateUserInput {
  @Field()
  name: string;
}

Defines a User object type for output and a CreateUserInput input type for input validation.

Execution Table

Step	Action	Class Created	Decorator Used	Purpose
1	Define User class	User	@ObjectType	Output type for GraphQL schema
2	Add name field to User	User	@Field	Expose name in GraphQL output
3	Define CreateUserInput class	CreateUserInput	@InputType	Input type for GraphQL schema
4	Add name field to CreateUserInput	CreateUserInput	@Field	Expose name in GraphQL input
5	Use CreateUserInput in resolver argument	N/A	N/A	Validate input data
6	Return User instance from resolver	N/A	N/A	Send output data
7	Exit	N/A	N/A	All types defined and used correctly

💡 All object and input types are defined and used properly in resolver methods.

Variable Tracker

Variable	Start	After Step 1	After Step 3	Final
User class	undefined	Defined with @ObjectType	Defined	Defined with @ObjectType and @Field
CreateUserInput class	undefined	undefined	Defined with @InputType	Defined with @InputType and @Field

Key Moments - 2 Insights

Why do we use @ObjectType for User but @InputType for CreateUserInput?

Because @ObjectType marks classes used for output in GraphQL responses, while @InputType marks classes used for input validation in GraphQL queries or mutations, as shown in steps 1 and 3 of the execution_table.

Can we use the same class for both input and output?

No, NestJS recommends separate classes for input and output to clearly separate validation and response shapes, as seen by separate User and CreateUserInput classes in steps 1 and 3.

Visual Quiz - 3 Questions

Look at the execution table, which decorator is used to define the output type class?

A @InputType

B @ObjectType

C @Field

D @Resolver

💡 Hint

Check Step 1 in the execution_table where User class is defined.

At which step is the input type class created?

A Step 1

B Step 5

C Step 3

D Step 6

💡 Hint

Look at the execution_table row describing CreateUserInput class creation.

If we add a new field to CreateUserInput, which decorator must we use?

A @Field

B @InputType

C @ObjectType

D @Resolver

💡 Hint

Fields inside both ObjectType and InputType classes use @Field decorator as shown in steps 2 and 4.

Concept Snapshot

NestJS GraphQL uses @ObjectType to define output data shapes.
Use @InputType to define input data shapes for validation.
Fields inside these classes use @Field decorator.
Resolvers accept InputType classes as arguments and return ObjectType instances.
Separate classes keep input and output clear and safe.

Full Transcript

In NestJS GraphQL, we define classes to describe the shape of data sent and received. We use @ObjectType to mark classes that represent output data, like what the server sends back. We use @InputType to mark classes that represent input data, like what the client sends in queries or mutations. Each field inside these classes uses the @Field decorator to expose it in the GraphQL schema. In the example, the User class is an ObjectType with a name field, and CreateUserInput is an InputType with a name field. Resolver methods take CreateUserInput as input and return User instances. This separation helps keep input validation and output clear and organized.