WebSocket transport in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

WebSocket subscription query output

Consider a GraphQL subscription over WebSocket that listens for new messages in a chat room. The subscription query is:

subscription { newMessage { id content sender } }

When a new message with id: 101, content: "Hello!", and sender: "Alice" arrives, what is the expected JSON output sent over the WebSocket?

A {"newMessage": {"id": 101, "content": "Hello!", "sender": "Alice"}}

B {"data": {"newMessage": {"id": 101, "content": "Hello!", "sender": "Alice"}}}

C {"data": {"message": {"id": 101, "content": "Hello!", "sender": "Alice"}}}

D {"data": {"newMessage": {"id": "101", "content": "Hello!", "sender": "Alice"}}}

💡 Hint

GraphQL responses wrap the result inside a data field matching the subscription field name.

The correct output wraps the subscription field newMessage inside the data key. The id is a number, not a string, matching the schema.

📝 Syntax

intermediate

Identify invalid WebSocket GraphQL subscription message

Which of the following WebSocket messages is not a valid GraphQL subscription start message according to the Apollo protocol?

A {"id": "1", "type": "start", "payload": {"query": "subscription { newMessage { id content } }", "variables": {}}}

B {"id": "1", "type": "start", "payload": {"query": "subscription { newMessage { id content } }"}}

C {"id": 1, "type": "start", "payload": {"query": "subscription { newMessage { id content } }"}}

D {"id": "1", "type": "start", "payload": {"query": "subscription { newMessage { id content } }", "operationName": "NewMsg"}}

💡 Hint

The id field must be a string, not a number.

Option C uses a numeric id which violates the Apollo WebSocket protocol requiring id to be a string.

❓ optimization

advanced

Optimizing WebSocket subscription message size

You want to reduce the size of WebSocket messages for a GraphQL subscription that sends frequent updates. Which approach will most effectively reduce message size without losing data?

A Send only changed fields in the subscription payload instead of the full object.

B Compress the WebSocket messages using gzip before sending.

C Use shorter field names in the GraphQL schema and queries.

D Batch multiple subscription updates into a single WebSocket message.

💡 Hint

Think about sending less data per message rather than just compressing or batching.

Sending only changed fields reduces the payload size directly. Shorter field names require schema changes and may break clients. Compression and batching help but do not reduce individual message size as effectively.

🔧 Debug

advanced

Debugging WebSocket subscription connection failure

A client tries to start a GraphQL subscription over WebSocket but immediately receives a Connection error and the subscription does not start. The server logs show no errors. Which is the most likely cause?

A The client did not send the <code>connection_init</code> message before <code>start</code>.

B The server does not support subscriptions.

C The WebSocket URL is missing the <code>ws://</code> or <code>wss://</code> scheme.

D The subscription query has a syntax error.

💡 Hint

Check the required handshake messages in the WebSocket protocol.

The Apollo WebSocket protocol requires the client to send a connection_init message before starting subscriptions. Missing this causes connection errors without server logs.

🧠 Conceptual

expert

Understanding WebSocket transport advantages for GraphQL

Why is WebSocket transport preferred over HTTP polling for real-time GraphQL subscriptions?

A WebSocket automatically retries failed queries without client intervention.

B WebSocket allows sending multiple queries in a single HTTP request.

C WebSocket encrypts data by default, unlike HTTP polling.

D WebSocket maintains a persistent connection, reducing overhead and latency for real-time updates.

💡 Hint

Consider connection persistence and efficiency for real-time data.

WebSocket keeps a single open connection, so updates can be pushed instantly without repeated HTTP requests, reducing latency and overhead. Other options are incorrect or unrelated.

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