What Happens After You Start Your Mojolicious 'app'

Tags:

Please note, THIS IS A WORK IN PROGRESS, not a final article.

First let's look at the skeleton version of the main script that gets created when you execute "mojo generate app Foo" − this is foo/script/foo −

#!/usr/bin/env perl

use strict;
use warnings;

use lib 'lib';

# Start command line interface for application
require Mojolicious::Commands;
Mojolicious::Commands->start_app('Foo');

what Mojolicious::Commands does:

enables all the processing for Mojolicious commands like daemon, get, generate, *routes, test, *etc.

Then we do Mojolicious::Commands->start_app('Foo') which:

handles all the switches and arguments in the invocation command-line
Loads the application class (here, lib/Foo.pm)
Calls the application

The source for start_app (in Mojolicious/Commands.pm) looks like this:

sub start_app {
  shift;
  Mojo::Server->new
    ->build_app(shift)
      ->start(@_)
}

This calls the new() method of Mojo::Server to create a Mojo server object (and subscribe to the "request" event with default request handling); the server object is returned and upon that we call build_app(). The argument to build_app will in this example be "Foo" which is the name of the application class for which we are building an instance.

→ Q: What does it mean, subscribe to the request event?

Then the call to start() runs as shown in Mojolicious.pm, namely by invoking the commands() and run() methods of Mojolicious, which have the effect of processing any commands and then running the event loop.

The only other code, aside from a stock Controller, is in lib/Foo.pm:

package Foo;
use Mojo::Base 'Mojolicious';

# This method will run once at server start
sub startup {
  my $self = shift;

  # Documentation browser under "/perldoc"
  $self->plugin('PODRenderer');

  # Router
  my $r = $self->routes;

  # Normal route to controller
  $r->get('/')->to('example#welcome');
}

What's going on here?

the argument is the 'app' (instance of _ class) that _ creates

From this we can call built-ins like plugin() and routes()

−−

https://en.wikipedia.org/wiki/Event-driven_architecture

from http://mojolicio.us/perldoc/Mojolicious/Guides/FAQ#What-is-an-event-loop

An event loop is basically a loop that continually tests for external events and executes the appropriate callbacks to handle them, it is often the main loop in a program. Non-blocking tests for readability/writability of file descriptors and timers are commonly used events for highly scalable network servers, because they allow a single process to handle thousands of client connections concurrently.

Set up all the routes, timers, and other reactions to be processed by the event engine.
The script calls app->start (for Lite) or −−− (for Mojolicious)
Event loop runs − Mojo::IOLoop (detail?)

from http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Timers

Timers, another primary feature of the event loop, are created with

[

"timer" in Mojo::IOLoop ](http://mojolicio.us/perldoc/Mojo/IOLoop#timer) and can for example be used to delay rendering of a response, and unlike sleep , won't block any other requests that might be processed concurrently… Recurring timers created with "recurring" in Mojo::IOLoop are slightly more powerful, but need to be stopped manually, or they would just keep getting emitted.

from http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Exceptions-in-events

Since timers and other non-blocking operations are running solely in the event loop, outside of the application, exceptions that get thrown in callbacks can't get caught and handled automatically. But you can handle them manually by subscribing to the event

[

"error" in Mojo::Reactor ](http://mojolicio.us/perldoc/Mojo/Reactor#error) or catching them inside the callback.