Object types and input types in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this NestJS GraphQL resolver with object types?

Consider this NestJS GraphQL resolver code snippet. What will be the output when the getUser query is called with id: 1?

NestJS

import { Resolver, Query, Args, ObjectType, Field, Int } from '@nestjs/graphql';

@ObjectType()
class User {
  @Field(type => Int)
  id: number;

  @Field()
  name: string;
}

@Resolver(of => User)
export class UserResolver {
  private users = [{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }];

  @Query(returns => User, { nullable: true })
  getUser(@Args('id', { type: () => Int }) id: number): User | undefined {
    return this.users.find(user => user.id === id);
  }
}

A GraphQL error: Field 'getUser' is missing a resolver

B { "data": { "getUser": { "id": 1, "name": "Alice" } } }

C { "data": { "getUser": null } }

D SyntaxError: Unexpected token in resolver

💡 Hint

Think about how the resolver finds the user by id and returns the matching object.

The resolver searches the users array for a user with id 1 and returns the matching object. The GraphQL query then returns this user data in the response.

📝 Syntax

intermediate

Which option correctly defines an input type for NestJS GraphQL mutation?

You want to create an input type for a mutation to create a new user with name and age. Which option is syntactically correct?

A

@ObjectType()
class CreateUserInput {
  @Field()
  name: string;

  @Field(type => Int)
  age: number;
}

B

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

  @Field(type => Int)
  age: number;
}

C

class CreateUserInput {
  @Field()
  name: string;

  @Field(type => Int)
  age: number;
}

D

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

  @Field(type => Int)
  age: number;
}

💡 Hint

Input types must use the @InputType decorator with parentheses.

Option D correctly uses @InputType() decorator and defines fields with @Field decorators. Option D uses @ObjectType which is for output types. Option D misses parentheses on @InputType. Option D lacks any decorator.

🔧 Debug

advanced

What error does this NestJS GraphQL input type cause?

Given this input type code, what error will occur when running the NestJS app?

NestJS

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

@InputType()
export class UpdateUserInput {
  @Field()
  name: string;

  age: number;
}

A SyntaxError: Unexpected token 'age'

B No error, code runs fine

C Error: Field 'age' is missing @Field decorator

D TypeError: Cannot read property 'name' of undefined

💡 Hint

All fields in input types must have @Field decorator to be exposed in GraphQL schema.

The 'age' field lacks the @Field decorator, so NestJS GraphQL will throw an error indicating this field is missing the decorator.

❓ state_output

advanced

What is the value of the input object in this NestJS mutation resolver?

In this mutation resolver, what is the value of the input parameter when the mutation is called with { "name": "Eve", "age": 30 }?

NestJS

import { Resolver, Mutation, Args, InputType, Field, Int } from '@nestjs/graphql';

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

  @Field(type => Int)
  age: number;
}

@Resolver()
export class UserResolver {
  @Mutation(returns => Boolean)
  async createUser(@Args('input') input: CreateUserInput): Promise<boolean> {
    console.log(input);
    return true;
  }
}

A { name: 'Eve', age: 30 }

B { input: { name: 'Eve', age: 30 } }

C undefined

D Error: Argument 'input' not found

💡 Hint

The @Args decorator extracts the input object directly.

The input parameter receives the object passed to the mutation under the 'input' argument, so it contains { name: 'Eve', age: 30 }.

🧠 Conceptual

expert

Which statement about NestJS GraphQL object and input types is correct?

Select the correct statement about the difference between object types and input types in NestJS GraphQL.

A Object types define the shape of data returned by queries and mutations, while input types define the shape of data accepted as arguments.

B Input types can be used as return types for queries, but object types cannot be used as input arguments.

C Both object types and input types must use the @ObjectType decorator in NestJS GraphQL.

D Input types automatically inherit all fields from object types without extra code.

💡 Hint

Think about the purpose of input types versus object types in GraphQL.

Object types describe the data structure returned by GraphQL operations. Input types describe the data structure accepted as input arguments. They use different decorators (@ObjectType vs @InputType).

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