Perl on Heroku(github.com)
github.com
Perl on Heroku
https://github.com/judofyr/perloku
5 comments
I did a lot of Perl CGI.pm stuff many years ago. What's the state of Perl for building web apps? Is it comparable to Python or Ruby? Where should an old Perl program start these days?
I've been using Catalyst for years now, for everything from AMQ Consumers which run warehouses to data analytics tools, to simple front-ends. Mojolicious looks promising, Dancer looks ... well, it does what it says it does, even if I don't see much point in that :-) Being Perl, there are a gazillion plugins for doing what you need that are well tested, and well documented, on the CPAN: https://metacpan.org/search?q=Catalyst
Template Toolkit is used almost exclusively for templating, although being Perl, there's lots of ways to do it (including Mason, which is a bit more PHP-esque).
DBIx::Class is the mature and most widely used DB interface, and seems to interface nicely with almost anything: https://metacpan.org/search?q=distribution:DBIx-Class+DBIx::...
All frameworks (ish) play nicely with Plack, which is a straight rip-off of Rack, but of course being Perl, there are a gazillion well-documented, well-tested, and sensibly installable plugins for it: https://metacpan.org/search?q=plack%3A%3Amiddleware
And then there's Moose, which provides a sane interface to the mind-boggling flexibility of the Perl object-system 'hack': https://metacpan.org/module/Moose
Programming in Perl on the web has never been as fun as it is today, and you'll find mst (who's a member here) was a lynchpin in most of the projects that made that true.
People talk about Perl being a glue language, and that's absolutely right: with CPAN, it's the ultimate mashup tool when you need it to be. It supports functional programming, Moose has made OO with it awesome, and it has a testing culture second to none.
Template Toolkit is used almost exclusively for templating, although being Perl, there's lots of ways to do it (including Mason, which is a bit more PHP-esque).
DBIx::Class is the mature and most widely used DB interface, and seems to interface nicely with almost anything: https://metacpan.org/search?q=distribution:DBIx-Class+DBIx::...
All frameworks (ish) play nicely with Plack, which is a straight rip-off of Rack, but of course being Perl, there are a gazillion well-documented, well-tested, and sensibly installable plugins for it: https://metacpan.org/search?q=plack%3A%3Amiddleware
And then there's Moose, which provides a sane interface to the mind-boggling flexibility of the Perl object-system 'hack': https://metacpan.org/module/Moose
Programming in Perl on the web has never been as fun as it is today, and you'll find mst (who's a member here) was a lynchpin in most of the projects that made that true.
People talk about Perl being a glue language, and that's absolutely right: with CPAN, it's the ultimate mashup tool when you need it to be. It supports functional programming, Moose has made OO with it awesome, and it has a testing culture second to none.
I'm one of the developers on musicbrainz, which is written using many of the technologies listed above.
We're experimenting with moving from Template::Toolkit to Xslate, we're having performance problems with Template::Toolkit.
Similarly we're seeing performance issues with Moose, and considering moving at least some of the code over to Moo.
If your project uses many CPAN packages, have a look at Carton. It has made our deployments infinitely easier.
We're experimenting with moving from Template::Toolkit to Xslate, we're having performance problems with Template::Toolkit.
Similarly we're seeing performance issues with Moose, and considering moving at least some of the code over to Moo.
If your project uses many CPAN packages, have a look at Carton. It has made our deployments infinitely easier.
I wouldn't expect Moo to gain you much over Moose in terms of runtime performance, except in the very simple cases where Moo can use Class::XSAccessor instead of generating a perl accessor method. What you probably want instead is to profile and selectively remove type constraints - perhaps only for runtime but not for the test suite. Consider:
package MyApp::AssertIsa;
use strictures 1;
use base qw(Exporter);
our @EXPORT = qw(assert_isa);
sub assert_isa { $ENV{SOMETHING} ? @_ : () }
use Moose;
use MyApp::AssertIsa;
has foo => (is => 'ro', assert_isa(isa => 'Bar'));
Performance issues with TT? Yowza... I am assuming you're using the XS version, helping it cache, have used a profiler to confirm that's really where it is etc. You must be serving a dramatic amount of dynamic traffic!
TT performance really can be a bitch. When I'm profiling Catalyst apps to improve performance I pretty much always assume that the first set of hotspots I'll find will be either Template Toolkit or waiting for database queries. The controller code and the Catalyst stack itself very rarely show up noticeably - and I'd suspect that Catalyst being the heaviest (or most featureful, depending on how you want to lookat it :) of the currently popular frameworks that that's likely to be true of everything else as well.
>> All frameworks (ish) play nicely with Plack, which is a straight rip-off of Rack
When developing PSGI/Plack, Miyagawa not only looked at Rack but also WSGI (Python) and also the proposed improvements to WSGI.
ref: http://bulknews.typepad.com/blog/2009/09/psgi-perl-wsgi.html | http://www.b-list.org/weblog/2009/aug/10/wsgi/ | http://jacobian.org/writing/snakes-on-the-web/
When developing PSGI/Plack, Miyagawa not only looked at Rack but also WSGI (Python) and also the proposed improvements to WSGI.
ref: http://bulknews.typepad.com/blog/2009/09/psgi-perl-wsgi.html | http://www.b-list.org/weblog/2009/aug/10/wsgi/ | http://jacobian.org/writing/snakes-on-the-web/
What's the right perl module to use for queue based worker stuff these days? I like rabbitmq, but unless there's something I'm missing, AMQP support in perl seems a little sketchy. Is STOMP the way to go? Or should I just build 0mq workers off mongrel2 and roll my own solution with POE or something? I kinda feel like Perl is falling a little behind in this space, but maybe I'm just not seeing what everyone else is doing.
(mst, and of course kraih, who I note posted the OP)
I'd suggest also adding miyagawa to that list for Plack, cpanminus and Carton ... but then if we start adding people we'll never stop. I've given out hundreds of commit bits over the year just to the projects we provide hosting on http://git.shadowcat.co.uk/ for - CPAN's a big big place and that never ceases to make me happy.
There is a list of web frameworks on the Perl5 wiki: http://www.perlfoundation.org/perl5/web_frameworks
However it needs a little updating because both Dancer & Mojolicious would now come under the Popular Frameworks.
Also see PSGI/Plack which all the modern Perl frameworks now work on/with: http://plackperl.org/
However it needs a little updating because both Dancer & Mojolicious would now come under the Popular Frameworks.
Also see PSGI/Plack which all the modern Perl frameworks now work on/with: http://plackperl.org/
Catalyst has been the favorite for some time now:
* http://www.catalystframework.org/
* http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.90007/li...
* http://www.catalystframework.org/
* http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.90007/li...
CGI isn't fun. I understand legacy code that runs on it, I don't think developing new web apps with it is the right thing to do, there are plenty of amazing frameworks which make perl web programming fast, powerful and fun again:
You have Catalyst (full on MVC framework, you can compare it to Rails), Dancer* (micro-web inspired by Ruby's Sinatra) and Mojolicious to name a few.
*Hint: Start here - http://perldancer.org/
You have Catalyst (full on MVC framework, you can compare it to Rails), Dancer* (micro-web inspired by Ruby's Sinatra) and Mojolicious to name a few.
*Hint: Start here - http://perldancer.org/
Mojolicious, which was used in the Heroku example. http://mojolicio.us
When looking for modules, a good place to start is the list of recommendations in Task::Kensho. https://metacpan.org/module/Task::Kensho
To refresh your Perl skills, there's the Modern Perl book. http://www.onyxneon.com/books/modern_perl/index.html
To refresh your Perl skills, there's the Modern Perl book. http://www.onyxneon.com/books/modern_perl/index.html
You want to look at:
* Dancer
* Mojolicious
* Catalyst
Looks awesome, always wondered if I could deploy perldancer web apps on Heroku!
I see that it's looking for a special file named Perloku and then expecting to execute that. Would it maybe be better to look for a Makefile.PL, use that to build, and then work with the standard Procfile system that Heroku has? That would be altogether more flexible.
You could also mandate using Carlton[1], which someone downthread mentioned as "bundler for perl". It's alpha at the moment, but that shouldn't stop anyone from using it.
[1]: http://search.cpan.org/~miyagawa/carton-v0.9.3/lib/Carton.po...
You could also mandate using Carlton[1], which someone downthread mentioned as "bundler for perl". It's alpha at the moment, but that shouldn't stop anyone from using it.
[1]: http://search.cpan.org/~miyagawa/carton-v0.9.3/lib/Carton.po...
I agree; opened an issue: https://github.com/judofyr/perloku/issues/2
Carton; not sure. Maybe.
Carton; not sure. Maybe.
Also see heroku-buildpack-perl: https://github.com/miyagawa/heroku-buildpack-perl
This is a Heroku buildpack that runs any PSGI based web applications using Starman
This is a Heroku buildpack that runs any PSGI based web applications using Starman
does anyone know if an alternate port has to be specified with this? Is there a reason it can't just be run on 80?
The example gives port 3000 as an example for running it on your localhost. Otherwise you need super-user permissions to start a server on port 80.
But on Heroku's Cedar stack, it will run on port 80.
But on Heroku's Cedar stack, it will run on port 80.
Maybe 80, maybe not, it will run on port $PORT which is provided at runtime by Heroku. Practically you do not need to worry about it, Heroku will take care to route the request from port 80 on the outside to port $PORT at the dyno level.