Code-first approach in NestJS - Step-by-Step Execution

Concept Flow - Code-first approach

Define TypeScript classes

↓

Decorate classes with GraphQL decorators

↓

NestJS reads classes

↓

Generate GraphQL schema from classes

↓

Run GraphQL server with generated schema

You write TypeScript classes with decorators, NestJS reads them to create the GraphQL schema automatically, then runs the server.

Execution Sample

NestJS

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

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

  @Field()
  title: string;
}

Defines a Recipe GraphQL type with id and title fields using decorators.

Execution Table

Step	Action	Input	Output/Effect
1	Define class Recipe	class Recipe { id, title }	TypeScript class created
2	Add @ObjectType decorator	Decorate Recipe	Marks Recipe as GraphQL ObjectType
3	Add @Field decorators	Decorate id and title	Marks fields for GraphQL schema
4	NestJS reads classes	Recipe class with decorators	Generates GraphQL schema type Recipe { id: Int, title: String }
5	Start GraphQL server	Schema generated	Server runs with Recipe type available
6	Client queries Recipe	Query for Recipe	Server returns data matching Recipe type
7	End	No more actions	Execution stops

💡 All classes processed and schema generated; server running with schema.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Recipe class	Defined with id, title	Marked as ObjectType	Fields marked with @Field	Schema type Recipe generated	Used by GraphQL server

Key Moments - 3 Insights

Why do we use decorators like @ObjectType and @Field?

Decorators tell NestJS which classes and properties to include in the GraphQL schema, as shown in steps 2 and 3 of the execution_table.

How does NestJS create the GraphQL schema from code?

NestJS reads the decorated classes at runtime (step 4) and generates the schema automatically without writing schema files.

What happens if a class property lacks @Field decorator?

That property is ignored in the GraphQL schema, so it won't be queryable, as implied between steps 3 and 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output after step 4?

A TypeScript class created

B GraphQL schema type Recipe generated

C Server starts running

D Client queries Recipe

💡 Hint

Check the Output/Effect column for step 4 in the execution_table.

At which step does NestJS read the decorated classes to generate the schema?

A Step 2

B Step 6

C Step 4

D Step 1

💡 Hint

Look for the step mentioning NestJS reading classes in the execution_table.

If you remove @Field decorator from a property, what changes in the execution?

A The property is ignored in the generated schema

B The property is included in the schema anyway

C NestJS throws an error at step 4

D The server fails to start

💡 Hint

Refer to the key_moments explanation about missing @Field decorators.

Concept Snapshot

Code-first approach in NestJS:
- Write TypeScript classes
- Use @ObjectType on classes
- Use @Field on properties
- NestJS auto-generates GraphQL schema
- Run server with generated schema
- No separate schema files needed

Full Transcript

In the code-first approach with NestJS, you start by defining TypeScript classes representing your GraphQL types. You decorate these classes with @ObjectType and their properties with @Field to mark them for inclusion in the GraphQL schema. NestJS reads these decorated classes at runtime and automatically generates the GraphQL schema from them. This means you do not have to write schema files manually. Once the schema is generated, the GraphQL server runs and can respond to client queries based on the defined types. Properties without the @Field decorator are ignored in the schema and won't be queryable. This approach keeps your schema and code in sync and simplifies development.

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