Live data from Hacker News

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

frankenphp.dev

21–30 of 93 posts

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

#21

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 ?

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.

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

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

#23
post #19

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…

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.

Early Hints support was added to Caddy's proxy by Kevin Dunglas, the author of FrankenPHP. No fork required for Early Hints!

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

#24

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.

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.

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

#26

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

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

#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?

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

#29

Earlier quoted context omitted.

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.

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

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.

Post reply on HN