FCGI::Engine(3pm)

✨ FCGI::Engine 💖

okay bestie, so this is the manual page for FCGI::Engine (the 3pm one, perl-verse, you know the vibe) and honestly? it's giving "I will handle your low-level FCGI nonsense so you don't have to" and I'm obsessed. 💅

---

🌸 NAME 🌸

FCGI::Engine — a flexible engine for running FCGI-based applications 🦋

---

✨ SYNOPSIS ✨

# in scripts/my_web_app_fcgi.pl
use strict;
use warnings;

use FCGI::Engine;

FCGI::Engine->new_with_options(
    handler_class  => 'My::Web::Application',
    handler_method => 'run',
    pre_fork_init  => sub {
        require('my_web_app_startup.pl');
    }
)->run;

# run as normal FCGI script
perl scripts/my_web_app_fcgi.pl

# run as standalone FCGI server
perl scripts/my_web_app_fcgi.pl --nproc 10 --pidfile /tmp/my_app.pid \
                                --listen /tmp/my_app.socket --daemon

# see also FCGI::Engine::Manager for managing
# multiple FastCGI backends under one script

like. look at that. three whole ways to run it and not one of them is stressful. 🌈

---

💜 DESCRIPTION 💜

so basically this module is your group-chat mom for FCGI web apps: it wraps up all the low-level FCGI details so you literally never have to touch them. it can run your FCGI program as a plain little script, or as a full standalone socket-based server that gets managed by FCGI::Engine::ProcManager. both. either. main character energy. 👑

the code is largely based (cough stolen cough) on the Catalyst::Engine::FastCGI module, and it gives you a command line interface that's compatible with that module. but — and this is the important part — it does not require Catalyst or anything Catalyst-related. so you can bring your CGI::Application-based web app, or literally any Random::Web::Framework-based web app. no gatekeeping here. 🫶

🧚 Using with Catalyst, Plack or other web frameworks 🧚

FCGI::Engine is not a replacement for Catalyst::Engine::FastCGI. instead, the FCGI::Engine::Manager (and all of its configuration tools) can be used to manage Catalyst apps as well as FCGI::Engine-based applications. for example, at work there's an application with 6 different FCGI backends running. three of them use an ancient in-house web framework with simple FCGI::Engine wrappers, one uses CGI::Application and an FCGI::Engine wrapper, and then two are Catalyst applications. they all happily and peacefully coexist and are all managed with the same FCGI::Engine::Manager script. found family fr fr. 💖

as of version 0.11 there's Plack/PSGI application support via the FCGI::Engine::Manager::Server::Plackup module. go read that module for more info on how to use it.

🍓 Note about CGI.pm usage 🍓

this module uses CGI::Simple as a sane replacement for CGI.pm, and it will pass a CGI::Simple instance into your chosen handler_method for you — so no, you do not need to create your own instance of it. 💅

there have been a few cases from users who had bad interactions with CGI.pm and the instance of CGI::Simple created for you, so before you spend hours looking for bugs in your app, check for this first instead. seriously. save yourself the heartbreak. 😭

if you want to change this behavior and not use CGI::Simple, you can override it using the handler_args_builder option — docs on that are below, keep scrolling bestie.

---

💀 CAVEAT 💀

this module is ***NIX only. it definitely does not work on Windows and there is no intention of making it do so. sorry. 🙈

---

👑 PARAMETERS 👑

🌟 Command Line 🌟

this module uses MooseX::Getopt for command line parameter handling and validation. fancy? yes. deserved? also yes.

all parameters are currently optional, but some parameters depend on one another. it's giving "situationship" but for flags. 💅

• --listen, -l — this should be a file path where the unix domain socket file should live. if this parameter is specified, then you must also specify a location for the pidfile.
• --nproc, -n — this should be an integer specifying the number of FCGI processes that FCGI::Engine::ProcManager should start up. the default is 1.
• --pidfile, -p — this should be a file path where your pidfile should live. this parameter is only used if the listen parameter is specified.
• --daemon, -d — this is a boolean parameter and has no argument, it is either used or not. it determines if the script should daemonize itself. this parameter is only used if the listen parameter is specified.
• --manager, -m — this allows you to pass the name of a FCGI::ProcManager subclass to use. the default is to use FCGI::Engine::ProcManager, and any value passed to this parameter must be a subclass of FCGI::ProcManager.

🎀 Constructor 🎀

in addition to the command line parameters, there are a couple of parameters that the constructor expects. yes, both. you're welcome.

• handler_class — this is expected to be a class name, which will be used inside the request loop to dispatch your web application.
• handler_method — this is the class method to be called on the handler_class to serve as a dispatch entry point to your web application. it will default to handler.
• handler_args_builder — this must be a CODE ref that when called produces the arguments to pass to the handler_method. it defaults to a sub which returns a CGI::Simple object.
• pre_fork_init — this is an optional CODE reference which will be executed prior to the request loop, and in a multi-proc context, prior to any forking (so as to take advantage of OS COW features). 🐄✨

---

💅 METHODS 💅

🌈 Command Line Related 🌈

• listen — returns the value passed on the command line with --listen. this will return a Path::Class::File object.
• is_listening — a predicate used to determine if the --listen parameter was specified.
• nproc — returns the value passed on the command line with --nproc.
• pidfile — returns the value passed on the command line with --pidfile. this will return a Path::Class::File object.
• has_pidfile — a predicate used to determine if the --pidfile parameter was specified.
• detach — returns the value passed on the command line with --daemon.
• should_detach — a predicate used to determine if the --daemon parameter was specified.
• manager — returns the value passed on the command line with --manager.

🔍 Inspection 🔍

• has_pre_fork_init — a predicate telling you if anything was passed to the pre_fork_init constructor parameter.

🔥 Important Stuff 🔥

• run (%addtional_options) — call this to start the show. 🎬

it passes the %addtional_options arguments to both the pre_fork_init sub and as constructor args to the proc_manager.

🌸 Other Stuff 🌸

• BUILD — this is the Moose BUILD method, it checks some of our parameters to be sure all is sane. vibe check, basically.
• meta — this returns the Moose metaclass associated with this class.

---

🌟 SEE ALSO 🌟

• Catalyst::Engine::FastCGI — I took all the guts of that module and squished them around a bit and stuffed them in here. (affectionate. 🫶)
• MooseX::Getopt
• FCGI::ProcManager — I refactored this module and renamed it FCGI::Engine::ProcManager, which is now included in this distro.

---

😭 BUGS 😭

all complex software has bugs lurking in it, and this module is no exception. if you find a bug please either email me, or add the bug to cpan-RT. no cap, please do report it — it's not snitching, it's self-care. 💖

---

✨ AUTHOR ✨

Stevan Little <stevan@iinteractive.com>

contributions from:

• Marcus Ramberg
• Bradley C. Bailey
• Brian Cassidy
• Johannes Plunien

the squad. 👑

---

🎀 COPYRIGHT AND LICENSE 🎀

Copyright 2007-2010 by Infinity Interactive, Inc.

<http://www.iinteractive.com>

this library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

---

okay that's the whole page, bestie, and one last thing before you go: this whole thing came from perl v5.36.0, dated 2022-12-10, and it's the FCGI::Engine(3pm) page. slay, go run your FastCGI apps, ily 💖✨🦋