tl;dr: Yes.
Plack is the namespace for an implementation of the PSGI standard. It is a more powerful modernization of and diversion from CGI. nginx wisely does not even support CGI (out of the box). That means you must use PSGI/Plack at least, though if you're feeling like redecorating your rooms in rubber you can use CGI beneath that. All modern Perl webframeworks (Catalyst, Mojolicious, Dancer2…) use PSGI as their interface layer because it is easily the best and most flexible way to do things today. Here is a simplistic but working set of code to run a toy app over PSGI through uWSGI/nginx.
Code <-> Dancer2 <-> PSGI <-> uWSGI <-> nginx <-> Clients
I recommend uWSGI over Starman.
| [reply]
[d/l] |
In your diagram of the simplistic deployment stack, I notice a distinct lack of layers labeled "Plack". Or is your overall point that "Plack" really just means "any arbitrary implementation of PSGI"?
| [reply] |
| [reply] |
I see that ngnix can connect to Mojo's Hypnotoad without going through Plack pagi.what sort of protocol is used there?
www.mind-it.info/2014/09/27/running-hypnotoad-behind-nginx/
| [reply] |
The configuration on the linked page shows nginx connecting to hypnotoad using proxy_pass, which connects to the back-end service using HTTP. This is also indicated by the backend having an http://... URL and the proxy_set_header X-Forwarded-Proto "http"; configuration setting.
| [reply]
[d/l]
[select] |
Well, at least one of those frameworks won't work without Plack. Surely, you see that, don't you?
Plack is what we call a "framework for frameworks", not exactly targeted at your "average" Perl developer, but there's nothing stopping them from using Plack in its barebones form.
As an exercise, take a look at Plack's reverse dependencies
Have fun, as always! | [reply] |
