Carlos Sosa

Yes, I’ve migrated my blog framework again. After several migrations, there’s finally a web framework that works for me. It’s called Dancer, and as redundant as this might sound; Dancer, is an effortless web framework.

Last year, I started writing my own mini-blog engine with several modules from CPAN; however, the engine became complicated and robust. Processing different tasks with more than 5 modules, I was calling more objects than actually outputting any useful data. I’ve known about Dancer since its early development, but never expected to run in my VPS hosting, NearlyFreeSpeech.

*How does it work*
Dancer works like Sinatra for Ruby. Just like Sinatra, Dancer works with routes. I like to call them, dance moves.

*For every request, there’s a dance move…*
A route is an HTTP request with an URL pattern. For every request, there is an associated block of code that will handle a task in your web-app.

Simple example:\\

#!/usr/bin/env perl
use Dancer;

get '/' => sub {
    ...do something
    ...display something
    ...call something
};

dance;

Working example:\\

#!/usr/bin/env perl
use Dancer;

get '/feed/:format' => sub {
    my $db = connect_db();
    my $sth = $db->prepare($sql) or
        die $db->errstr;
    $sth->execute or die $sth->errstr;
    my $feed = create_feed(
        format  => params->{format},
        entries => _get_entries(
                $sth->fetchall_arrayref({}))
                );
    $sth->finish();
    return $feed;
};

dance;

To sum it up, the first example shows the structure of a route. The second, shows a working example of my mini-blog engine feed request. To get the working example, there has to be a request to http://log.gnusosa.net/feed/rss or http://log.gnusosa.net/feed/atom; which ever is the case, the route will display the desired feed format.

It took me more time studying Dancer’s features and specs, than the time it took for me to write the whole mini-blog app. In my case, my runtime errors were caused by external modules. Debugging was an easy task thanks to the logs generated by the Dancer core, and the error message from Dancer’s development environment. By the time, I finished writing the main routes, there were several examples on how to deploy the web-app in a CGI environment.

*An environment becomes a dance floor…*
Dancer comes with a standalone development server, that can bring up your apps at http://127.0.0.0:3000/ . This is a handy feature that helps to develop without a testing server, that way your focus stays on building the web-app, instead, of focusing on transferring files.

Easy as running:
#+begin_src sh $ cd App $ perl bin/app.pl >> Dancer server 16222 listening on http://0.0.0.0:3000 == Entering the development dance floor …

#+end_src

Like most recent Web frameworks for Perl, Dancer supports Plack/PSGI, and work together as a built-in script that deploys the web-app in any webserver.

*In the dance floor…*
Dancer is known to be fast, and minimalistic. PSGI compatible, Dancer can be deployed in any recent webserver, including, the dominant Apache. I’ve seen several instances of Dancer using Nginx, Lighttpd, and even Apache with mod_proxy. However, many people don’t recommend robust web-apps in a CGI deployment, and mid-size apps in Fast-CGI. Many add to this discussion that Dancer is capable of handling robust, complicated, and resourceful web apps. I subscribe to that idea; with a good webserver in a fast enviroment like Fast-CGI or in a lean webserver like Nginx, Dancer can show its moves.

To get a better idea of the cases in which Dancer can be opted for, there is the Dancer::Cookbook, and the Dancer Advent Calendar. For big projects, there is always Mojolicious.

This log was made with Dancer, and is deployed in a CGI enviroment on Apache in a VPS webserver.