4 Tricks to Going Real-Time for Developers

This is the second in a three part series on going Real-Time. The first part gave advise to software architects. These four tips summarize our lessons learned during this integration effort from a developer’s perspective.

1. Be prepared for a lot more Javascript. Even if you use open source libraries such as strophe, your developers are going to be dealing with and your user’s web browsers are going to be downloading a lot more code. This adds complexity to your client-side code base, slows total page load speed, and increases network traffic. To deliver this experience with a minimal impact to page load, render time, and network traffic, our Web team built a custom Javascript client to share connections over BOSH to our back-end XMPP servers.
2. In the push driven world of RTC, the chat server calls you. Many web developers are used to writing code that just calls the server then registers a handler for that response. That is what AJAX is all about. When RTC enabling a web app, these developers need to be able to write code to handle server responses even when they didn’t request anything. It’s a paradigm shift that may take some getting used to for the engineers.
3. Case in point, the complex state machine of subscription states in roster and presence can cause many a scratching of the head when bugs about friending failures get filed. If your user’s will exchange presence and messages with a select group of people, then you need to budget more time to deal with the inevitable cognitive mismatch between the bi-directional, multi-phase subscription based model of XMPP and how your web app defines the who a user’s friends or team mates are. A classic mistake that we encountered at Zoosk was making an implicit assumption about the order in which packets will arrive.
4. Server code will need to act like a chat client too. Since your API tier will most probably have to send chat packets too, it should be prepared to log in to the chat clusters and act like a surrogate user at times. This client oriented register handlers for packets style of programming can be antithetical to the classical server design of get in, get out, inputs, processing, and outputs. At Zoosk, we solved this problem by making sure that the part that talks to the chat server is never in the thread that is directly serving a user’s request. Also, we employed the concept of administrator proxied connections in which the app code logs in as a chat administrator once then sends lots of packets as if it were different end users. This approach allows you to use connection pooling techniques.

Real-Time Communications can be a great addition to any social site but only if the developers are ready to change their ways. Share these four tips with each developer to help them overcome some of the mental traps and gotchas to switching over to a real-time world.

Glenn Engstrand
Senior Software Engineer for Real-Time Communications
Platform Team