A thread for considering the appropriate realtime-ish comms framework

[leppert]

@davidbyrd11 and I talked today and he mentioned that @sjkaliski has some good experience in this area so I thought it worth having a discussion.

The project requirements are as such:

• Should scale as easily as possible
• Should allow for easy development of chat like features
• Should be easily published to and consumed by a variety of clients (Rails, iOS, etc)
• Should permit communication without the involvement of the Rails app ("User X is typing" statuses shouldn't need to pass through the Rails server, for instance)
• Data persistence isn't especially important (i.e. if the socket server fails, there's no need to restore state to that server. The client can retrieve state from the Rails app if needed)
• Realtime only needs to feel realtime. A few lost seconds here or there aren't critical

The current strategy is to use Pusher with the expectation that we'll eventually host our own Slanger instances. Slanger is an open source, Redis backed, Pusher implementation. This affords us:

• A quick launch out of the gate with a hosted solution
• A slew of client libraries for a variety of platforms and maintained docs.
• A clear upgrade / scaling path with Slanger
• A safety net / fallback to Pusher.com in the event that self-hosting fails or proves problematic

With those things in mind, let me know what you guys think. I think the current strategy makes a lot of sense but it's only a means to an end and if there are better means then let's use them.

[thebyrd]

I think we should email layervault and ask why they didn't user pusher. My guess is that iOS support wasn't important for PSD versioning.

[sjkaliski]

Yes, so as @davidbyrd11 said I've got some experience with this. I actually gave a talk at the node.js meetup a couple months back on realtime apis using node & socket.io (repo here).

Lots of these tools for developing real time are very scalable, work nicely, and are easy to use. The main consideration, then, is your implementation of it.

If you have a fixed quantity, n, where n is the total number of rooms you are currently pushing data to, and m, where m is the number of people currently in room n_i, then you want to ensure the total processes "established" is never more than n, where m is either pooled into process for n_i or that events m_j is bound to events in n_i.

Sorry for the math talk haha.

To separate this process from the rails server, run a separate server that manages each of these connections. When a client connects it will "subscribe" to events in that "room." When any event is triggered (ie. "userIsTyping") that event is sent as a JSON object to all current subscriptions of that room.

So long as Rails and iOS and the browser are all compatible with whatever service or library, it'll be no problem.

The other server you create should have access to your database too if need be.