It's not uncommon lately for startup companies utilizing RIA technologies to delivery their ideas and services. Adobe Flex based startup Babbel is one good example. To allow our readers learn the insight on how a Flex startup's architecture is designed and implemented, InfoQ spoke with Thomas Holl, CTO of Lesson Nine GmbH, the company behind Babbel.
First, Holl described what Babbel is:
Babbel is a community-based, online language-learning tool. With courses in German, English, French, Italian and Spanish, Babbel.com blends the pleasures of social networking with playful but effective vocabulary-developing and sentence-building tools.
Then, he answered the question on the reasons of creating Babbel:
In late 2006, when we were looking for a modern online language learning tool ourselves, we were amazed that nothing like Babbel existed. It seems the situation is only beginning to change now. But back then, available online vocabulary trainers were pretty basic and not very user-friendly, and multimedia applications you could buy on CD-ROM or DVD were not only expensive but also often out-of-date in terms of content and technology. Learning games on consoles became a kind of role model for the Babbel concept -- these simple applications are fun to use and also vastly popular.
On Flex vs AJAX Holl explained:
It was clear from the start that our site should make use of modern multimedia possibilities such as playing sounds, animations and buffering data in the background for faster reponse times. As of last year, there simply wasn't an alternative to the Flex framework that seemed suitable for the vision we have for Babbel. We might have been able to do a lot of the things in AJAX, but then there would have been a lot of JavaScript libraries to handle and still the user experience could not compare with a Flash application.
For the interest of learning technical details on how Babble was developed, Holl shared:
We've been working with 4 developers on Babbel - 2 of them focusing on the Flex client and 2 developing the Ruby On Rails based backend running on Amazon EC2 instances. We were starting from scratch in May 2007, so development time to the first public version in January 2008 was about 8 months.
The server consists of 12K lines of Ruby code, the Flex client is about 50K LOC (including 7K lines of generated integration code).
We're following an iterative development process - and found out that a length of one week seems to work best for us. Besides that, we're using best practice tools and processes, e.g. Subversion for version control, Trac for defect tracking/documentation/communication, automated builds/deployment via Ant/Capistrano, etc.
Holl also shared with us the challenges they encountered during the Babbel development:
To access the backend services from the client, we started to describe the services with a simple definition language (think of WSDL, but based on JSON and much simpler). Our generator then turns these definitions into ActionScript methods, the data returned from the service (via JSON over HTTP) is then accessible to the client via statically typed Value Objects (the classes are also generated). For some functionality however (e.g. the "people search") marshalling the data this way didn't seem the right way to go - writing code to dynamically create the GUI elements is just wasteful. We wanted to leverage the ability of Rails to generate HTML on the fly. Since displaying HTML in Flex is severely limited regarding the supported HTML elements and styles, we now generate MXML with Rails and display it in the client. Via this way the server can also trigger actions in the client (e.g. a new message arrived and the client should display a notification).
On specific RIA related technical and architecture issues, Holl recalled:
Another topic that pops up from time to time is how much state the client can and should have. This took us several rounds of improving and testing to find the right balance for Babbel. Client relevant changes on the server side are signaled to the client in the result of the next client request (so there is no need for a push architecture) and then the client decides on its own when to synchronize with the server.
What technologies will help Babbel in the future:
We will push our language learning tools quite a lot further towards a game-like user experience. One of the next big goals is to integrate audio and video chat capabilities and there are some exciting possibilities within the Adobe ecosystem we're evaluating right now. Then there is a host of functionality in terms of networking and community features we want to add. Also the content management for our in-house team as well as the possibilities four our users to contribute have to be vastly expended. We also want to bring Babbel to the mobile world, so that probably means J2ME, Symbian or iPhone development.