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

Concept Flow - Schema-first approach

Define GraphQL Schema (SDL)

↓

Generate TypeScript Types

↓

Implement Resolvers Using Types

↓

NestJS GraphQL Module Loads Schema

↓

GraphQL Server Ready to Handle Queries

Start by writing the GraphQL schema, then generate types and implement resolvers, finally load schema in NestJS to serve requests.

Execution Sample

NestJS

const typeDefs = `
  type Query {
    hello: String
  }
`;

const resolvers = {
  Query: { hello: () => 'Hello World!' }
};

Defines a simple GraphQL schema and resolver that returns a greeting string.

Execution Table

Step	Action	Input/Code	Output/Result
1	Define schema	type Query { hello: String }	Schema with Query type and hello field created
2	Generate types	Schema SDL	TypeScript types generated for Query and hello
3	Implement resolver	hello: () => 'Hello World!'	Resolver function ready to return greeting
4	Load schema in NestJS	typeDefs and resolvers	GraphQL module configured with schema and resolvers
5	Server ready	GraphQL server running	Can respond to { hello } query with 'Hello World!'
6	Query executed	{ hello }	"Hello World!" returned

💡 Execution stops after server responds to query with the expected data.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
typeDefs	undefined	Schema SDL string	Schema SDL string	Schema SDL string	Schema SDL string	Schema SDL string
resolvers	undefined	undefined	undefined	Resolver object with hello function	Resolver object	Resolver object
serverStatus	stopped	stopped	stopped	stopped	running	running

Key Moments - 3 Insights

Why do we write the schema first instead of code?

Writing the schema first defines the API contract clearly before coding, as shown in Step 1 of the execution_table.

How do resolvers connect to the schema fields?

Resolvers match schema fields by name and type, like the 'hello' resolver matches the 'hello' field in the Query type (Step 3).

What happens if the schema and resolvers don't match?

The server will error or fail to respond correctly, because NestJS uses the schema to validate queries and expects matching resolvers (Step 4).

Visual Quiz - 3 Questions

Look at the execution_table, what is the output after Step 3?

A Schema with Query type and hello field created

B Resolver function ready to return greeting

C GraphQL module configured with schema and resolvers

D Can respond to { hello } query with 'Hello World!'

💡 Hint

Check the Output/Result column for Step 3 in the execution_table.

At which step does the GraphQL server start running?

A Step 5

B Step 4

C Step 2

D Step 6

💡 Hint

Look for 'server running' status in the Output/Result column.

If the resolver for 'hello' was missing, what would happen at Step 6?

A Server returns 'Hello World!' anyway

B Schema generation fails

C Server returns null or error for { hello } query

D Server crashes immediately

💡 Hint

Refer to the key_moments about schema and resolver matching.

Concept Snapshot

Schema-first approach in NestJS:
1. Write GraphQL schema (SDL) first.
2. Generate TypeScript types from schema.
3. Implement resolvers matching schema fields.
4. Load schema and resolvers in NestJS GraphQL module.
5. Server runs and responds to queries based on schema.

Full Transcript

In the schema-first approach with NestJS, you start by writing the GraphQL schema using SDL. This schema defines the API's shape and fields. Next, you generate TypeScript types from this schema to help with type safety. Then, you implement resolver functions that match the schema's fields, providing the actual data or logic. After that, you load the schema and resolvers into the NestJS GraphQL module, which sets up the server. Finally, the server runs and can respond to GraphQL queries according to the schema and resolvers. This approach ensures a clear API contract and organized code.

Practice

1. What is the main idea behind the Schema-first approach in NestJS GraphQL?

easy

A. Use REST endpoints before adding GraphQL

B. Write resolvers first, then generate the schema automatically

C. Define the GraphQL schema first, then write resolvers to match it

D. Skip schema and use only TypeScript interfaces

Solution

1. Step 1: Understand Schema-first approach concept

   Schema-first means you write the GraphQL schema (types, queries, mutations) before coding the logic.

2. Step 2: Match resolvers to schema

   Resolvers are then implemented to fulfill the schema's fields and operations.

3. Final Answer:

   Define the GraphQL schema first, then write resolvers to match it -> Option C

4. Quick Check:

   Schema-first = Define schema first [OK]

Hint: Schema-first means schema before code [OK]

Common Mistakes:

• Thinking resolvers come before schema
• Confusing schema-first with code-first
• Assuming REST is involved
• Skipping schema definition

2. Which of the following is the correct way to define a GraphQL type in a schema-first approach SDL file?

easy

A. type User { id: ID! name: String! }

B. class User { id: number; name: string; }

C. interface User { id: ID; name: String }

D. schema User { id: ID! name: String! }

Solution

1. Step 1: Recognize GraphQL SDL syntax

   GraphQL SDL defines types with the keyword type followed by fields and their types.

2. Step 2: Check each option

   type User { id: ID! name: String! } uses correct SDL syntax. Options B and C use TypeScript syntax, and A uses invalid keyword schema for type definition.

3. Final Answer:

   type User { id: ID! name: String! } -> Option A

4. Quick Check:

   SDL type syntax = type User { id: ID! name: String! } [OK]

Hint: SDL uses 'type' keyword with fields and types [OK]

Common Mistakes:

• Using TypeScript syntax instead of SDL
• Confusing 'schema' keyword with 'type'
• Omitting exclamation marks for required fields

3. Given this schema snippet:

type Query { hello: String! }

And this resolver in NestJS:

@Resolver('Query')
export class HelloResolver {
  @Query()
  hello() {
    return 'Hi there!';
  }
}

What will be the result of querying { hello }?

medium

A. "Hi there!"

B. null

C. Error: Resolver method missing

D. undefined

Solution

1. Step 1: Match schema and resolver

   The schema defines a Query field hello returning a non-null String. The resolver implements a method hello() returning 'Hi there!'.

2. Step 2: Query execution result

   When querying { hello }, the resolver returns 'Hi there!', so the response is the string "Hi there!".

3. Final Answer:

   "Hi there!" -> Option A

4. Quick Check:

   Schema and resolver match = returns 'Hi there!' [OK]

Hint: Resolver method name matches schema field [OK]

Common Mistakes:

• Not matching resolver method name to schema field
• Returning undefined or null in resolver
• Missing @Query decorator

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

@Resolver('Query')
export class UserResolver {
  @Query()
  user(id: string) {
    return { id, name: 'Alice' };
  }
}

Assuming the schema defines user(id: ID!): User.

medium

A. Resolver class name must be UserQueryResolver

B. Missing @Args decorator for the id parameter

C. Return type must be a string, not an object

D. Schema should not have arguments in schema-first

Solution

1. Step 1: Check resolver method parameters

   The resolver method user expects an argument id. In NestJS schema-first, arguments must be decorated with @Args() to map schema args.

2. Step 2: Identify missing decorator

   The code misses @Args('id') before the id parameter, so NestJS won't pass the argument correctly.

3. Final Answer:

   Missing @Args decorator for the id parameter -> Option B

4. Quick Check:

   Arguments need @Args decorator [OK]

Hint: Use @Args() for resolver method arguments [OK]

Common Mistakes:

• Forgetting @Args decorator on parameters
• Wrong resolver class naming (not required)
• Returning wrong types
• Thinking schema can't have arguments

5. You have this schema-first GraphQL SDL:

type Mutation {
  updateUser(id: ID!, name: String): User
}

type User {
  id: ID!
  name: String!
}

Which resolver implementation correctly updates the user name and returns the updated user in NestJS?

hard

A. @Mutation()
updateUser(@Args('id') id: string, @Args('name') name: string) {
return { id, name };
}

B. @Mutation()
updateUser(id: string, name: string) {
const user = users.find(u => u.id === id);
user.name = name;
return user;
}

C. @Mutation()
updateUser(@Args() args) {
const user = users.find(u => u.id === args.id);
user.name = args.name;
return user;
}

D. @Mutation()
updateUser(@Args('id') id: string, @Args('name') name?: string) {
const user = users.find(u => u.id === id);
if (user && name) user.name = name;
return user;
}

Solution

1. Step 1: Match resolver signature to schema

   The schema defines updateUser(id: ID!, name: String): User. The resolver must use @Args('id') and optional @Args('name') parameters.

2. Step 2: Check update logic and return

   @Mutation() updateUser(@Args('id') id: string, @Args('name') name?: string) { const user = users.find(u => u.id === id); if (user && name) user.name = name; return user; } finds the user by id, updates name only if provided, and returns the user object, matching schema and logic.

3. Step 3: Analyze other options

   @Mutation() updateUser(id: string, name: string) { const user = users.find(u => u.id === id); user.name = name; return user; } misses @Args decorators, so arguments won't map. @Mutation() updateUser(@Args() args) { const user = users.find(u => u.id === args.id); user.name = args.name; return user; } uses @Args() args but does not check if user exists before setting user.name, causing runtime error if user not found. @Mutation() updateUser(@Args('id') id: string, @Args('name') name: string) { return { id, name }; } returns a new object without updating the stored user.

4. Final Answer:

   The resolver using @Args('id') id: string, @Args('name') name?: string with conditional update logic -> Option D

5. Quick Check:

   Use @Args and update logic correctly [OK]

Hint: Use @Args for each param and update data before return [OK]

Common Mistakes:

• Missing @Args decorators
• Not checking if user exists before update
• Returning new object without updating data
• Using @Args() without destructuring