Mojolicious In Conversation With Sebastian Riedel
Written by Nikos Vaggalis   
Thursday, 11 December 2014

Our journey into the world of Perl's Web frameworks would not be complete without Mojolicious. So Nikos Vaggalis talked to Sebastian Riedel, Mojolicious mastermind and the original founder of Catalyst.

 

 mojsebastianriedel

 

The conversation ranged over the history of Mojolicious; its present status  and the project's future. We also get more technical with questions like why not opt for a DSL like Dancer does; what is meant by real time web framework; whether the framework is dependency free and much more.

 

NV: Do you think that now with Mojolicious, Catalyst and Dancer we are experiencing Perl's most successful Web revolution since the 90s?

SR: It's certainly a great time for web development with Perl, and it has been a lot of fun seeing Catalyst and Mojolicious take the Perl community by storm. But for a real revolution, along the lines of CGI.pm in the late 90s, I think we have to get a lot better at reaching people outside the echo chamber, which is not really a technical, but a public relations problem.

NV: There are many web frameworks out there each one targeting various areas of web development. Which ones does Mojolicious address and how does it compare to Dancer and Catalyst?

SR: There was a time when I would jump at every opportunity to learn more about all the different web frameworks out there, searching for inspiration. But these days there's actually very little innovation happening, almost all server-side frameworks follow the same basic formula. Some are trying to optimize for projects of a certain size, but it's mostly just programming languages competing now.

So I only really pay attention to the very small number that are still experimenting with different architectures and technologies, usually written in languages other than Perl. Some recent examples would be Meteor (JavaScript) and Play Framework (Scala).

What's really important to me with Mojolicious, and what I believe really differentiates it from everything else in Perl, is that we are always trying new things. Like we've done with tight integration of WebSockets and event loops, or the ability to grow from single-file prototypes to well structured web applications.

 

NV: What does the term "real time web framework" refer to? Is the the facility for WebSockets, non-blocking I/O and event loops? Can you walk us through these concepts? Do such features make Mojolicious a prime platform for building Web APIs?

SR: The real-time web is simply a collection of technologies that allow content to be pushed to consumers with long-lived connections, as soon as it is generated. One of these technologies is the WebSocket protocol, offering full bi-directional low-latency communication channels between the browser and your web server.

I'm not actually a big fan of non-blocking I/O and event loops, but they are the tools that allow us to scale. So a single WebSocket server process can handle thousands of connections concurrently. Sounds rather complicated, doesn't it? But with Mojolicious all you need are these 9 lines of Perl code, and you have a fully functioning real-time web application:

use Mojolicious::Lite;
  use 5.20.0;
  use experimental 'signatures';

  websocket '/echo' => sub ($c) {
    $c->on(message => sub ($c, $msg) {
       $c->send("echo: $msg");
    });
};

app->start;

 

You tell me if this makes Mojolicious a prime platform for building Web APIs!

 

NV: Does the dependency free nature of Mojolicious act as an invitation to people familiar with other frameworks, such as Ruby on Rails, and languages like PHP? That aside, what other factors/features would lure such developers to the framework?

SR: The dependency free nature of Mojolicious is actually something of a myth. The truth is that installing Mojolicious is simply a very fast and pleasant experience.

One of the ways in which we've done this, is to make hard to install 3rd party modules like IO::Socket::SSL and Net::DNS::Native optional.

I think what makes Mojolicious special is best explained with an example application:

use Mojolicious::Lite;

use 5.20.0;
use experimental 'signatures';

   # Render template "index.html.ep"
   # from the DATA section 

   get '/' => {template => 'index'};
# WebSocket service used by the template
# to extract the title from a web site
   websocket '/title' => sub ($c) {
     $c->on(message => sub ($c, $msg) {
        my $title = $c->ua->get($msg)->
                 res->dom->at('title')->text;
        $c->send($title);
    });
  };
  app->start;
  __DATA__
  @@ index.html.ep
  % my $url = url_for 'title';
  <script>
     var ws = new WebSocket(
                  '<%= $url->to_abs %>');
     ws.onmessage = function (event) {    
      document.body.innerHTML += event.data };
     ws.onopen = function (event) {
      ws.send('http://mojolicio.us') };
  </script>

 

This is actually the first example application you encounter on our website (http://mojolicio.us). It doesn't look very complicated at all. But once you start digging a little deeper, you'll quickly realize how crazy (in a good way) it really is, and how hard it would be to replicate with any other web framework, in any language.

To give you a very quick summary:

  1. There's an EP (Embedded Perl) template, in the DATA section of a single-file web application. That template generates an HTML file, containing JavaScript, which opens a WebSocket connection, to a dynamically generated URL (ws://127.0.0.1:3000/title), based on the name of a route.

  2. It then sends another URL (http://mojolicio.us) through the WebSocket as a text message, which results in a message event being emitted by the server.

  3. Our server then uses a full featured HTTP user agent, to issue a GET request to this URL, and uses an HTML DOM parser to extract the title from the resulting document with CSS selectors.

  4. Before finally returning it through the WebSocket to the browser, which then displays it in the body of our original HTML file.

Next year at Mojoconf 2015, I'll be giving a whole talk about this one application, exploring it in much greater detail.

 

NV: It's a framework that you use in pure Perl. Why not go for a DSL like Dancer does?

SR: There are actually two kinds of web framework DSLs, and they differ by scope.First, you have your routing DSL, which usually runs during server start-up and modifies application state. (application scope):

get '/foo' => sub {...};

Second, there is what I would call the content generation DSL, which modifies request/response state (request scope):

get '/foo' => sub {
  header 'Content-Type' => 'text/plain';
  render 'some_template';

};

Mojolicious does have the first kind, and we've already used it in the examples above, but not the second. And the reason for this, is that the second kind does not work very well, when you plan on handling multiple requests concurrently in the same process, which involves a lot of context switching. It's a trade-off between making your framework more approachable for beginners, that might not know Object-Oriented Perl yet, and supporting modern real-time web features.

NV: What can we expect in the future and what is the greater vision for the project's evolution?

SR: Mojolicious has an amazing community, and I hope we can expand on that to reach more people from outside the Perl community in the future. Not a day goes by where I don't receive requests for a Mojolicious book, so that's a pretty big priority too.

Feature wise, with the release of the final RFC, I expect HTTP/2 to be a very big topic in 2015.And hopefully we will get to play more with new Perl features such as signatures, I can't wait for a polyfill CPAN module to bring signatures to older versions of Perl.

 

 mojo

 

A version of this conversation originally appeared as a two-part series on the JosetteORama blog.

 

Other Perl-related interviews by Nikos Vagallis:

All About Dancer - In Conversation With Sawyer X

Catalyst And More - An Interview With Matt Trout

Where is Perl Heading? Interview with Jonathan Worthington

Banner

To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, FacebookGoogle+ or Linkedin,  or sign up for our weekly newsletter.

 

kotlin book

 

Comments




or email your comment to: comments@i-programmer.info

Last Updated ( Monday, 25 July 2016 )