Consider using SockJS internally #155

Closed
devinrhode2 opened this Issue Oct 18, 2012 · 4 comments

Projects

None yet

4 participants

@devinrhode2

Noticed the Socket.io client side file is a hefty 78k, whereas SockJS is 9k, and engine.io is about 16k. Engine.io is to SockJS which are both nearly identical to the official websocket api.

Perhaps a benefit of using engine.io is more seamless integration with socket.io if it's desired, but if you just want to do a few messages, then you only load 16k of js, and not 78.

@myguidingstar

Totally agree

@nateps
Collaborator
nateps commented Jun 5, 2013

We now recommend BrowserChannel by default, and the connection layer has been moved to its own module so that any socket-like connection type may be used with Derby.

@nateps nateps closed this Jun 5, 2013
@devinrhode2

The fact that BrowserChannel is used in gmail is very assuring 👍

@korbin
korbin commented Jun 19, 2013

Just to get comments out of IRC onto the boards - I spoke to @josephg about this particular issue the other day, and the advantages thereof of providing native WebSocket support - I will be writing an Engine.io driver for this as soon as the API is made available.

In my particular use case, I have direct control over the client browser stack, and WebSockets provide several sizable horizontal scaling benefits (less LB drama, transit overhead, etc.) when compared to long-polling. I understand the testing with Socket.io created some problems, however, I haven't seen any issues with Engine.io

I will keep the boards posted on whether or not Engine.io performs as well as node-browserchannel, as I know there have been issues with packet ordering, offline message queueing, etc. with other libraries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment