Comment by jpetazzo | Hacker News Reader

Comment by jpetazzo | Hacker News Reader

Parent Full thread

Hi,

Well, actually, we didn't pickup Plack from its author. When people started asking about Perl, we just replied with another question: "which framework? how? what?", and we tried extract the most common denominator.

The vast majority told us about Mojolicious, Dancer and Catalyst. There seemed to be a pattern :-)

Regarding the server interface, a lot of people seems to agree over Plack. We were the ones asking "hey, what about FastCGI?" - since I personally never had met Plack before. We were shown the Plack::*::FCGI modules and thought "okay, that seems cool".

Then we had a look at the server options. We had already used UWSGI for the Python stack, and UWSGI has a PSGI module. Some might say that it's a bit experimental, but the authors are awesome people, always willing to fix bugs as fast and efficiently as possible.

Of course, the author of Plack helped us to get everything straight - but paradoxally, he was also the one pointing us to cpanm, perlbrew and basic stuff like Makefile.PL.

Now, to get back to you: what does your app look like? We would like to help and see how we can get it to run on DotCloud!

Dancer and Mojolicious are pretty new and I will not use them in production yet (not to say that our framework is better, way from that but just that it's not open to things like that: http://blog.kraih.com/mojolicious-116-emergency-release-plea...). Catalyst is a dependency hell made true,not for us either. Mojolicious and Dancer will certainly be nice and will look into it but not at this stage of development.

>Some might say that it's a bit experimental,

Because it is.

It's nice to play with it though. But not quite yet to use for our clients.

> but the authors are awesome people, always willing to fix bugs as fast and efficiently as possible.

Won't be able to say to my client: well, you know, we've tried this experimental stuff but we met these bugs we can't do anything about.

"hey, what about FastCGI?"

This was a very good question and I would have answered go for it... Apache+FastCGI+CGI::Fast. That's quite common nowadays and I think well understood, well documented.

cpanm is not necessary, I've never used it and am happy with cpan. oh, right, cpanm is by the same author right?

perlbrew&locale::lib are nice things to have though.

> We would like to help and see how we can get it to run on DotCloud!

Apache+FastCGI+CGI::Fast,that will do for me.

Apache+mod_perl,that will do (even though i don't use it).

Having at the cutting edge technologies is nice, don't get me wrong but it would help to have at least a more stable or at least bullet-proof environment too.

I resepectfully disagree. My company has two PSGI Dancer apps running mission critical elements. They're "new" but they're absolutely production ready. Plack/PSGI has been embraced by almost everyone.

I'm REALLY looking forward to playing with DotCloud.

Plack/PSGI is not "cutting edge". It's the way to do it now, not tomorrow. You do Miyagawa a disservice implying he's pumping his own code.

Likewise my company is 100% PSGI for the last year+, we're a mix of a good number of Catalyst and Dancer apps. We've had absolutely 0 problems here.

PSGI stable, sane and the way you want to be doing things.

As both of you have a good experience of Plack/PSGI, could you sum up the benefit you got from using it?

If your app (or your framework) runs on Plack/PSGI you have a wide choice of server implementations. It will work under mod_perl, FastCGI and numerous other server environments.

Indeed if you write an app to run on DotCloud; you can also run the same app on your laptop, Phenona, any other server -- etc etc.

As someone else said (more politely), you'd have to be nuts to do an HTTP app now and not take advantage of it.

>Plack/PSGI has been embraced by almost everyone.

In your company or in general? Because if it's in general, I would be more than happy to see where you get your stats.

> You do Miyagawa a disservice implying he's pumping his own code.

Well, I do think that a not even 2yo spec,a set of modules that are 6~18 months old pushed on a cloud service like that with no back up plan for more "traditional" systems is a way to push its own system. we can agree to disagree on that. which percentage of providers offer plack with nginx nowadays compared to Apache with FactCGI?

If you have a problem with Catalyst dependencies, please report them to irc.perl.org #catalyst (I'm mst on there).

Any time anybody reports a problem with them, we go out of our way to solve it - avoiding wheel reinvention is important to us to speed development but we understand that using a module makes us responsible for it installing for end users.

if you really want CGI.pm, there are Plack modules to convert a PSGI environment to a CGI environment - descended roughly from the Catalyst::Controller::WrapCGI that Opsview sponsored Shadowcat to write years ago.

And remember, PSGI might appear to be new but much of the guts of Plack are pulled from previous framework-specific code so the various workarounds for server insanities are already there. It's a lot more reliable than you appear to think.

>PSGI might appear to be new but much of the guts of Plack are pulled from previous framework-specific code so the various workarounds for server insanities are already there. It's a lot more reliable than you appear to think.

I see. Perhaps my vision of the state of PSGI is not right indeed. Nethertheless, my apps run under Fast::CGI and I really don't see the advantage of PSGI.

By the way, I see that you've decided to go with Nginx as the primary server for all languages and this is not really a problem in fact. I don't think switching to Nginx would be much of a hassle.

Reply on news.ycombinator.com