WebROaR http://webroar.in/, a Ruby web application server designed to support Rails and Rack based applications recently came to my attention. My currently preferred Rails stack is Apache2 http://httpd.apache.org/, Ruby Enterprise 1.87 http://www.rubyenterpriseedition.com/, and Passenger http://www.modrails.com/, using NewRelic RPM http://www.newrelic.com/features.html for notifications and metrics. I wanted to see how WebROaR stacked up as a replacement.
I began my investigation the way I do any application. I start by writing an installation script. My tool of choice for deployments right now is Capistrano http://www.capify.org, and I've recently been interested in Deprec http://deprec.failmode.com/, a framework of recipes built on top of Capistrano specifically designed to install on ubuntu, which by chance, is also my preferred linux distribution. So I decided to extend Deprec with a WebROaR installation recipe. WebROaR began showing it's relative youth immediately. I expect to be able to install a production application non-interactively. That is to say, I should be able to script the entire affair by passing values to the installer, configure, and make scripts via the command line. The current version of WebROaR's install will prompt you for up to four different values and provides no mechanism to create a non-interactive install.With Capistrano a non-interactive install can be worked around by examining output and responding as a user would with stored answers. Other deployment systems based on shell scripts will find installing WebROaR challenging.The next issue to deal with is provisioning the application. There was no mechanism, save rewriting the entire configuration file, to create a new application from Capistrano. For this reason I left any configuration of the server or applications out of the deprec recipe.The problem with re-creating the entire configuration via Capistrano is a simple one, when you install an application with Capistrano it doesn't normally have any concept of any other applications that may be hosted by your server. So a rewrite of the entire config would end up wiping out all other applications unless pains were taken to make it tolerant.Another sign that WebROaR is fairly young is that when I deployed a simple test application, the deploy scripts hadn't properly used the bundle command to unpack all of the application's dependent gems. It left the application in a really sorry state. WebROaR's user interface didn't expose the error condition, nor was it able to serve the configured application. It wasn't until I connected to the box via ssh and tried to run script/server in the applications deploy folder before I got any clue as to what the problem might be. WebROaR should have done what it could to raise the problem to my attention within its exceptions section. I dealt with several errors where the WebROaR UI wasn't any help which gives me the impression there are many areas where WebROaR is rough around the reliability edges.It's great that WebROaR's concept is built around interactive management, Apache, Passenger, Mongrel, and Thin don't really provide any instrumentation without something like NewRelic's RPM.The exception reporting was definately useful, and presented nicely, if not exactly timely. After triggering a few errors it still took several refreshes of WebROaR's UI before the information was ready to be examined. Similarly there was a delay from when the first requests were generated before the graphs in the analytics could be reviewed.Things like email and sms notifications are not in the product yet. I would have expected the ability to automatically send notifications and have some control over the process when metrics go above or beyond certain thresholds, or when certain types of exceptions occur.The admin interface is protected by only a single username and password, multiple users aren't possible. Obviously role based access controls aren't in the product yet either.The documentation is rather good for what features there are. But there aren't that many features. I didn't do any kind of exhaustive performance benchmarks or stress tests because my curiosity had already been sated by getting my test application up. WebROaR doesn't compare to the configurability, stability, and breadth of options that I could even remotely consider it as a replacement for my current Rails Stack, even if all of it's claims about performance are true.If it's going to become a production ready application, it's going to have to make it effecient for sysadmins to install and manage it from the command line and report error conditions better. I can absolutely see it's alure to hosting companies as a great way to host rails apps if they can delegate control to end users and use an API to control the configuration. The project is very young, announced November 25th, 2009 according to their Blog, and it's incredibly promising, I'll definately check it out again when they get near a 1.0 release.Deprec WebROaR recipe: http://github.com/donnoman/deprec/blob/2cdac7ed5c322d41512673a2e199707b3e47de...Related changes to deprec: http://github.com/donnoman/deprec/commit/2cdac7ed5c322d41512673a2e199707b3e47...Any fixes will be comitted here: http://github.com/donnoman/deprec/tree/webroarSample App Deploy Script using webroar: http://github.com/donnoman/flitten_deploy/commit/76e0ae350d75127fb43e7cc181f0...
