Techniques for programming real-time updates

The history of internet and web development always fought against stateless connections between web browsers and servers. Programmers keep trying to create a more realistic experience in order to hide some of the protocol’s limitations.

In order to give the user the feeling of live responses, we can go through several paths. There are a lot of implementations to give the user a real sense of immediate interaction, some using Ajax, but sometime we need to change content for the user without his interaction. Sometimes server-side needs to send information for the user like in multiplayer games, chats or projects with more than one collaborator.

It’s not trivial to make multiple clients communicate in the same page with the sensation of realtime response without a first user interaction. An usual approach for this is to invoke the server in small time periods, but this creates problems like a huge unnecessary amount of protocol data traffic and a middleware storage, normally any relational database, which isn’t designed to it.

New technologies for new needs

In order to create realtime connections between servers and client browsers some new technologies have emerged. The Node.js aims at creating a scalable network and handling multiple clients connections concurrently. To handle the publisher/subscribe necessity, there are some NoSQL alternatives like Redis, an advanced key-value store. We can orchestrate everything using frameworks like Ruby on Rails .

The technologies quoted above can reach a particular architecture when putted together. In a realtime environment the first client can send a normal HTTP request for a Ruby on Rails application, this one detects the demand and now needs to notify another client who is interacting with the same application. We need asynchronous behavior here between this clients and, to achieve that, our Ruby application can publish a message to some key-value store, like Redis in this architecture.

The other client needs to be notified now but without interactions. That’s where Node.js, using javascript’s callbacks come into. We can run another server running javascript in the server side. The second client now completes the PUBSUB process, subscribing to Redis and performing a desired callback with given information.

Sometime ago, Ajax changed the way people interact with internet, giving users an experience similar to what we have seen in desktop projects.

Now we are experiencing new trends with realtime necessities where users interact and receive a lot of information even without directly performing events.

Maybe all of these new demands will cause a revolution on the web like what Ajax created sometime ago.

Although doing this correctly can be a challenge in web development, a whole new creative solution can be raised with this new approach in mind. In some time, acting realtime in almost all projects we work on can be a reality, jumping to a new age of web applications, even more dynamically and scalable.