From Python to Ruby on Rails to Erlang

We started working on SlideAware Workgroups about a year ago. After collecting feedback from Alpha users in November 06, we decided to build the simpler SlideAware Personal which allows users to publish presentation to a URL and conduct live slideshows. SlideAware Personal has been live since March 07. SlideAware Workgroups will be released in the next few months. Both applications share the same architecture.

There are really two front-ends:

• The PowerPoint toolbar which provides buttons to allow users to very easily send slides to SlideAware or get feedback from co-workers. It is written in Visual Basic Application and leverages external DLLs for image and flash generation, file compression, etc.

• The web application leverages Dojo and Scriptaculous and interacts with the server using XmlHttpRequest. The user interface is entirely done in JavaScript in the browser. The JavaScript code manipulates the business objects (slides, presentations, tags, users,  etc.) and generates the user interface using Dojo widgets. The server is invoked to persist and query objects. It serves data as JSON instead of sending back HTML snippets.

The back-end has gone through several iterations.

We wrote the first version (0.1) of SlideAware Workgroups using Python and TurboGears. TurboGears combines a template engine (Kid), an object-relational mapping manager (SQLObject). Data (slides, presentations, tags, users) was stored in a SQLite database, while text indexes for the slides’ content were stored using Lucene. We leveraged xml-rpc to communicate between the python server and the java server (Lucene). We had a Jython wrapper on the java side.

We decided to switch to Ruby on Rails for the second version (0.2) of SlideAware Workgroups. Rails has a much larger following and finding solutions to issues is therefore a lot easier. Because the presentation layer is entirely done in the browser in JavaScript, our back-end code is fairly lean and was ported to Ruby on Rails in a matter of weeks. We kept SQLite, xml-rpc and Lucene. We added Lighttpd in the mix as our web server.

At that point, we started wondering about how our heterogeneous back-end stack could be made available, reliable and scalable. We had been hearing for a while about Erlang, the concurrent programming language initially developed at Ericson,  and Mnesia the real-time distributed database written in Erlang that is part of Erlang’s Open Telecom Platform,  and Yaws the web server written in Erlang.

We liked the idea of replacing our multiple language stack (Lighttpd + RoR + SQLlite + XMLRpc + Jython + Lucene) with an Erlang-only solution (Yaws + Mnesia + Erlang).

We were particularly intrigued by the promises of:

• High concurrency: Yaws leverages Erlang’s  light-weight threading system and supposedly performs very well under high concurrency. Mnesia’s tables can be replicated across nodes to allow more reads to happen concurrently.
• High performance: Mnesia resides in memory and is built to allow fast real-time lookups.
• High reliability: Erlang flagship project, the AXD301 which has over 2 million lines of Erlang has achieved a NINE nines reliability (yes, you read that right, 99.9999999%).

So we made the switch for version 0.5 of SlideAware Workgroups.

In my next post, I’ll tell you whether Erlang lived up to our expectations…