Live data from Hacker News

Show HN: FrankenPHP, an app server for PHP written in Go

frankenphp.dev

51–60 of 93 posts

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#51
post #47

Earlier quoted context omitted.

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…

Since it's not using PSR-7, does it mean that you could even run WordPress?

I haven't tested it yet, but yes it's a stated goal.

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#52
post #6

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.

Don't forget Zig, with Bun.

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#53

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 sugges…

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

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#54
post #28

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 sugges…

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?

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

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#55

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 ?

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.

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#56
post #48

Earlier quoted context omitted.

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…

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".

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.

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#57

Earlier quoted context omitted.

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.

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.

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).

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#59
post #33

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

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.

Been using php-fpm with nginx for many-many years (and with caddy since recently) and had zero problems with it.

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#60
post #53

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 sugges…

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

It is not good. I don’t know of any major projects that use it. Instead people: * compile in plugins

* run plugins as separate processes and expect them to implement a specific RPC api

Compiling in plugins is more practical in Go then it might be in another language, due to the regularity of the go build system.

Post reply on HN