Moving web code base from Catalyst to Mojolicious

Its a long story. For those who don’t know, Catalyst is a Perl based web framework. So is Mojolicious. The person who started developing Catalyst years ago, left that group, and started Mojolicious later on. I like many things about Catalyst. Like other MVC frameworks, it lets you divide up your logic between controllers (the heavy lifters), the model (aka the database), and the display logic. Prior to this, I wrote some rather ugly looking code which combined controllers and display logic. I usually punted on the model, as I rarely needed anything more complex than a simple database at best. My main problem with Catalyst has always been its dependency radius (e.g. how much additional crap you have to install to run/maintain your code). I liked using it, but installing it was … well … a challenge. Especially due to the dependency tree including a number of hopelessly broken modules, specifically anything that matchs the regex /WWW::Mechanize/ has failed to build/test/install cleanly on every machine I’ve tried (all OSes I’ve tried, many different Perl’s). Some of Catalyst’s controllers have this module as a hard dependency … which I never liked … and thus caused updates and upgrades to fail. But it got worse.

In April this year I showed off a speedometer for Bandwidth and IOPs at HPC on Wall Street on some of our hardware. That was a Catalyst app. Ok, it was an Ajaxified Javascript unit which was implemented in a Catalyst app. I was planning on using the same thing at SC11. I had updated Catalyst since then. I was using Mojolicious by then … there is a critical component of Tiburon which is Mojolicious based. More on that in a moment. Path of least resistance. Install Catalyst on the siFlash. Install the application. And voila. Too bad about a few things. Like Catalyst is, of course, under very active development. And the bits I had working in April? Incompatible with the new drop of Catalyst. Yeah. Thats what I said too. I had a few options, tried installing the monitoring portion on siFlash. That worked (see previous post). But I ran into some browser caching issue (that I still don’t grok) that allowed me a single measurement then no more. Ok. What about lifting the display code out of Catalyst and building a Mojolicious page on our monitoring/control dashboard? The display logic was using the Mason template engine. This lets you compile templates to executable code and display code, which enables you to build very powerful display logic. So I did this. And I had it working inside of about 30 minutes. To install Mojolicious, a quick sudo cpan Mojolicious Is all you need. Its fast, and everything just works. Did I mention that it just works? The latest Catalyst is built around Moose. It wasn’t when we started using Catalyst about 5 years ago. Moose is an object system (Perl’s objects not integrated into the language so you get only one object system … they are Perl Modules such that you can literally pick and choose what you want/need, and you can use multiple object systems at once … this might not be a benefit for some folks, but the flexibility is very good). But Moose is big. And slow. And this doesn’t help Catalyst. And it adds dependencies. Catalyst is a good system. Don’t get me wrong. Its just got so many dependencies that it makes itself effectively impossible to deploy in the field for us. It makes it very hard to support. There are so many moving parts. Another project I liked, and especially like their Database tools, is Jifty. Jifty is almost exactly what I wanted when I started working on this stuff. But their dependency radius was absolutely gargantuan relative to Catalyst, which itself was huge compared to other codes. I chose Catalyst over Jifty because of that. As I could not be assured I had a working environment. Early versions of Catalyst, I was pretty sure I had a working environment. DragonFly is a Catalyst application. Well, I’ve now written quite a number of things in Mojolicious. And its very … very easy to write stuff that works, correctly, the first time, in Mojolicious, without dealing with many moving parts demanding their square meter of skin. I understand there is a similar structure code for Python. Here is a very simple code to return the time #!/usr/bin/env perl use Mojolicious::Lite; get '/time' => 'clock'; app->start; __DATA__ @@ clock.html.ep % my ($second, $minute, $hour) = (localtime(time))[0, 1, 2]; < %= link_to clock => begin %> The time is < %= $hour %>:< %= $minute %>:< %= $second %>. < % end %> and starting it in one window

landman@lightning:~$ ./timetest.pl daemon
[Sat Dec  3 22:25:32 2011] [info] Server listening (http://*:3000)
Server available at http://127.0.0.1:3000.

while querying it ….

<code>
landman@lightning:~$ lynx -source http://localhost:3000/time
<a href="/time">
    The time is 22:25:39
</a>
</code>

Yeah, this makes life pretty easy. So, we are going to be moving our web kit over to this. The other very nice thing we can do with this, that I’ve never been able to do with Catalyst is to run it in a debugger. Like the excellent Komodo from ActiveState. The example above is a bit contrived. But its notable for how easy it is to put together, test, run, and debug. And maintaining Mojolicious over the last year? I have code I started writing at the 0.9x phase that is working fine at the 2.35 rev. Thats why we are moving. Catalyst isn’t bad at all, its just too much for us. Mojolicious is just right. It coupled with Mason, and some nice Ajaxified display logic make for a pretty powerful set of tools for building things.