The backend API is indeed (modern) Perl and the repository is here: https://github.com/metacpan/metacpan-api
The basic idea is simple though. Use strict. Use warnings. Use new features and best practices modules (Task::Kensho[2] an help here) when them make sense (e.g. Moose/Moo). Be aware at least what PBP[3] is, and if you feel so inclined, use Perl::Tidy and/or Perl::Critic (even if your own defined subset of rules) to give yourself an idea of what is considered good practices (and when to throw them our for that elegant line or two, just don't forget to comment it so you don't confuse yourself when you see it months/years later). Basically, if you care about the code you write, you should find yourself gravitating towards writing Modern Perl anyway, and the speed at which it happens is largely determined by your exposure to the Perl community at large.
My own personal set of best practices means almost always using something like Function::Parameters or Kavorka, and possibly Moops.[4]
1: https://metacpan.org/pod/Modern::Perl
2: https://metacpan.org/pod/Task::Kensho
Uhm, I can't see Catalyst listed in the web development section... Has it fallen out of grace ?
Mojolicious and Dancer are the more modern equivalents, and both are frameworks in the vein of Ruby's Sinatra or Rails (probably more in-between). While you can run them as CGI/FastCGI, really nowadays I think most people just run them as standalone pure-Perl web servers (which makes it really easy to access and deal with every part of the request and routing), optionally with a proxying front-end such as Nginx or Apache to speed op static requests or handle SSL (but that's not needed, both are entirely capably of doing SSL encrypted servers in pure-perl with a few configuration params set).
Like the sibling comment, I prefer Mojolicious, and it's simple enough that the landing page for it[1] shows not just one but two fully functional standalone web applications with embedded webservers, one of 5 lines and one of 25 lines (both counts including blank lines). That may not help much with existing Catalyst apps, but I would be hard pressed to recommend Catalyst given how far the state of the art has advanced, but then again I've never really been a Catalyst user, so I may be unaware of a lot of its benefits.
The thing I like about catalyst is the same as the thing I like about git. It works well for the smallest use case and it scales well to the largest reasonable case.
Rather than try to guess at the proper set of modules recommended by a subproject, if there was already a recommendation (ie a Task:: module) we tried to re-use that.