Question

I am writing a Ruby on Rails(3) application that relies on an xml feed that is updated ~30 seconds. Should I be parsing the xml data on my server with some sort of worker? If this is the case, will the server be able to respond to the client fast enough to stay ‘real-time’. I was thinking that it could be done with javascript but I’m not sure.

Edit:
Each update will be around 70kb and the source of the xml is able to handle a ton of connections.

No, this information is not going to be saved to the database. The user will have read-only access to the xml data.

Would it be possible to directly connect to the xml server with javascript on the clientside?

Answer 1

There are 3 realistic ways to approach this. I’m not a ruby guy, but none of these methods are ruby specific, either.

• Refresh the page itself periodically to grab the latest feed. This is the old way of doing it, and though reliable, not a very good user experience.
• Grab the new data periodically via AJAX and append it to the web page UI elements as necessary. This is probably your best bet in a high volume scenario, as it doesn’t retain any active connections to the server and doesn’t refresh the entire page. It also suffers from the same downside as option 1 though, which is that the updates are not real-time.
• If you have a small enough audience or enough servers to split the load, you could take a comet approach. Essentially, each request to the page opens another long-running request in an invisible iframe. The output of the thread serving this request is a series of small, real-time updates in the form of javascript that triggers the UI elements to be updated. You then have to develop the process on the server that parses the input in real-time and notifies each active connection of the new data.

Summary: Use a COMET type setup if you absolutely need real-time data access and/or your target audience is small enough to handle the load. Otherwise, use periodic AJAX updates.