Chouette
view release on metacpan or search on metacpan
lib/Chouette.pm view on Meta::CPAN
my $route_params = \%+;
my $methods = $self->{route_patterns}->{ $self->{route_regexp_assemble}->source($^R) };
my $method = $c->{env}->{REQUEST_METHOD};
my $func = $methods->{$method};
die "405: Method Not Allowed" if !$func;
$c->{route_params} = $route_params;
$func->($c);
}
sub generate_token {
state $generator = Session::Token->new;
return $generator->get;
}
1;
__END__
=encoding utf-8
=head1 NAME
Chouette - REST API Framework
=head1 DESCRIPTION
L<Chouette> is a framework for making asynchronous HTTP services. It makes some opinionated design choices, but is otherwise fairly flexible.
L<AnyEvent> is used as the glue to connect all the asynchronous libraries, although Chouette depends on L<Feersum> and therefore L<EV> for its event loop. It uses L<Feersum> in PSGI mode so it can use L<Plack> for request parsing, and has support for...
Chouette generally assumes that its input will be C<application/x-www-form-urlencoded>. L<Plack::Request::WithEncoding> is used so that text is properly decoded (we recommend UTF-8 of course). For output, the default is C<application/json> encoded wi...
Chouette apps can optionally load a config file and its format is C<YAML>, loaded with the L<YAML> module. L<Regexp::Assemble> is used for efficient route-dispatch.
The above aside, Chouette's main purpose is to glue together several of my own modules into a cohesive whole. These modules have been designed to work together and I have used them to build numerous services, some of which handle a considerable amoun...
Chouette was extracted from some of these services I have built before, and I have put in the extra effort required so that all the modules work together in the ways they were designed:
=over
=item L<AnyEvent::Task>
Allows us to perform blocking operations without holding up other requests.
=item L<Callback::Frame>
Makes exception handling simple and convenient. You can C<die> anywhere and it will only affect the request being currently handled.
Important note: If you are using 3rd-party libraries that accept callbacks, please understand how L<Callback::Frame> works. You will usually need to pass C<fub {}> instead of C<sub {}> to these libraries. See the L<EXCEPTIONS> section for more detail...
=item L<Session::Token>
For random identifiers such as session tokens (obviously).
=item L<Log::Defer>
Structured logging, properly integrated with L<AnyEvent::Task> so your tasks can log messages into the proper request log contexts.
Note that Chouette also depends on L<Log::Defer::Viz> so C<log-defer-viz> will be available for viewing logs.
=item L<Log::File::Rolling>
Store logs in files and rotate them periodically. Also maintains a current symlink so you can simply run the following in a shell and you'll always see the latest logs as you need them:
$ log-defer-viz -F /var/myapi/logs/myapi.current.log
=back
Chouette will always depend on L<AnyEvent::Task>, L<Callback::Frame>, L<Session::Token>, and L<Log::Defer> so if your app also uses these modules then it is sufficient to depend on C<Chouette> alone.
Where does the name "Chouette" come from? A L<chouette|http://www.bkgm.com/variants/Chouette.html> is a multi-player, fast-paced backgammon game with lots of stuff going on at once, kind of like an asynchronous REST API server... Hmmm, a bit of a str...
=head1 CHOUETTE OBJECT
To start a server, create a C<Chouette> object. The constructor accepts a hash ref with the following parameters. Most are optional. See the C<bin/myapi> file below for a full example.
=over
=item C<config_defaults>
This hash is where you provide default config values. These values can be overridden by the config file.
You can use the config store for values specific to your application (it is accessible with the C<config> method of the context), but here are the values that C<Chouette> itself looks for:
C<var_dir> - This directory must exist and be writable. C<Chouette> will use this to store log files and L<AnyEvent::Task> sockets.
C<listen> - This is the location the Chouette server will listen on. Examples: C<8080> C<127.0.0.1:8080> C<unix:/var/myapi/myapi.socket>
C<logging.file_prefix> - The prefix for log file names (default is C<app>).
C<logging.timezone> - Either C<gmtime> or C<localtime> (C<gmtime> is default, see L<Log::File::Rolling>).
The only required config parameters are C<var_dir> and C<listen> (though these can be omitted from the defaults assuming they will be specified in the config file, see below).
=item C<config_file>
If you want a config file, this path is where it will be read from. The file's format is L<YAML>. The values in this file over-ride the values in C<config_defaults>. If this parameter is not provided then it will not attempt to load a config file and...
=item C<routes>
Routes are specified as a hash-ref of route paths, mapping to hash-refs of methods, mapping to package+function names or callbacks. For example:
routes => {
'/myapi/resource' => {
POST => 'MyAPI::Resource::create',
GET => 'MyAPI::Resource::get_all',
},
'/myapi/resource/:resource_id' => {
GET => 'MyAPI::Resource::get_by_id',
POST => sub {
my $c = shift;
die "400: can't update ID " . $c->route_params->{resource_id};
},
},
'/myapi/upload' => {
PUT => 'MyAPI::Upload::upload',
}
},
For each route, if a package+function name is used it will try to C<require> the package specified, and obtain the function specified for each HTTP method. If the package or function doesn't exists, an error will be thrown.
You can use C<:param> path elements in your routes to extract parameters from the path. They are accessible via the C<route_params> method of the context (see C<lib/MyAPI/Resource.pm> below).
Note that routes are combined with L<Regexp::Assemble> so we don't have to loop over every possible route for every request, in case you have a lot of routes. For example, here is the regexp used for the above routes:
\A/myapi/(?:resource(?:/(?<resource_id>[^/]+)\z(?{2})|\z(?{1}))|upload\z(?{0}))
See the C<bin/myapi> file below for an example.
=item C<pre_route>
A package+function or callback that will be called with a context and a resume callback. If the function determines the request processing should continue, it should call the resume callback.
See the C<lib/MyAPI/Auth.pm> file below for an example of the function.
=item C<middleware>
Any array-ref of L<Plack::Middleware> packages. Each element is either a string representing a package+function, or an array-ref where the first element is the package+function and the rest of the elements are the arguments to the middleware.
The strings representing packages can either be prefixed with C<Plack::Middleware::> or not. If not, it will try to C<require> the package as is and if that doesn't exist, it will try again with the C<Plack::Middleware::> prefix.
middleware => [
'Plack::Middleware::ContentLength',
'ETag',
['Plack::Middleware::CrossOrigin', origins => '*'],
],
=item C<tasks>
This is a hash-ref of L<AnyEvent::Task> servers/clients to create.
tasks => {
db => {
pkg => 'LPAPI::Task::DB',
checkout_caching => 1,
client => {
timeout => 20,
},
server => {
lib/Chouette.pm view on Meta::CPAN
Follow log messages:
log-defer-viz -F /var/myapi/logs/myapi.current.log
===============================================================================
=back
After the C<Chouette> object is obtained, you should call C<serve> or C<run>. They are basically the same except C<serve> returns whereas C<run> enters the L<AnyEvent> event loop. These are equivalent:
$chouette->run;
and
$chouette->serve;
AE::cv->recv;
=head1 CONTEXT OBJECT
For every request a C<Chouette::Context> object is created. This object is passed into the handler for the request. Typically we name the object C<$c>. Your code interacts with the request via the following methods on the context object:
=over
=item C<respond>
The respond method sends a JSON response, the contents of which are encoded from the first argument:
$c->respond({ a => 1, b => 2, });
Note: After responding, this method returns and your code continues. This is useful if you wish to do additional work after sending the response. However, if you call C<respond> on this context again an error will logged. The second response will not...
If you wish to stop processing after sending the response, you can C<die> with the result from C<respond> since it returns a special object for this purpose:
die $c->respond({ a => 1, });
See the L<EXCEPTIONS> section for more details on the use of exceptions in Chouette.
C<respond> takes an optional second argument which is the HTTP response code (defaults to 200):
$c->respond({ error => "access denied" }, 403);
Note that processing continues here also. If you wish to terminate the processing right away, prefix with C<die> as above, or use the following shortcut:
die "403: access denied";
The client will receive an HTTP response with the L<Feersum> default message ("Forbidden" in this case) and the JSON body will be C<{"error":"access denied"}>.
This works too, except the value of C<error> in the JSON body of the response will just be "HTTP code 403":
die 403;
=item C<done>
If you wish to stop processing but not send a response:
$c->done;
You will need to send a response later, usually from an async callback. Note: If the last reference to the context is destroyed without a response being sent, the message C<no response was sent, sending 500> will be logged and a 500 "internal server ...
You don't ever need to call C<done>. You can just C<return> from the handler instead. C<done> is only for convenience in case you are deeply nested in callbacks and don't want to worry about writing a bunch of nested returns.
=item C<respond_raw>
Similar to C<respond> except it doesn't assume JSON encoding:
$c->respond_raw(200, 'text/plain', 'here is some plain text');
=item C<logger>
Returns the L<Log::Defer> object associated with the request:
$c->logger->info("some stuff is happening");
{
my $timer = $c->logger->timer('doing big_computation');
big_computation();
}
See the L<Log::Defer> docs for more details. For viewing the log messages, check out L<Log::Defer::Viz>.
=item C<config>
Returns the C<config> hash. See the L<CHOUETTE OBJECT> section for details.
=item C<req>
Returns the L<Plack::Request> object created for this request.
my $name = $c->req->parameters->{name};
=item C<res>
One would think this would return a L<Plack::Response> object. Unfortunately this isn't yet implemented and will instead throw an error.
=item C<generate_token>
Generates a random string using a default-config L<Session::Token> generator. The generator is created when the first token is needed so as to avoid a "cold" entropy pool immediately after a reboot (see the L<Session::Token> docs).
=item C<task>
Returns an L<AnyEvent::Task> checkout object for the task with the given name:
$c->task('db')->selectrow_hashref(q{ SELECT * FROM sometable WHERE id = ? },
undef, $id, sub {
my ($dbh, $row) = @_;
die $c->respond($row);
});
Checkout options can be passed after the task name:
$c->task('db', timeout => 5)->selectrow_hashref(...);
See L<AnyEvent::Task> for more details.
=back
=head1 EXCEPTIONS
Assuming you are familiar with asynchronous programming, most of L<Chouette> should feel straightforward. The only thing that might be unfamiliar is how exceptions are used.
=head2 ERROR HANDLING
The first unusual thing about how Chouette uses exceptions is that it uses them for error conditions, in contrast to many other asynchronous frameworks.
Most asynchronous frameworks are unable to use exceptions to signal errors since an error may occur in a callback being run from the event loop. If this callback throws an exception, there will be nothing to catch it, except perhaps a catch block ins...
Consider the L<AnyEvent::DBI> library. This is how its error handling works:
$dbh->exec("SELECT * FROM no_such_table", sub {
my ($dbh, $rows, $rv) = @_;
if ($#_) {
# success
} else {
# failure. error message is in $@
}
});
Even if C<exec> failed, the callback still gets called. Whether or not it succeeded is indicated by its parameters. You can think of this as a sort of "in-band" signalling. The fact that there was an error, and what exactly that error was, needs to b...
But with both of these methods, what should the callback do when it is notified of an error? It can't just C<die> because nothing will catch the exception. With the L<EV> event loop you will see this:
EV: error in callback (ignoring): failure: ERROR: relation "no_such_table" does not exist
Even if you wrap an C<eval> or a L<Try::Tiny> C<try {} catch {}> around the code the same thing happens. The try/catch is in effect while installing the callback, but not when the callback is called.
As a consequence of all this, asynchronous web frameworks usually cannot indicate errors with exceptions. Instead, they require you to respond to the client from inside the callback:
$dbh->exec("SELECT * FROM no_such_table", sub {
my ($dbh, $rows, $rv) = @_;
if (!$#_) {
$context->respond_500_error("DB error: $@");
return;
}
# success
});
There are several down-sides to this approach:
=over
=item *
The error must be handled locally in each callback, rather than once in a catch-all error handler.
=item *
Everywhere an error might occur needs to have access to the context object. This often requires passing it as an argument around everywhere.
=item *
You might forget to handle an error (or it might be too inconvenient so you don't bother) and your success-case code will run on garbage data.
=item *
Perhaps most importantly, if some unexpected exception is thrown by your callback (or something that it calls) then the event loop will receive an exception and nothing will get logged or replied to.
=back
For these reasons, Chouette uses L<Callback::Frame> to deal with exceptions. The idea is that the exception handling code is carried around with your callbacks. For instance, this is how you would accomplish the same thing with Chouette:
my $dbh = $c->task('db');
$dbh->selectrow_arrayref("SELECT * FROM no_such_table", undef, sub {
my ($dbh, $rows) = @_;
# success
# Even if I can die here and it will get routed to the right request!
});
The callback will only be invoked in the success case. If a failure occurs, an exception will be raised in the dynamic scope that was in effect when the callback was installed. Because Chouette installs a C<catch> handler for each request, an appropr...
Important note: Libraries like L<AnyEvent::Task> (which is what C<task> in the above example uses) are L<Callback::Frame>-aware. This means that you can pass C<sub {}> callbacks into them and they will automatically convert them to C<fub {}> callback...
When using 3rd-party libraries, you must pass C<fub {}> instead. Also, you'll need to figure out how the library handles error cases, and throw exceptions as appropriate. For example, if you really wanted to use L<AnyEvent::DBI> (even though the L<An...
$dbh->exec("SELECT * FROM no_such_table", fub {
my ($dbh, $rows, $rv) = @_;
if (!$#_) {
die "DB error: $@";
}
# success
});
Note that the C<sub> has been changed to C<fub> and an exception is thrown for the error case.
In summary, when installing callbacks you must use C<fub> except when the library is L<Callback::Frame>-aware.
Please see the L<Callback::Frame> documentation for more specifics.
=head2 CONTROL FLOW
The other unusual thing about how Chouette uses exceptions is that it uses them for control flow as well as errors.
As you can see in the C<respond> method documentation of the L<CHOUETTE OBJECT> section, you can C<die> with the result of the C<respond> method:
die $c->respond({ status => 'ok' });
This works because C<respond> returns a special object specifically intended for this purpose. When it gets an exception, the main catch block checks if it is this object. If so, it just ignores the exception. This lets you terminate your current cal...
This catch block also checks if your exception starts with 3 digits followed by a word-break. If so, it considers this a special exception intended to send an HTTP response. For example, the following code will send a 404 Not Found response:
die "404: no such resource";
The body of the response will be:
{"error":"no such resource"}
You can even just throw a number:
die 404;
Some people consider this usage of exceptions to be kind of a hack, but it does make for really nice code if you'll give it a chance.
=head1 EXAMPLE
These files represent a complete-ish Chouette application that I have extracted from a real-world app. Warning: untested!
=over
=item C<bin/myapi>
#!/usr/bin/env perl
use common::sense;
use Chouette;
my $chouette = Chouette->new({
config_file => '/etc/myapi.conf',
config_defaults => {
var_dir => '/var/myapi',
listen => '8080',
logging => {
file_prefix => 'myapi',
timezone => 'localtime',
},
},
middleware => [
'Plack::Middleware::ContentLength',
],
( run in 1.308 second using v1.01-cache-2.11-cpan-f56aa216473 )