
Perl on Heroku - kraih
https://github.com/judofyr/perloku
======
melling
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?

~~~
peteretep
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::...](https://metacpan.org/search?q=distribution:DBIx-
Class+DBIx::Class::Storage::DBI)

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.

~~~
warp
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.

~~~
peteretep
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!

~~~
mst
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.

------
amirf
Looks awesome, always wondered if I could deploy perldancer web apps on
Heroku!

------
zrail
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...](http://search.cpan.org/~miyagawa/carton-v0.9.3/lib/Carton.pod)

~~~
judofyr
I agree; opened an issue: <https://github.com/judofyr/perloku/issues/2>

Carton; not sure. Maybe.

------
draegtun
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_

------
masukomi
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?

~~~
bogdanL
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.

~~~
Loic
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.

