@wood Two questions and a comment:

1) You avoid a 3rd-party service like #Netlify because you "want [your] #blog to run forever,” but then use the https://Webmention.io #SaaS?

2) Did you use the classic #Perl #CGI module? You might enjoy the simpler and faster CGI::Tny instead. Here's a comparison: https://metacpan.org/pod/CGI::Tiny#COMPARISON-TO-CGI.PM

Comment: A lot of Perl is “legacy," but new #WebDev projects typically use #PSGI. An article on lifting to a modern framework: https://metacpan.org/pod/CGI::Alternatives

Webmention.io

@negative12dollarbill @Npazo @ovid I strenuously disagree about #Nginx and #Perl being at cross purposes. In fact, Nginx has long had a first-party module analogous to mod_perl: https://docs.nginx.com/nginx/admin-guide/dynamic-modules/perl/

#Fortra (formerly #AlertLogic)’s Web Application Firewall is based on Nginx and Perl: https://www.fortra.com/services/managed-services/waf

For web apps the usual done thing is to put Nginx in front of a #PSGI server like @miyagawa’s #Starman: https://metacpan.org/pod/Starman

Perl | NGINX Documentation

Implement location and variable handlers in Perl and insert Perl calls into Server Side Includes (SSI), with the Perl dynamic module, supported by NGINX, Inc.

@negative12dollarbill @Npazo What they mean is that “runs on #Apache and #Perl” isn’t specific enough to offer a recommendation. Is the web app using #CGI or the #mod_perl extension to Apache httpd? Does it rely on custom additions to the Apache configuration? etc.

You can try using #PSGI as @ovid suggested, but there may be more work involved and I don’t know how familiar you are with the app you inherited.

@ncommander You jest but my $work is in the final phases of a #Kubernetes migration of our decades-old #ModPerl app. (It's already running under #docker-compose in dev, test, and #CI)

Yes, we have goals to move to some #PSGI framework, but first we have to have repeatable deployments from dev through to prod.

@vandys @randomgeek @codinghorror As a #Perl hacker I will never besmirch #CGI as a standard or for light-use web scripts, but a lot of sins were committed with the two.

These days the done thing is to use #PSGI and a framework like #Mojolicious or #Dancer2 in a persistent app server. You don’t have to write nearly as much code, either. https://plackperl.org

The #Plack middleware can even run your code as a CGI or #FastCGI script if you reallly want.

PSGI/Plack - Perl Superglue for Web Frameworks and Web Servers

On this day in 2008, the #Apache Software Foundation released mod_perl 2.0.4, compatible with the December 2007 release of #Perl v5.10: https://lists.apache.org/thread/shyvjnl3dww17pdv24147vbnnwpcb64b

#ModPerl embeds a #Perl runtime in the Apache #httpd web server, hooking it into all stages of the request and response process as well as configuration file logic. Before the advent of #PSGI and #Plack in the 2010s, it was the recommended platform for persistent Perl web applications without the overhead of legacy #CGI.

#WebDev #ASF

@js @berkes @simon #CGI for #Perl #WebDev hasn't been a best practice since the release of the #PSGI spec and #Plack middleware in 2009. There are several very good frameworks that build on PSGI, described here for folks coming from CGI: https://metacpan.org/pod/CGI::Alternatives

The CGI module itself was removed from the core Perl distribution with v5.20 in 2014 https://perldoc.perl.org/perl5200delta#CGI-and-its-associated-CGI::-packages

For anything but the simplest single-user apps, you are permitted to point and laugh at anyone that still uses CGI.

CGI::Alternatives - Documentation for alternative solutions to CGI.pm - metacpan.org

Documentation for alternative solutions to CGI.pm