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.

Practice

1. What is the main purpose of using @ObjectType() in NestJS GraphQL?

easy

A. To define the shape of data returned by queries and mutations

B. To define the shape of data clients send to the server

C. To create database entities automatically

D. To handle HTTP request validation

Solution

1. Step 1: Understand the role of @ObjectType()

   This decorator is used to define the structure of data that GraphQL queries and mutations return to clients.

2. Step 2: Differentiate from input types

   @InputType() is used for data clients send, while @ObjectType() is for data sent back to clients.

3. Final Answer:

   To define the shape of data returned by queries and mutations -> Option A

4. Quick Check:

   ObjectType = output data shape [OK]

Hint: ObjectType decorates output data, InputType decorates input data [OK]

Common Mistakes:

• Confusing @ObjectType() with @InputType()
• Thinking @ObjectType() creates database tables
• Assuming @ObjectType() validates HTTP requests

2. Which of the following is the correct way to define an input type in NestJS GraphQL?

easy

A. @ObjectType() class CreateUserInput { name: string; }

B. @InputType() interface CreateUserInput { name: string; }

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

D. @Input() class CreateUserInput { name: string; }

Solution

1. Step 1: Identify correct decorator and syntax

   Input types require the @InputType() decorator and fields must be decorated with @Field() to expose them to GraphQL.

2. Step 2: Check class vs interface usage

   Input types must be classes, not interfaces, to work with decorators in NestJS.

3. Final Answer:

   @InputType() class CreateUserInput { @Field() name: string; } -> Option C

4. Quick Check:

   InputType + @Field + class = correct input type [OK]

Hint: Input types need @InputType() and @Field() on class properties [OK]

Common Mistakes:

• Using @ObjectType() instead of @InputType()
• Using interfaces instead of classes for input types
• Omitting @Field() decorator on fields

3. Given the following code, what will be the GraphQL output type for the user query?

@ObjectType()
class User {
  @Field()
  id: string;

  @Field()
  name: string;
}

@Resolver()
class UserResolver {
  @Query(() => User)
  user() {
    return { id: '1', name: 'Alice' };
  }
}

medium

A. An error because id is not a number

B. A User object with fields id and name

C. A list of User objects

D. Null because no data source is connected

Solution

1. Step 1: Analyze the @ObjectType and @Field decorators

   The User class defines two fields, id and name, both exposed to GraphQL via @Field().

2. Step 2: Check the resolver return and query type

   The user query returns an object matching User shape with id and name strings, matching the GraphQL type.

3. Final Answer:

   A User object with fields id and name -> Option B

4. Quick Check:

   Query returns User object with id and name [OK]

Hint: Return object matches @ObjectType class shape for query output [OK]

Common Mistakes:

• Expecting type errors for string id when GraphQL expects string
• Assuming query returns a list without @Query(() => [User])
• Thinking null is returned without data source

4. Identify the error in this input type definition:

@InputType()
class UpdateUserInput {
  name: string;
  @Field()
  age: number;
}

medium

A. Missing @Field() decorator on the 'name' property

B. Cannot use number type in input types

C. Class must be decorated with @ObjectType() instead

D. Input types cannot have more than one property

Solution

1. Step 1: Check decorators on class properties

   In GraphQL input types, each field must have the @Field() decorator to be exposed.

2. Step 2: Identify missing decorator

   The 'name' property lacks the @Field() decorator, so it won't be part of the GraphQL input type.

3. Final Answer:

   Missing @Field() decorator on the 'name' property -> Option A

4. Quick Check:

   All input fields need @Field() [OK]

Hint: Every input field needs @Field() decorator [OK]

Common Mistakes:

• Forgetting @Field() on some properties
• Confusing @InputType() with @ObjectType()
• Thinking number types are invalid in input types

5. You want to create a mutation to update a user's profile with optional fields. Which approach correctly defines the input type to allow optional fields in NestJS GraphQL?

@InputType()
class UpdateUserInput {
  @Field({ nullable: true })
  name?: string;

  @Field({ nullable: true })
  age?: number;
}

hard

A. Use @ObjectType() instead of @InputType() for mutations

B. Remove '?' and set default values instead of nullable

C. Make all fields required and handle optional logic in resolver

D. Use @Field({ nullable: true }) and optional properties with '?' to allow partial updates

Solution

1. Step 1: Understand optional fields in GraphQL input types

   To allow optional fields, use { nullable: true } in @Field() and mark properties optional with '?'.

2. Step 2: Confirm correct decorator usage

   Use @InputType() for input data in mutations, not @ObjectType().

3. Final Answer:

   Use @Field({ nullable: true }) and optional properties with '?' to allow partial updates -> Option D

4. Quick Check:

   Nullable fields + optional properties = optional input fields [OK]

Hint: Use nullable:true and '?' for optional input fields [OK]

Common Mistakes:

• Using @ObjectType() for input types
• Not marking fields nullable for optional inputs
• Making all fields required and complicating resolver logic