WebSocket transport in GraphQL - Step-by-Step Execution

Concept Flow - WebSocket transport

Client initiates WebSocket connection

↓

Server accepts connection

↓

Client sends GraphQL subscription request

↓

Server processes subscription

↓

Server sends real-time data updates

↓

Client receives updates and processes

↓

Connection stays open for continuous data

↓

Client or server closes connection

This flow shows how a client and server use WebSocket to keep a live connection for GraphQL subscriptions, sending and receiving real-time data continuously.

Execution Sample

GraphQL

1. Client opens WebSocket to server
2. Client sends subscription query
3. Server acknowledges and starts sending data
4. Server sends data updates as events occur
5. Client receives and processes updates
6. Connection remains open until closed

This sequence shows the steps of establishing and using WebSocket transport for GraphQL subscriptions to get live data updates.

Execution Table

Step	Action	Message Type	Data Sent/Received	Connection State
1	Client opens WebSocket	Connection Request	null	Open
2	Server accepts connection	Connection Ack	null	Open
3	Client sends subscription query	Subscription Start	{"query": "subscription { newMessages }"}	Open
4	Server acknowledges subscription	Subscription Ack	Subscription accepted	Open
5	Server sends data update	Data	{"newMessages": "Hello!"}	Open
6	Client receives data update	Data	{"newMessages": "Hello!"}	Open
7	Server sends another update	Data	{"newMessages": "How are you?"}	Open
8	Client receives second update	Data	{"newMessages": "How are you?"}	Open
9	Client closes connection	Connection Terminate	null	Closed
10	Server acknowledges close	Connection Closed	null	Closed

💡 Connection closed by client at step 9, ending WebSocket session

Variable Tracker

Variable	Start	After Step 3	After Step 5	After Step 7	Final
Connection State	Closed	Open	Open	Open	Closed
Subscription Status	null	Started	Active	Active	Terminated
Received Data	null	null	{"newMessages": "Hello!"}	{"newMessages": "How are you?"}	{"newMessages": "How are you?"}

Key Moments - 3 Insights

Why does the connection stay open after the first data update?

Because WebSocket transport keeps the connection open to continuously send real-time updates, as shown in steps 5 to 8 in the execution_table.

What happens if the client closes the connection?

The connection state changes to Closed, and the server acknowledges this closure, ending the session as seen in steps 9 and 10.

How does the client start receiving live data?

By sending a subscription query (step 3) and receiving an acknowledgment (step 4), the server then sends live data updates (steps 5 and 7).

Visual Quiz - 3 Questions

Look at the execution_table, what is the connection state after step 4?

A Closed

B Open

C Pending

D Terminated

💡 Hint

Check the 'Connection State' column at step 4 in the execution_table.

At which step does the client send the subscription query?

A Step 2

B Step 5

C Step 3

D Step 9

💡 Hint

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

If the client never closes the connection, what would happen to the connection state in variable_tracker?

A It would remain 'Open' after the final step

B It would change to 'Closed' automatically

C It would become 'Pending'

D It would reset to 'null'

💡 Hint

Refer to the 'Connection State' row in variable_tracker and consider what closing the connection does at step 9.

Concept Snapshot

WebSocket transport keeps a live connection open between client and server.
Client sends a subscription query to start receiving real-time data.
Server sends updates as events happen without reconnecting.
Connection stays open until client or server closes it.
Used mainly for GraphQL subscriptions to get live updates.

Full Transcript

WebSocket transport in GraphQL starts when the client opens a WebSocket connection to the server. The server accepts this connection, and the client sends a subscription query to listen for live data. The server acknowledges the subscription and begins sending data updates as events occur. The client receives these updates continuously while the connection remains open. This live connection allows real-time data flow without repeated requests. Finally, either the client or server can close the connection to end the session. This process enables efficient live data updates in applications.

Practice

1. What is the main benefit of using WebSocket transport with GraphQL subscriptions?

easy

A. It converts GraphQL queries into SQL automatically.

B. It stores data permanently in the database.

C. It keeps a live connection for real-time data updates.

D. It compresses data to reduce storage size.

Solution

1. Step 1: Understand WebSocket transport purpose

   WebSocket transport maintains a continuous connection between client and server.

2. Step 2: Connect with GraphQL subscriptions

   This live connection allows instant data updates, which is the main benefit for subscriptions.

3. Final Answer:

   It keeps a live connection for real-time data updates. -> Option C

4. Quick Check:

   WebSocket = live real-time updates [OK]

Hint: WebSocket means live connection for instant updates [OK]

Common Mistakes:

• Confusing WebSocket with data storage
• Thinking it converts queries automatically
• Assuming it compresses data

2. Which of the following is the correct way to initiate a WebSocket connection for GraphQL subscriptions?

easy

A. const ws = new WebSocket('ws://example.com/graphql');

B. const ws = new WebSocket('http://example.com/graphql');

C. const ws = new WebSocket('ftp://example.com/graphql');

D. const ws = new WebSocket('file://example.com/graphql');

Solution

1. Step 1: Identify the correct WebSocket URL scheme

   WebSocket URLs start with 'ws://' or 'wss://' for secure connections.

2. Step 2: Check the options

   Only const ws = new WebSocket('ws://example.com/graphql'); uses 'ws://' which is the correct scheme for WebSocket connections.

3. Final Answer:

   const ws = new WebSocket('ws://example.com/graphql'); -> Option A

4. Quick Check:

   WebSocket URL starts with ws:// [OK]

Hint: WebSocket URLs start with ws:// or wss:// [OK]

Common Mistakes:

• Using http:// instead of ws://
• Using ftp:// or file:// which are invalid for WebSocket
• Confusing secure ws with http

3. Given this GraphQL subscription client code snippet, what will be the output when a new message arrives?

const subscription = client.subscribe({ query: MESSAGE_SUBSCRIPTION });
subscription.subscribe({
  next(data) { console.log(data); },
  error(err) { console.error(err); }
});

medium

A. Does nothing because subscription is not started.

B. Throws a syntax error because subscribe is not a function.

C. Logs an error immediately.

D. Logs the new message data to the console.

Solution

1. Step 1: Understand the subscription method

   The client.subscribe returns an observable that listens for new data.

2. Step 2: Analyze the subscribe callback

   The next callback logs incoming data, so when a new message arrives, it prints it.

3. Final Answer:

   Logs the new message data to the console. -> Option D

4. Quick Check:

   Subscription next callback logs data [OK]

Hint: Subscription next callback logs incoming data [OK]

Common Mistakes:

• Thinking subscribe is not a function
• Assuming subscription needs manual start
• Expecting immediate error without cause

4. Identify the error in this WebSocket transport setup for GraphQL subscriptions:

const ws = new WebSocket('http://example.com/graphql');
const subscription = client.subscribe({ query: SUBSCRIPTION_QUERY });
subscription.subscribe({
  next(data) { console.log(data); },
  error(err) { console.error(err); }
});

medium

A. The error callback is missing a return statement.

B. WebSocket URL uses 'http://' instead of 'ws://'.

C. The subscribe method is called twice incorrectly.

D. Subscription query is missing variables.

Solution

1. Step 1: Check the WebSocket URL scheme

   The URL uses 'http://' which is incorrect for WebSocket connections; it should be 'ws://'.

2. Step 2: Verify other parts

   Subscription query and callbacks are correctly used; no missing variables or double subscribe calls.

3. Final Answer:

   WebSocket URL uses 'http://' instead of 'ws://'. -> Option B

4. Quick Check:

   WebSocket URL must start with ws:// [OK]

Hint: Check WebSocket URL scheme for ws:// [OK]

Common Mistakes:

• Ignoring URL scheme errors
• Assuming variables are always required
• Confusing subscribe method usage

5. You want to build a live chat app using GraphQL subscriptions over WebSocket. Which approach best ensures efficient real-time updates and minimal server load?

hard

A. Use WebSocket transport with filtered subscriptions to send only relevant messages to each client.

B. Use HTTP polling every second to fetch new messages.

C. Send all chat messages to every client regardless of chat room.

D. Use WebSocket but reconnect on every new message.

Solution

1. Step 1: Understand real-time update needs

   Live chat requires instant updates with minimal delay and server load.

2. Step 2: Evaluate options for efficiency

   Using WebSocket with filtered subscriptions sends only needed messages, reducing unnecessary data and load.

3. Step 3: Compare alternatives

   Polling wastes resources; sending all messages to all clients is inefficient; reconnecting often adds overhead.

4. Final Answer:

   Use WebSocket transport with filtered subscriptions to send only relevant messages to each client. -> Option A

5. Quick Check:

   Filtered WebSocket subscriptions = efficient real-time updates [OK]

Hint: Filter subscriptions to send only needed data [OK]

Common Mistakes:

• Using polling instead of WebSocket
• Broadcasting all messages to all clients
• Reconnecting WebSocket too frequently