GraphQL & WebSockets

5.5.1Definition

GraphQL is a query language that lets a client request exactly the fields it needs from a single endpoint, rather than hitting multiple fixed REST endpoints and receiving fixed response shapes. WebSockets are a protocol that upgrades an HTTP connection into a persistent, two-way channel, allowing the server to push data to the client without the client having to ask again.

5.5.2Why It Exists

REST's fixed endpoints often return more data than a client needs (over-fetching) or require multiple round-trips to assemble a single screen's data (under-fetching) — GraphQL exists to let the client specify precisely what it needs in one request. Separately, REST's request-response model has no way for a server to notify a client of new data without being asked — WebSockets exist to solve real-time cases like chat (3.31) or live notifications where the server needs to speak first.

5.5.3When to Reach for Each

5.5.4Common Mistakes

• Adopting GraphQL for a simple CRUD API with no genuine over-fetching problem, adding a new query language and resolver layer for no corresponding benefit.
• Using polling instead of WebSockets for genuinely real-time features, repeatedly hitting the server every few seconds and calling it "live" when a persistent connection would be both faster and cheaper.
• No query depth or complexity limiting in GraphQL, allowing a single malicious or careless deeply-nested query to overload the database.
• Treating WebSocket connections as free — each open connection consumes server memory, and an architecture untested at scale can exhaust connection limits quickly.

5.5.5Best Practices

• Reach for GraphQL only when a client genuinely needs flexible, composed data shapes across multiple resource types — not by default.
• Apply query complexity/depth limits on any public GraphQL endpoint.
• Use a managed WebSocket/real-time layer (or a service like Pusher/Ably) before building connection-scaling infrastructure from scratch.