Is FrankenPHP a fork?

[mindplay-dk]

From the documentation, I don't understand, is FrankenPHP a fork of Caddy, or just an extension?

If it's a proper extension, where is the documentation that explains how to install that?

I mean, for the use case where I already have my Caddy server and want to add FrankenPHP? I don't see anything in the documentation explaining how to do that? It doesn't seem like that's going to be an exotic use case?

Or is it actually a modified version of Caddy? Do I need to switch from Caddy to FrankenPHP?

[dunglas]

It isn't a fork of Caddy, it is a custom Caddy build that includes an extra Caddy module. As it requires complex build steps (involving cgo), we provide our own binaries, Docker images, etc.

You can follow these steps to build FrankenPHP on top of an existing Caddy installation (using xcaddy): https://frankenphp.dev/docs/compile/#using-xcaddy

[mindplay-dk]

That helps, though I'm still a bit fuzzy on what exactly this is. 😅

The home page says:

• Native support for HTTP/1.1, HTTP/2 and HTTP/3
• Automatic HTTPS certificates generation and renewal (Let’s Encrypt or ZeroSSL)

To be clear, these are just Caddy feature, right? Nothing inherently to do with the FrankenPHP module?

• Copy your PHP files in the document root, that’s all!

This point confuses me as well - so you can just host any regular PHP script?

Because this makes it look like some sort of PHP-based daemon (along the lines of Swoole) is what creates the magic? along with the fact that major frameworks seem to have dedicated FrankenPHP integrations?

This does not look like a "normal" index.php, so what does this loop accomplish? Is this just to save on the number of PHP processes, allowing the same PHP script execution to process multiple incoming requests, turning it into a kind of "worker"?

Is this what makes FrankenPHP fast? I wish the tech itself was better explained. Swoole was very easy to understand, as it's just a PHP script with extensions that implement a web server within the script itself, at least conceptually. FrankenPHP appears to use a different level of abstraction, where multiple different PHP scripts can potentially act as "workers" for multiple incoming requests?

Is there a PSR-15 integration, or would I just plug in an existing PSR-15 SAPI host such as this in an index.php script? Is the added for loop required to reap the performance benefits?

[dunglas]

To be clear, these are just Caddy feature, right? Nothing inherently to do with the FrankenPHP module?

Yes! The only "generic" web server features that are FrankenPHP-specific are Brotli support (because we already rely on cgo anyway), Mercure and Vulcain.
Everything not directly PHP-related comes from Caddy.

This point confuses me as well - so you can just host any regular PHP script?

Yes. There are two modes: the normal CGI-like mode works with any existing PHP app without modification.

The worker mode is more like Swoole and requires some slight modifications. Laravel Octane and Symfony Runtime are necessary for this mode, not for the normal CGI-like one.

Is this what makes FrankenPHP fast?

Yes (among other things like multi-threading, 103 Early Hints, Brotli, ZStandard and HTTP/3).

multiple different PHP scripts can potentially act as "workers" for multiple incoming requests?

Indeed.

Is there a PSR-15 integration, or would I just plug in an existing PSR-15 SAPI host such as this in an index.php script? Is the added for loop required to reap the performance benefits?

We just use typical superglobals. Any PSR-15 implementation will work if your app needs it. HttpFoundation (Symfony, Laravel, Drupal etc) is also supported.

The for loop is mandatory to use the worker mode (which is optional).

[mindplay-dk]

@dunglas thank you, this helps a lot. 👍

Your approach to workers is quite interesting - keeps things working mostly like PHP, but with the ability to any script to potentially act as a worker by processing multiple requests.

So, if a script doesn't do the loop, the module treats this just like a looping worker terminating? a non-looping script is essentially a "worker that quits after one request", yes? I have to wonder how you schedule this behind the scenes? Since the for loop is synchronous, I would guess that processing multiple requests in a single worker only really happens when the server is under enough load, that requests are coming in fast enough that it's worth while and doesn't add unacceptable latency?

It might be a good idea to have a "how does it work" page? Black boxes make me uneasy, personally - and many developers might not even know which questions to ask. I'm sure there's more you could tell that I wouldn't even know to ask. 😅