[HN Gopher] Show HN: FrankenPHP, an app server for PHP written i...
___________________________________________________________________
Show HN: FrankenPHP, an app server for PHP written in Go
Author : kdunglas
Score : 240 points
Date : 2022-10-14 15:59 UTC (7 hours ago)
(HTM) web link (frankenphp.dev)
(TXT) w3m dump (frankenphp.dev)
| green-salt wrote:
| I'll have to try this out!
| abrztam wrote:
| What is the difference between this and Roadrunner? It seems to
| do the same stuff.
|
| https://github.com/roadrunner-server/roadrunner
| kdunglas wrote:
| The approach isn't the same:
|
| Roadrunner executes php-cli and connects it to its web server
| through GRPC; FrankenPHP uses an ad-hoc SAPI, it is more like
| Apache's mod_php, the Go code uses the PHP interpreter as a
| library, it's all in the same process.
|
| RoadRunner only has a worker mode, and can only work with
| compatible apps; FrankenPHP has a "standard" mode compatible
| with all existing applications, and a worker mode that requires
| some code changes (like RR).
|
| RoadRunner runner uses PSR-7 HTTP messages; FrankenPHP uses
| plain old superglobals and streams (both in normal and in
| worker modes), they are reset after each handled request.
|
| RoadRunner is battle-tested and production ready; FrankenPHP is
| experimental and not yet ready for production use.
|
| FrankenPHP can also be used as a Go library to integrate PHP
| into any Go program or server (theoretically, it should be
| possible to integrate FrankenPHP into Traefik or the local
| Symfony web server, which are written in Go).
| bogdanu wrote:
| Since it's not using PSR-7, does it mean that you could even
| run WordPress?
| kdunglas wrote:
| I haven't tested it yet, but yes it's a stated goal.
| floppydisc wrote:
| no. 1 feature: goofier branding
| nobleach wrote:
| I've been watching how Go and Rust tooling has been finding its
| way into the JavaScript ecosystem. I've been out of the PHP realm
| for about 10 years but I did find RoadRunner for PHP at one
| point. That's also an app server written in Go I believe. I
| wonder how this compares.
| fideloper wrote:
| My understanding is RoadRunner is more like FrankenPHP's
| "worker mode" (RoadRunner only makes sense in context of
| Laravel Octane), where as FrankenPHP can run "normally" as
| well.
| jedisct1 wrote:
| Don't forget Zig, with Bun.
| jeffersonheard wrote:
| If this isn't pronounced Frankenphip I will be disappointed.
| tiffanyh wrote:
| I might be missing the obvious but why would you add extra
| complexity to your infrastrucutre setup when PHP can be run
| natively from within caddy, apache, nginx via fastcgi.
| mholt wrote:
| With this you don't need FastCGI. FrankenPHP _is_ simpler and
| less complex: just run it directly from your Caddy web server.
| CoolCold wrote:
| Short answer would be: sole solo developer experience (DX).
|
| Longer answer: avoiding infrastructure setup - for those who
| has infrastructure it makes no sense, for those who knows how
| to run things in Docker and not need much beyond it -
| eliminates the need of getting familiar with Docker Compose.
|
| Having php stay in memory should make performance benefits [and
| make sense for the project], but that's different story.
| fideloper wrote:
| Removing php-fpm + nginx from a container sounds AMAZING to me.
| If I can just have one thing in a container (plus a code base),
| that would be a LOT simpler than:
|
| nginx, php-fpm, some init system, and the convoluted
| configuration needed to get logs out via Docker's logging
| mechanism.
| PlutoIsAPlanet wrote:
| I've recently changed our nginx/php-fpm containers to
| caddy/php-fpm
|
| Caddy has a supervisor plugin, so can start php-fpm itself
| and the containers entrypoint can be Caddy, which achieves
| similar objectives here that Caddy becomes a PHP application
| server.
| francislavoie wrote:
| FrankenPHP will perform better than php-fpm though, in
| worker mode, because it doesn't need to bootstrap fully on
| every request. In the conference slides, Kevin showed php-
| fpm had a 12ms request latency, whereas FrankenPHP had 3ms.
|
| But yes, the supervisor plugin is definitely nice to be
| able to wrap up Caddy + php-fpm in a single container.
| Makes shipping it easier, especially with the PHP code
| (because both Caddy and php-fpm need access to the code;
| Caddy so it can serve static files and check for the
| existence of PHP files, and php-fpm to actually run your
| code).
| waynesonfire wrote:
| [deleted]
| treahauet wrote:
| Congratulations! This looks neat!
| seabrookmx wrote:
| So.. it's like gunicorn (pre-fork web server) but for PHP and
| built on top of Caddy?
|
| Looks neat!
| 0xbadcafebee wrote:
| So it's mod_php for Caddy, in reverse?
|
| The traditional idea is to build a plug-in for the parent
| webserver. By essentially "making a fork" of Caddy, if you want
| to add other plugins to Caddy and then incorporate them into
| FrankenPHP, it's a lot more work. If instead you ship a PHP
| plugin to Caddy, you can manage Caddy instead and mix and match
| different functionality in one place.
|
| But I guess it's heretical to suggest somebody use plugins in Go,
| if the whole idea is everything is a static binary.
| mike_d wrote:
| Early Hints breaks a lot of the common APIs (like FastCGI/FPM)
| where you are expected to have one request and one response. I
| don't know how Caddy specifically works, but I suspect that may
| be the reason for the fork.
| mholt wrote:
| Early Hints support was added to Caddy's proxy by Kevin
| Dunglas, the author of FrankenPHP. No fork required for Early
| Hints!
| mholt wrote:
| I don't think this forks Caddy. Rather, it is a Caddy plugin:
| https://github.com/dunglas/frankenphp/blob/main/caddy/caddy....
|
| It uses mainline Caddy:
| https://github.com/dunglas/frankenphp/blob/main/caddy/go.mod
| 0xbadcafebee wrote:
| Can I use an officially released build of Caddy and have that
| official Caddy executable load FrankenPHP?
| kdunglas wrote:
| Definitely! (using xcaddy and compiling PHP yourself, for
| now)
| [deleted]
| chrsig wrote:
| go does have some support for dynamically loaded shared
| libraries. I haven't used it, so I can't speak to how good it
| is, or any pitfalls.
|
| https://pkg.go.dev/plugin
| tomcam wrote:
| I love the idea but as far as I can tell there isn't a portable
| way to do plug-ins in go that works with windows, is there?
| francislavoie wrote:
| If you're talking about Caddy, its plugins are cross-
| platform, because Go (as long as you don't use CGO, or at
| least that your plugin that needs CGO also works on Windows).
| Read about Caddy's architecture here:
| https://caddyserver.com/docs/architecture
| password4321 wrote:
| PHP in .NET: https://www.peachpie.io
| [deleted]
| pbowyer wrote:
| Good. PHP-FPM needs a challenger as anyone who has tried to debug
| it or its pools knows. Or to tune it (so many modes, so many
| configuration options).
|
| Litespeed's PHP LSAPI [1] shows how good performance can be with
| other setups. It'll be great if FrankenPHP gets to the same
| state.
|
| 1. https://www.litespeedtech.com/open-source/litespeed-sapi/php
| apocalyptic0n3 wrote:
| PHP-FPM can be so unreliable too. It'll just go down randomly
| without any warning or logs at all. As you said, it's
| impossible to debug what happens there and all you can really
| do is setup monitoring to detect it went down and automatically
| restart it.
| xorcist wrote:
| That's interesting, in my experience php-fpm has been very
| dependable even in demanding situations where we migrate over
| to new backends without missing a request. PHP applications
| can be a different story, but php-fpm provides enough knobs
| to restart problematic applications on demand. It's probably
| that last part of a PHP stack I'd want to replace.
|
| Debugging application servers in production comes with its
| own set of difficulties, but I don't see how this one is
| worse than others. If anything, the ability to start new
| sockets without restarting the process is a plus.
| jijji wrote:
| PHP-FPM is very easy to debug. It's as simple as setting it
| up to use a listening socket in www.conf (located in i.e.
| /etc/php/8.1/fpm/pool.d) and then running a packet sniffer
| (i.e. ngrep) to listen on that socket, all messages back and
| forth are visible at that point.
| amq wrote:
| PHP-FPM has been extremely reliable in my experience.
| timw4mail wrote:
| So after looking at the slidedeck on the authors blog, I'm rather
| confused. How does FrankenPHP keep the code in memory if each
| request is in a separate memory space?
| marcofatica wrote:
| They're probably using PHP's built in opcache or something they
| rolled themselves OPcache improves PHP
| performance by storing precompiled script bytecode in shared
| memory
|
| https://www.php.net/manual/en/intro.opcache.php
| chx wrote:
| opcache is definitely on https://github.com/dunglas/frankenph
| p/blob/f97f56d45a403342b...
| kingkool68 wrote:
| See Preloading which landed in PHP 7.4
| https://stitcher.io/blog/preloading-in-php-74
| simlevesque wrote:
| Felicitation !
|
| Do you have any success story with this application server ?
| francislavoie wrote:
| Kinda early for that, isn't it? It's still in the experimental
| phase.
| codegeek wrote:
| I see a bit of C as well ? Also, do we need to use Docker ? I am
| very interested in trying but wanted to check.
|
| If it is Go, can I not just compile the binary and execute ?
| TheRealPomax wrote:
| When do things ever "just compile"? I assume the Docker image
| is because this is a pre-alpha and the docker image ensures
| that no one needs to go through hours of dependency/config hell
| because the docker image is set up with everything necessary
| already, letting you focus on alpha-testing this and reporting
| bugs.
| calvinmorrison wrote:
| typically I find CMake would do this, or Make, to verify
| dependencies.
|
| Coupled with a packaging system, like debian gives you, this
| is all pretty straightforward.
|
| I ran into this yesterday, and turns out I don't want to
| install docker just to build a program...
| TheRealPomax wrote:
| Right, but there are as many setups as there are potential
| users, so even if Debian works, that doesn't mean other
| linux flavours will work as easily, or flavours of BSDs,
| and then also Macs, and even WSL, or _even_ just plain old
| Windows.
|
| Having an "everyone gets the same thing, so no one wastes
| time on bootstrapping" solution is a perfect use-case for
| Docker. And then once the bugs have been found and fixed,
| and the code is production-ready, you can focus on
| documenting and scripting the setup procedures for the
| various operating systems.
| andirk wrote:
| As an aside, may I ask what people's opinion of running
| docker containers in prod is? The joke "But it works on
| my local--" "Then ship your local".
| francislavoie wrote:
| The big win of Docker for me is parity between dev and
| prod. I absolutely run on Docker in prod. It is not just
| a dev tool.
| francislavoie wrote:
| C is necessary because PHP is written in C. So CGO is used to
| interface with PHP directly from Go, from a Caddy plugin.
|
| Docker is definitely not necessary, but it is the easiest way
| to ship something that _just works_. Since you need a bunch of
| build dependencies to compile PHP, the installation steps are
| different for every distro to pull those in with whatever 's
| your package manager.
| k__ wrote:
| PHP is already FrankenPerl, and Perl FrankenAwk?
|
| What happened to the times where some crazy person would simply
| slap together an interpreter and call it a language?
|
| Somehow, language creation got more and more sophisticated these
| days.
| [deleted]
| mhd wrote:
| Really? Aren't there a lot of slapped together LLVM frontends
| these days?
| chx wrote:
| Looking at the forked PHP source https://github.com/php/php-
| src/compare/master...dunglas:php-... I do not expect
| compatibility issues.
| [deleted]
| nonoesp wrote:
| It'd be great to see how a Laravel app could run on FrankenPHP
| and see if there are speed gains.
|
| My current setup is a DigitalOcean Droplet with Nginx and php-
| fpm.
| some_developer wrote:
| Try Octane, it's the app server we were longing for.
___________________________________________________________________
(page generated 2022-10-14 23:00 UTC)