WebSocket.binaryType: The binary data type used by the connection.
WebSocket.bufferedAmount: The number of bytes of queued data.
WebSocket.extensions: The extensions selected by the server.
WebSocket.protocol: The sub-protocol selected by the server.
WebSocket.readyState: The current state of the connection.
WebSocket.url: The absolute URL of the WebSocket.
send(data): Sends data to the server over the WebSocket connection.
close([code, reason])Closes the WebSocket connection. You can optionally provide a status code and a reason for closing.
addEventListener(type, listener): Adds an event listener for a specific event type
removeEventListener(type, listener): Removes an event listener.
You're building a chat feature. The WebSocket connection just opened — how do you send a JSON message to the server?
What happens if you call socket.send() immediately after new WebSocket() but before the 'open' event fires?
The server sends you a message. Where do you write the code to parse and display it?
Users report messages occasionally not arriving. You see 'onerror' firing but 'onclose' doesn't. How do you debug whether it's a network blip or server-side drop?
You need to support both JSON and binary (protobuf) payloads on the same connection. How do you structure the message handling so the rest of your app doesn't care about the wire format?
The backend team wants to add a heartbeat. Where do you put the ping/pong logic — client, server, or both — and how do you avoid false disconnects during GC pauses?
At 50k concurrent connections, you're seeing memory growth from unclosed sockets. Walk me through how you'd instrument the WebSocket lifecycle to find leaks — what events, what metrics, what cleanup?
Design a backpressure strategy: the client produces messages faster than the network can drain. Do you buffer, drop, or apply flow control? How does that interact with the WebSocket's internal send buffer?
You're migrating from long-polling to WebSockets for a real-time dashboard. The legacy code expects request/response semantics. How do you bridge the paradigm gap without rewriting all consumers?
Three teams own services that push real-time updates to a shared WebSocket gateway. How do you define a protocol contract (frame format, auth, versioning) that lets teams deploy independently without breaking clients?
Your company acquired a product that uses Socket.IO. You're standardizing on raw WebSockets. Plan the migration: compatibility layer, feature parity checklist, rollback criteria, and how you measure 'done'.
The security team mandates mutual TLS for all WebSocket connections. Your load balancer terminates TLS. How do you propagate client cert identity to the WebSocket application layer without redesigning the auth system?