WebSockets Sound Simple Until You Have to Maintain One
There's a moment every engineer hits when building a real-time feature: you look at the WebSocket spec, think "okay, just a persistent TCP connection with a handshake," and start writing the server. Then a week later you're debugging a half-open connection that isn't sending frames but also isn't closing, and you're reading RFC 6455 at midnight wondering where things went wrong.
This is not a hypothetical. It's basically a rite of passage.
The part nobody warns you about: state
HTTP is blissfully stateless. Each request carries everything it needs, and when it's done, it's done. WebSockets are the opposite. Once a connection opens, you own it. You're responsible for tracking who's connected, what they're subscribed to, whether they're still alive, and what happens when they drop.
