Schema-first development in GraphQL - Step-by-Step Execution

Concept Flow - Schema-first development

Define Schema

↓

Generate Server Code

↓

Implement Resolvers

↓

Run Server

↓

Client Queries

↓

Server Resolves Queries

↓

Return Data to Client

Start by writing the schema, then generate server code, implement resolvers, run the server, and finally handle client queries.

Execution Sample

GraphQL

type Query {
  hello: String
}

// Example resolver implementation (JavaScript):
const resolvers = {
  Query: {
    hello: () => "Hello, world!"
  }
};

Defines a schema with a 'hello' query and implements a resolver returning a greeting.

Execution Table

Step	Action	Input/Code	Result/Output
1	Define schema	type Query { hello: String }	Schema with Query type and hello field created
2	Generate server code	Generate types and server stubs	Server code skeleton ready
3	Implement resolver	hello: () => "Hello, world!"	Resolver returns greeting string
4	Run server	Start GraphQL server	Server listens for queries
5	Client sends query	{ hello }	Server receives query
6	Server resolves query	Call hello resolver	"Hello, world!" returned
7	Return data	Send response to client	{ "data": { "hello": "Hello, world!" } }

💡 Execution ends after server returns data to client

Variable Tracker

Variable	Start	After Step 3	After Step 6	Final
Schema	undefined	Defined with Query and hello	Defined	Defined
Server Code	undefined	Skeleton with resolver	Skeleton with resolver	Running server
Resolver hello	undefined	Function returning greeting	Function called, returns greeting	Returns greeting
Client Query	undefined	undefined	Query sent: { hello }	Query processed
Response	undefined	undefined	undefined	{"data":{"hello":"Hello, world!"}}

Key Moments - 3 Insights

Why do we define the schema before writing resolver code?

Because the schema defines the shape of data and queries, guiding the resolver implementation as shown in execution_table step 1 and 3.

What happens if the resolver does not match the schema?

The server may throw errors or return null data, since the schema and resolver must align, as seen in step 3 and 6.

Why is the client query sent after the server runs?

Because the server must be running to accept queries, as shown in steps 4 and 5.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output at step 6?

A Server code skeleton ready

B "Hello, world!" returned

C Schema with Query type and hello field created

D Server listens for queries

💡 Hint

Check the 'Result/Output' column at step 6 in the execution_table

At which step does the client send the query?

A Step 3

B Step 2

C Step 5

D Step 7

💡 Hint

Look for 'Client sends query' in the 'Action' column of execution_table

If the resolver function returned null, which step's output would change?

A Step 6

B Step 4

C Step 1

D Step 2

💡 Hint

Resolver output is shown in step 6 'Result/Output' column

Concept Snapshot

Schema-first development:
1. Write GraphQL schema first.
2. Generate server code from schema.
3. Implement resolvers matching schema.
4. Run server to accept queries.
5. Client queries server, server returns data.
Key: Schema guides all development steps.

Full Transcript

Schema-first development in GraphQL starts by defining the schema that describes the data and queries. Next, server code is generated based on this schema. Developers then implement resolver functions that fulfill the schema's queries. After running the server, clients send queries that the server resolves using the implemented resolvers, returning data back to the client. This approach ensures the API contract is clear and guides the entire development process.

Practice

1. What is the main purpose of schema-first development in GraphQL?

easy

A. To design the data types and API structure before writing code

B. To write all the backend code before defining the API

C. To generate random queries automatically

D. To skip planning and start coding immediately

Solution

1. Step 1: Understand schema-first development

   Schema-first means you create the schema (data types and API) first before coding the backend logic.

2. Step 2: Compare options with definition

   Only To design the data types and API structure before writing code matches this idea; others describe different or incorrect approaches.

3. Final Answer:

   To design the data types and API structure before writing code -> Option A

4. Quick Check:

   Schema-first = plan schema first [OK]

Hint: Schema-first means plan schema before coding [OK]

Common Mistakes:

• Thinking schema is generated after coding
• Confusing schema-first with code-first
• Believing schema-first skips planning

2. Which of the following is the correct way to define a GraphQL type in SDL (Schema Definition Language)?

easy

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

B. type User { id: ID!, name: String! }

C. define type User { id: ID, name: String }

D. class User { id: ID; name: String; }

Solution

1. Step 1: Recall GraphQL SDL syntax

   GraphQL SDL defines types using 'type TypeName { fields }' with field types and optional ! for required.

2. Step 2: Check each option

   type User { id: ID!, name: String! } matches correct SDL syntax. The other options use incorrect keywords or syntax from other languages.

3. Final Answer:

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

4. Quick Check:

   SDL type syntax = type Name { fields } [OK]

Hint: SDL uses 'type Name { fields }' syntax [OK]

Common Mistakes:

• Using 'define' keyword instead of 'type'
• Writing types like classes in other languages
• Omitting exclamation marks for required fields incorrectly

3. Given this schema snippet:

type Query { user(id: ID!): User }

and this query:

{ user(id: "1") { id name } }

What will the query return if the user with id "1" exists?

medium

A. { "data": { "user": null } }

B. { "error": "User not found" }

C. { "data": { "user": { "id": "1", "name": "Alice" } } }

D. SyntaxError

Solution

1. Step 1: Understand the schema and query

   The schema defines a Query type with a user field that takes an id and returns a User type. The query requests user with id "1" and fields id and name.

2. Step 2: Predict the output if user exists

   If user with id "1" exists, the response will include data with user object containing id and name fields.

3. Final Answer:

   { "data": { "user": { "id": "1", "name": "Alice" } } } -> Option C

4. Quick Check:

   Existing user query returns data with user object [OK]

Hint: Existing user query returns data with user object [OK]

Common Mistakes:

• Confusing null response with error
• Expecting error instead of data when user exists
• Misreading query syntax causing syntax error

4. Identify the error in this schema definition:

type Query { getUser(id: ID): User }

What is wrong here?

medium

A. ID is not a valid GraphQL type

B. The User type is missing curly braces

C. Query type cannot have arguments

D. The id argument should be non-nullable with an exclamation mark

Solution

1. Step 1: Review argument type in schema

   The argument 'id' is typed as 'ID' but lacks the exclamation mark, so it is nullable.

2. Step 2: Understand common practice for IDs

   Usually, IDs used to fetch data are required (non-nullable), so 'ID!' is preferred to ensure the argument is provided.

3. Final Answer:

   The id argument should be non-nullable with an exclamation mark -> Option D

4. Quick Check:

   Required args use ! in schema [OK]

Hint: Use ! for required arguments in schema [OK]

Common Mistakes:

• Thinking Query type cannot have arguments
• Believing User type needs braces in this line
• Assuming ID is invalid type

5. You want to add a new mutation to update a user's email in a schema-first GraphQL API. Which schema definition correctly adds this mutation?

hard

A. type Mutation { updateUserEmail(id: ID!, email: String!): User }

B. mutation updateUserEmail(id: ID!, email: String!): User

C. type Mutation updateUserEmail(id: ID!, email: String!): User

D. type Mutation { updateUserEmail(id: ID, email: String): Boolean }

Solution

1. Step 1: Recall mutation syntax in schema-first SDL

   Mutations are defined inside a 'type Mutation { ... }' block with fields representing mutation functions and their arguments and return types.

2. Step 2: Analyze each option

   type Mutation { updateUserEmail(id: ID!, email: String!): User } correctly defines a mutation field with required id and email arguments and returns a User type. mutation updateUserEmail(id: ID!, email: String!): User uses incorrect syntax without 'type'. type Mutation updateUserEmail(id: ID!, email: String!): User misses braces. type Mutation { updateUserEmail(id: ID, email: String): Boolean } uses optional args and returns Boolean, which may not match update use case.

3. Final Answer:

   type Mutation { updateUserEmail(id: ID!, email: String!): User } -> Option A

4. Quick Check:

   Mutations inside 'type Mutation { }' with args and return type [OK]

Hint: Mutations go inside 'type Mutation { }' with args and return type [OK]

Common Mistakes:

• Omitting 'type' keyword for Mutation
• Forgetting braces around Mutation fields
• Using optional args when required
• Returning wrong type for update mutation