Code-first approach in NestJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output of this NestJS GraphQL code-first resolver?

Consider this NestJS GraphQL resolver using the code-first approach. What will be the GraphQL query response for hello()?

NestJS

import { Resolver, Query } from '@nestjs/graphql';

@Resolver()
export class HelloResolver {
  @Query(() => String)
  hello() {
    return 'Hello, NestJS!';
  }
}

A { "data": { "hello": "Hello, NestJS!" } }

B { "data": { "hello": "hello" } }

C { "data": { "Hello": "Hello, NestJS!" } }

D { "error": "Query not found" }

💡 Hint

Look at the method name and the returned string value.

The resolver defines a query named 'hello' that returns the string 'Hello, NestJS!'. The GraphQL response wraps this in a 'data' object with the query name as the key.

📝 Syntax

intermediate

Which option correctly defines a GraphQL ObjectType with a field in NestJS code-first?

You want to create a GraphQL ObjectType named Cat with a string field name. Which code snippet is correct?

A

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

@ObjectType()
export class Cat {
  name: string;
}

B

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

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

C

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

@ObjectType
export class Cat {
  @Field(String)
  name: string;
}

D

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

@ObjectType()
export class Cat {
  @Field(() => Number)
  name: string;
}

💡 Hint

Remember the decorator syntax and type hints for fields.

Option B correctly uses @ObjectType() and @Field() decorators. The field 'name' is a string and @Field() without arguments defaults to String type.

❓ state_output

advanced

What is the output of this NestJS code-first mutation resolver?

Given this mutation resolver, what will be the GraphQL mutation response when calling incrementCounter twice?

NestJS

import { Resolver, Mutation } from '@nestjs/graphql';

@Resolver()
export class CounterResolver {
  private count = 0;

  @Mutation(() => Number)
  incrementCounter() {
    this.count += 1;
    return this.count;
  }
}

A First call: { "error": "Cannot read property 'count'" }

B First call: { "data": { "incrementCounter": 0 } }, Second call: { "data": { "incrementCounter": 0 } }

C First call: { "data": { "incrementCounter": 1 } }, Second call: { "data": { "incrementCounter": 2 } }

D First call: { "data": { "incrementCounter": 1 } }, Second call: { "data": { "incrementCounter": 1 } }

💡 Hint

Think about the private variable and how it changes with each call.

The private variable 'count' starts at 0 and increments by 1 each time the mutation is called, so the first call returns 1 and the second returns 2.

🔧 Debug

advanced

What error does this NestJS code-first resolver produce?

Examine this resolver code. What error will occur when the GraphQL server starts?

NestJS

import { Resolver, Query } from '@nestjs/graphql';

@Resolver()
export class SampleResolver {
  @Query(() => String)
  greet() {
    return 123;
  }
}

A No error, returns '123' as string

B RuntimeError: Resolver method missing return statement

C SyntaxError: Unexpected number literal

D TypeError: Query 'greet' must return a string, but returned a number

💡 Hint

Look at the return type declared and the actual returned value.

The @Query decorator expects a string return type, but the method returns a number, causing a type mismatch error.

🧠 Conceptual

expert

Why is the code-first approach beneficial in NestJS GraphQL development?

Choose the best explanation for the main advantage of using the code-first approach in NestJS GraphQL.

A It allows defining GraphQL schema using TypeScript classes and decorators, enabling type safety and IDE support.

B It automatically generates REST endpoints without extra configuration.

C It requires writing GraphQL SDL files manually for better control.

D It disables type checking to speed up development.

💡 Hint

Think about how code-first relates to TypeScript and schema generation.

Code-first uses TypeScript classes and decorators to generate GraphQL schema, improving type safety and developer experience.

Practice

1. What does the code-first approach in NestJS GraphQL primarily involve?

easy

A. Manually writing GraphQL schema files before coding

B. Using REST endpoints instead of GraphQL

C. Writing TypeScript classes and decorators to define GraphQL schema

D. Generating code from existing GraphQL schema files

Solution

1. Step 1: Understand code-first approach basics

   The code-first approach means you write your GraphQL types and resolvers directly in TypeScript code using classes and decorators.

2. Step 2: Compare with other approaches

   Unlike schema-first, you do not write schema files manually; instead, the schema is generated automatically from your code.

3. Final Answer:

   Writing TypeScript classes and decorators to define GraphQL schema -> Option C

4. Quick Check:

   Code-first = Define schema in code [OK]

Hint: Code-first means schema comes from your TypeScript classes [OK]

Common Mistakes:

• Confusing code-first with schema-first approach
• Thinking schema files must be manually written
• Assuming REST is involved in code-first GraphQL

2. Which decorator is used in NestJS code-first approach to mark a class as a GraphQL object type?

easy

A. @ObjectType()

B. @Resolver()

C. @Query()

D. @Injectable()

Solution

1. Step 1: Identify decorator for GraphQL object type

   In code-first, @ObjectType() marks a class as a GraphQL object type to generate schema.

2. Step 2: Differentiate from other decorators

   @Resolver() marks resolver classes, @Query() marks query methods, and @Injectable() is for dependency injection, not schema types.

3. Final Answer:

   @ObjectType() -> Option A

4. Quick Check:

   @ObjectType = GraphQL type class [OK]

Hint: Use @ObjectType() for GraphQL types, not @Resolver() [OK]

Common Mistakes:

• Using @Resolver() instead of @ObjectType() for types
• Confusing @Query() with type decorators
• Thinking @Injectable() defines GraphQL schema

3. Given this code-first resolver snippet, what will be the GraphQL query result for hello()?

import { Query, Resolver } from '@nestjs/graphql';

@Resolver()
export class HelloResolver {
  @Query(() => String)
  hello() {
    return 'Hello, NestJS!';
  }
}

medium

A. "Hello, NestJS!"

B. null

C. Error: Missing return type

D. undefined

Solution

1. Step 1: Analyze the resolver method

   The method hello() returns the string 'Hello, NestJS!'. The @Query decorator specifies the return type as String.

2. Step 2: Understand GraphQL query result

   When queried, the hello field returns the string value wrapped in quotes as a valid GraphQL string response.

3. Final Answer:

   "Hello, NestJS!" -> Option A

4. Quick Check:

   hello() returns string 'Hello, NestJS!' [OK]

Hint: Resolver method return matches GraphQL query result [OK]

Common Mistakes:

• Expecting null or undefined instead of returned string
• Thinking missing return type causes runtime error
• Confusing resolver method with schema definition

4. Identify the error in this code-first resolver snippet:

import { Query, Resolver } from '@nestjs/graphql';

@Resolver()
export class SampleResolver {
  @Query()
  sample() {
    return 123;
  }
}

medium

A. Method sample() should be async

B. Missing return type in @Query decorator

C. Resolver class missing @ObjectType decorator

D. Return value 123 is invalid in GraphQL

Solution

1. Step 1: Check @Query decorator usage

   The @Query decorator requires a return type function, e.g., @Query(() => Int) or @Query(() => String).

2. Step 2: Identify missing return type

   Here, @Query() is missing the return type, which causes schema generation errors.

3. Final Answer:

   Missing return type in @Query decorator -> Option B

4. Quick Check:

   @Query needs return type function [OK]

Hint: Always specify return type in @Query(() => Type) [OK]

Common Mistakes:

• Omitting return type in @Query decorator
• Adding @ObjectType to resolver class incorrectly
• Assuming async is mandatory for resolver methods

5. You want to create a GraphQL object type with a field that is optional and nullable using the code-first approach. Which is the correct way to define the field in your class?

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

@ObjectType()
export class User {
  @Field(() => String, { nullable: true })
  nickname?: string;
}

What does this code do?

hard

A. Ignores the nickname field in the generated schema

B. Causes a schema error because optional fields are not allowed

C. Makes nickname required and non-nullable in the schema

D. Defines a User type with an optional nullable nickname field in GraphQL schema

Solution

1. Step 1: Understand @Field decorator options

   The @Field decorator with { nullable: true } marks the field as nullable in GraphQL schema, allowing null values.

2. Step 2: Check TypeScript optional property

   Using ? in nickname?: string means the property is optional in TypeScript, matching nullable in GraphQL.

3. Step 3: Confirm schema generation behavior

   This combination correctly generates a GraphQL field that can be omitted or set to null without errors.

4. Final Answer:

   Defines a User type with an optional nullable nickname field in GraphQL schema -> Option D

5. Quick Check:

   nullable + optional = optional nullable field [OK]

Hint: Use @Field({ nullable: true }) and ? for optional nullable fields [OK]

Common Mistakes:

• Omitting nullable option for optional fields
• Confusing optional in TypeScript with required in GraphQL
• Expecting errors for optional nullable fields