The Realtime Engine(devthought.com)
devthought.com
The Realtime Engine
http://www.devthought.com/2012/07/07/the-realtime-engine/
2 comments
Nice that they're going to write the connection part properly. I had to switch from socket.io to sockjs a long time ago because socket.io was just too flaky. The code was pretty ad-hoc with its state (mishmash of .reconnecting, .reconnected, .disconnected, etc. predicates), and clients would randomly get stuck in in-between states if they were on 3G etc.
I had the same experience. socket.io was too flaky. Also I didn't need Flash support etc. In the end when I started to fix socket.io code to suit my needs and to handle the weird errors, I simply hacked together something in Go that pulls messages from Redis and writes them to Websocket or as HTTP GET response. It has only Websocket and HTTP POST/GET support but who cares. The simpler the code for handling these things, the better. Maybe socket.io got too complicated or something.
In my experience, Websocket is not something to depend on. But it's really nice to have and should be used as an upgrade if available.
In my experience, Websocket is not something to depend on. But it's really nice to have and should be used as an upgrade if available.
Is SockJS any better?
SockJS doesn't have those problems?
Wise decision to extract out browsers and environmental dependencies into Engine.IO. Apart from decoupling concerns, both these libraries become simpler and can attract more contributors with relevant experience. Socket.IO can now focus on important features like JSON encoding / decoding, custom events, automatic reconnection with exponential backoff and multiplexing etc. It would have been nice to show some before and after code examples and stats on performance under websockets, long polling etc. scenarios.