We've got a FastCGI-based web framework that we use internally for some mission critical apps. Thus moving to an existing PSGI-complaint framework is not very practical. We've successfully moved our framework over from plain old CGI.pm to Plack handlers.
However, there is quite a lot of routing logic, in the form of mod_rewrite rules, inside Apache's config file. If we were to deploy the apps that use our newly PSGI compliant framework using Plack::Handler::FCGI via reverse proxy in Apache, I suppose the mod_rewrite rules can continue to work there, with some tweaks. (Planning to do this, but haven't tried yet).
However, reading about Plack::Middleware::Rewrite as a replacement for mod_rewrite has intrigued me.
Do I need to convert mod_rewrite rules to Plack::Middleware::Rewrite rules and move all the app logic fully to Perl to get the full benefits of PSGI?
I think the answer is yes, but I've got no experience deploying PSGI apps so I'll appreciate it if some can share their experience to make sure that I'm going down the right path.
Sub-question Is the idea of PSGI all about letting the web server do as little (and as fast) as possible and delegating all the other stuff to application servers (middleware)?**
The benefit of PSGI is deployment flexibility. As long as you have rules in mod_rewrite, you are stuck with Apache and, therefore, not getting the full benefit of PSGI.
However, as long as you are happy with Apache, I don't see a strong motivation to rewrite all of your rules. If mod_rewrite is giving you headaches, then go for it.
Also consider putting your routing logic in your main app code with something like Router::Simple or Path::Router
BTW, unless you are really attached to FastCGI, there' probably no reason to use Plack::Handler::FCGI. Keep Apache as your reverse proxy and your app runs in Starlet or one of the other Plack web servers.