WebSocket transport in GraphQL - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to start a WebSocket connection for GraphQL subscriptions.

GraphQL

const wsClient = new WebSocket('[1]');

Drag options to blanks, or click blank then click option'

Aftp://localhost:4000/graphql

Bhttp://localhost:4000/graphql

Cfile://localhost:4000/graphql

Dws://localhost:4000/graphql

Attempts:

3 left

💡 Hint

Common Mistakes

Using http:// instead of ws://

Using unsupported protocols like ftp:// or file://

The WebSocket URL must start with ws:// or wss:// for secure connections. Here, ws://localhost:4000/graphql is correct.

2fill in blank

medium

Complete the code to send a GraphQL subscription start message over WebSocket.

GraphQL

wsClient.send(JSON.stringify({ type: '[1]', id: '1', payload: { query: SUBSCRIPTION_QUERY } }));

Drag options to blanks, or click blank then click option'

Astart

Bquery

Cstop

Dconnection_init

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'query' instead of 'start' for subscription messages

Using 'connection_init' which is for connection setup, not starting subscriptions

The message type to start a subscription is start. This tells the server to begin sending subscription data.

3fill in blank

hard

Fix the error in the WebSocket message handler to correctly parse incoming data.

GraphQL

wsClient.onmessage = event => { const data = JSON.parse(event.[1]); console.log(data); };

Drag options to blanks, or click blank then click option'

Amessage

Bdata

Ctext

Dpayload

Attempts:

3 left

💡 Hint

Common Mistakes

Trying to parse event.message or event.payload which do not exist

Not parsing the string before using it

The WebSocket event object has a data property containing the message as a string. We parse event.data.

4fill in blank

hard

Fill both blanks to correctly handle a GraphQL subscription stop message and close the WebSocket.

GraphQL

if (message.type === '[1]') { wsClient.[2](); }

Drag options to blanks, or click blank then click option'

Astop

Bstart

Cclose

DcloseConnection

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'start' instead of 'stop' to end subscription

Calling a non-existent method like 'closeConnection()'

The message type to stop a subscription is stop. To close the WebSocket, call wsClient.close().

5fill in blank

hard

Fill all three blanks to initialize a WebSocket connection with connection_init message and send it.

GraphQL

const initMessage = { type: '[1]', payload: { headers: { Authorization: '[2]' } } }; wsClient.[3](JSON.stringify(initMessage));

Drag options to blanks, or click blank then click option'

Aconnection_init

BBearer token123

Csend

Dstart

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'start' instead of 'connection_init' for initialization

Forgetting to use 'send' method to send the message

The connection initialization message type is connection_init. The Authorization header uses a bearer token string. To send the message, use wsClient.send().

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