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.