When you google "how to build a chat app in Node.js," the very first result will almost certainly point you to Socket.IO. It is the de facto standa...
For further actions, you may consider blocking this person and/or reporting abuse
Great insights on moving from Socket.IO to raw WebSockets! Your point about mental clarity and knowing exactly what bytes go over the wire really resonates. The reconnection engine implementation was particularly helpful. Thanks for sharing this practical journey!
Glad it was meaningful!
Your reconnect wrapper is solid, but there's one gap that bites in exactly the tunnel scenario you described: reconnecting gets the socket back, it doesn't get back the messages that were sent while you were offline. Socket.IO quietly buffers client emits during a drop and replays them on reconnect, and rebuilding that is the part people miss until a user swears a message vanished. A small outbound queue that holds sends while the socket is closed and flushes on reopen covers most of it, and pairing it with a message id lets the server drop duplicates if a send half-landed before the drop. Doing it the hard way really is how you learn where the magic was hiding.
I hadn't thought of that until now but it seems so obvious now that you mention it. I will definitely fix that. Thank you for such a valuable insight!
no no, thanks YOU! for sharing 😊
Interesting writeup. I went through a similar transition when Socket.IO's protocol overhead became a bottleneck for a real-time dashboard. One thing I missed after switching: automatic reconnection with exponential backoff. Ended up implementing it myself and it was way more nuanced than I expected. The reconnect jitter alone took a day to get right. Worth it for the reduced bundle size though.
Totally agree. I still haven't added jitter to the project but I will now that you mention it. Thanks!
No worries, glad the jitter thing was useful! It's one of those fixes that seems tiny but makes a huge difference once you have a few hundred clients reconnecting at the same time. Good luck with the implementation — let me know if you hit any edge cases.
Yeah good move - as you explain, nowadays (i.e. with modern browsers), there are only 2 things that Socket.IO implements which are really worth it, and it's pretty easy to implement them yourself (on top of native browser APIs) ...
And:
"If you use Socket.IO on the client, you must use a Socket.IO server implementation"
That's a big one - that's real "vendor lock-in" ...
Exactly! It has a chokehold that I, as a full stack developer, would prefer not to have.