[2.x] Add support for FrankenPHP

[dunglas]

This patch adds FrankenPHP as a runtime for Laravel Octane!

To get started, use the following commands:

php artisan octane:install --server=frankenphp
php artisan octane:start

The current implementation provides feature parity with RoadRunner (worker mode, watch, and max requests) but also adds new features not supported by the other engines:

• Production-grade HTTPS (with automatic certificate creation and renewal), HTTP/2, and HTTP/3 (enabled only if the new --https flag is passed)
• Real-time updates with the built-in Mercure hub. Install mvanduijker/laravel-mercure-broadcaster for seamless integration with Laravel Broadcast.
• Support for sending 103 HTTP Early Hints responses (assets preloading), (see [HttpFoundation] Add support for the 103 status code (Early Hints) and other 1XX statuses symfony/symfony#48128 for usage examples)
• Automatic compression using Zstandard or Gzip, depending on client support

[taylorotwell]

Very cool - will review! 🙏

[driesvints]

Very cool @dunglas!

[vasilvestre]

The description about the https isn't clear, feels like HTTP3 is enabled when https is on but HTTP2 is always on.
Apart from it, incredible work :)

[dunglas]

@vasilvestre thanks! To clarify: by default, only HTTP/1.1 (unencrypted) is enabled. When --https is passed, the connection is encrypted and HTTP versions 1.1, 2 and 3 are supported.

[roberto-butti]

super, i will try it!

[francislavoie]

👋 Hey everyone! @dunglas and I spoke a bunch about FrankenPHP in the past; I'm a Caddy maintainer by night, and a PHP dev by day, so these comments come from that perspective.

[oprypkhantc]

Hey @dunglas. We're currently running Octane/Swoole + Nginx. If we were to switch Nginx with Caddy (so Swoole + Caddy), how would that be different from FrankenPHP? The proxy configuration is already extremely simple in Caddy, and the Caddy process itself is lightweight, so what are the practical benefits of this complex integration?

I'm not discrediting your work, just am curious of whether we should switch and how this can be beneficial to us. Thanks :)

[dunglas]

Hi @oprypkhantc, the main difference is that with FrankenPHP, Caddy isn't acting as a proxy: FrankenPHP is a custom build of Caddy with an extra module that embeds PHP in it. That means that PHP and Caddy are the same program, running as the same process. Calling the PHP engine from Caddy is just a function call, with no network connection involved, no IPC, etc.

It's probably explained more clearly at the beginning of this video: https://www.youtube.com/watch?v=q6FQaaFZVy4

[oprypkhantc]

Hi @oprypkhantc, the main difference is that with FrankenPHP, Caddy isn't acting as a proxy: FrankenPHP is a custom build of Caddy with an extra module that embeds PHP in it. That means that PHP and Caddy are the same program, running as the same process. Calling the PHP engine from Caddy is just a function call, with no network connection involved, no IPC, etc.

It's probably explained more clearly at the beginning of this video: https://www.youtube.com/watch?v=q6FQaaFZVy4

Thank you. It'd be interesting to see if this affects performance for our API-only app though, as there's not a lot of traffic, so likely not a lot of overhead from the proxying.

I'll post the results when I get to try it if anyone is interested.

[fannyfan414]

It's probably explained more clearly at the beginning of this video: https://www.youtube.com/watch?v=q6FQaaFZVy4

Thanks, cool video!
One more question - what happens if I scale same app(binary) to multiple servers? How caddy will manage certificates between 2 servers?

[francislavoie]

@fannyfan414 see https://caddyserver.com/docs/automatic-https#storage, you're meant to configure storage to be shared across all your instances. You can use filesystem syncing, or you can use a Redis storage module, for example.

[nickarellano]

Very interested in this. How does this effect running it as a binary with octane?

[jhoanborges]

Waiting for this...

[marsderp]

Very interested in this. How does this effect running it as a binary with octane?

Second this - anyone know of any guides on how to build a binary with octane yet?

[ARehmanMahi]

Sorry for the noob question, when using php artisan octane:install --server=frankenphp, what's the difference between using system php rather than frankenphp's php-cli like:

php artisan octane:start VS ./frankenphp php-cli artisan octane:start

[dunglas]

@ARehmanMahi this will use the PHP engine embedded in the binary. This should work, even with no local installation of PHP.

[ARehmanMahi]

@ARehmanMahi this will use the PHP engine embedded in the binary. This should work, even with no local installation of PHP.

@dunglas Thanks for the reply, one more question as I'm a bit unclear.

As FrankenPHP has its own PHP, I assume php artisan octane:start will use Franky's built-in PHP to run the app even though it was started with system's php, is this how it works?

P.S. If that's the case, I can completely get rid of systems php for the project I reckon. Which feels great.

[rodrigopedra]

@ARehmanMahi if you alias php to the FrankenPHP binary in your system, that will work as you described.

Otherwise, your system won't know which binary to run when you type php artisan ....

Also, keep in mind that composer will try to resolve the PHP binary, so you still need a globally accessible PHP binary, be it an alias to the FrankenPHP binary or a system installed one.

[whousehomestay]

Is this still in beta version like in the Octane Docs until now?

[jameshulse]

Is this still in beta version like in the Octane Docs until now?

I'm wondering the same, and whether there is somewhere that we can track progress of this integration moving out of beta. We are holding off moving to octane until this integration stabilises as it seems to be the most promising in a number of ways.

[oprypkhantc]

Is this still in beta version like in the Octane Docs until now?

I'm wondering the same, and whether there is somewhere that we can track progress of this integration moving out of beta. We are holding off moving to octane until this integration stabilises as it seems to be the most promising in a number of ways.

Speaking from experience, you'll likely have to fix countless little bugs when moving to Octane, regardless of what specific web server you'll be using, be it RoadRunner, Swoole or FrankenPHP. Octane itself is stable as far as I know and as far as I've seen in the last year we've been running it in production.

Switching the integration from Swoole to FrankenPHP should not touch any of your application code and should require only minimal changes to your (hopefully containerized) setup, so consider moving to Octane/Swoole first and only then to FrankenPHP :)

[ARehmanMahi]

@oprypkhantc your 1st & 2nd line seems contradictory.

Is it moving to Octane that will cause countless bugs?
Or not moving and starting with Octane from scratch is the better option.
I can't deduce what you mean actually.

Moving to in-memory application architecture requires a keen eye on using STATIC/Singleton, which could cause bugs or memory leaks. Note to self.

[oprypkhantc]

@ARehmanMahi Moving to Octane itself is likely to cause bugs.

And the problem is not just static/singletons; we had more problems with Laravel itself than with our app code. There is a lot that Octane does to "fix" the poor implementation choices of Laravel; for example, the container/app instance is cloned for every request, meaning you have to be extra careful when injecting the Container in your services. Same goes for multiple other things too, to which Octane has a whole dedicated section in the docs.

[ARehmanMahi]

Okay, so you mean it's not necessarily the app or octane, but laravel itself.
Well, I can agree on this with you. Recently been hit by weird issues in laravel. Cache maco plus the tags memory leaks for instance. Good luck everyone.