Act Voyager Report

No Comments

The Act - Voyager project has not come to a halt, although it has been a bit silent. My apologies for those who had been waiting last month for the report.

Life has taken some turns, in my favour, and thanks to Rick Deller from Eligo, I got a nice job at Broadbean technologies in London - and yes, moved from my lovely little hometown to the Perl capital of the United Kingdom, and met some great people at work or during the London pm activities.

The few hours left, I kept pushing forward the project, little by little. And I am very happy with the direction it is going and below I will try to explain what has happend with the basics of the REST-api. But before that, I think I should mention that the Act-Voyager project will leave behind the legacy system. It has served the community for more than a decade and during that time changes have been made to fulfil the needs organisers had. But in that process some decisions also have led to not such nice solutions. Things will need to change and a nice REST-api should come from the drawing-board...

REST api's deal with resources, indicated by an URL... the new structure will be:

The first level (which I called a syndicate) functions as a kind of aggregate for the events organised under that 'authority'... in this example... the 2015 edition of the YAPC-NA. In the future I would love to see it happen that we could use it also for the monthly pm-meetings, like

So, in the future, the api will simply deliver the news about YAPC-NA at the resource:

and if you only want the news for the 2016 edition

The design is slightly deviant from other URL patterns, normally it would be more tedious: or the other approach would be using tons of filters.

Another important thing in designing a REST-api is the decoupling between the REST resource representations and that actual data-store. In other words, the Act-Voyager REST resources are not being a 1 to 1 translation of the legacy-tables, but will be composed from different tables. At a few occasions in Cluj, Amsterdam-X, German Perlworkshop, I gave a presentation about multi-lingual REST api's and did address the decoupling and how a REST api should use a abstraction layer which does all the hard work - not your Dancer2 app.

Add on top of that the fact that Act has a 'rights' table that holds the information for a conference and a user and what rights he / she has, and it becomes obvious that it was not going to be a simple Dancer2 dispatch app. For the authentication I modified some previous work I did for a plugin: Dancer2::Plugin::HTTP::Auth::Extensible.

Bolting all things together, I came up with a REST::api::Handler... one that can do only very simple tasks... dispatch the work to the REST::api::Objects, REST::api::Collections or REST::api::DataStore. Now, instead of having all these different methods in one huge module, I put them in smaller modules, Moo::Roles to be more specific. And each of these roles will be applied to the Handler object, based on the context... a ResourceRoot and a ClientUser.

inside Dancer2, it looks just like:

post '/news' http_require_task 'insert_news' => sub { http_handler->insert_news(...) };

And the handler knows if and on what level to dispatch the request to the REST api datastore.

I personally think, Act Voyager is going to have a save journey now

NB: for the brave... check it out on Github

Theo van Hoesel

Leave a comment

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at

About this Entry

This page contains a single entry by Elizabeth Mattijsen published on June 3, 2015 1:02 PM.

Deadline Extended - Call For Grant Proposals was the previous entry in this blog.

Maintaining Perl 5: Grant Report for April 2015 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 6.2.2