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

https://frankenphp.dev

by kdunglas • 4 years ago

368 83 4 years ago

frankenphp.dev

seabrookmx• 4 years ago

So.. it's like gunicorn (pre-fork web server) but for PHP and built on top of Caddy?

Looks neat!

timw4mail• 4 years ago

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• 4 years ago

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

chx2• 4 years ago

opcache is definitely on https://github.com/dunglas/frankenphp/blob/f97f56d45a403342b...

kingkool68• 4 years ago

See Preloading which landed in PHP 7.4 https://stitcher.io/blog/preloading-in-php-74

green-salt• 4 years ago

I'll have to try this out!

nobleach2• 4 years ago

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.

fideloper3• 4 years ago

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• 4 years ago

Don't forget Zig, with Bun.

nobleach2• 4 years ago

Ah yes. I've had my eye on that as well!

simlevesque• 4 years ago

Félicitation !

Do you have any success story with this application server ?

francislavoie6• 4 years ago

Kinda early for that, isn't it? It's still in the experimental phase.

chx2• 4 years ago

Looking at the forked PHP source https://github.com/php/php-src/compare/master...dunglas:php-... I do not expect compatibility issues.

tiffanyh• 4 years ago

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.

mholt3• 4 years ago

With this you don't need FastCGI. FrankenPHP is simpler and less complex: just run it directly from your Caddy web server.

fideloper3• 4 years ago

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• 4 years ago

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.

nickjj2• 4 years ago

What about having 1 Dockerfile but run php-fpm in 1 container with nginx in a 2nd container?

This pattern is common for background workers too, such as running gunicorn + celery in separate containers (Python tools) but the same image is used for both. You can change the CMD at runtime by overwriting it (for example the `command` property in Docker Compose and Kubernetes).

This avoids needing to hack around things at the Docker level to install an init system and it gives you a way to split things out at runtime so you individually scale and log them as needed.

It does mean a change in your app would restart nginx since the image would change for both but this isn't that big of a deal. If that was a deal breaker then you could create separate images for each one to still avoid an init system running in your container.

CoolCold• 4 years ago

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.

nonoesp• 4 years ago

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• 4 years ago

Try Octane, it's the app server we were longing for.

0xbadcafebee2• 4 years ago

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• 4 years ago

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.

mholt3• 4 years ago

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

mholt3• 4 years ago

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

0xbadcafebee2• 4 years ago

Can I use an officially released build of Caddy and have that official Caddy executable load FrankenPHP?

tomcam• 4 years ago

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?

francislavoie6• 4 years ago

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

chrsig• 4 years ago

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

philosopher1234• 4 years ago

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.

codegeek• 4 years ago

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 ?

TheRealPomax3• 4 years ago

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• 4 years ago

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

francislavoie6• 4 years ago

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.

treahauet• 4 years ago

Congratulations! This looks neat!

password4321• 4 years ago

PHP in .NET: https://www.peachpie.io

k__• 4 years ago

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.

mhd• 4 years ago

Really? Aren't there a lot of slapped together LLVM frontends these days?

bdg3• 4 years ago

In general I wish the "culture" of programmers would differentiate the "language" itself from the "things it is linked with" and "the ecosystem of available packages". We get a lot of pointless arguments where person 1 is talking about case 2, and another is thinking about case 3.

PHP, Ruby, and Node all use things like cURL or the same PCRE regex lib, but I've seen uninformed or misguided arguments about "how Node is better than PHP at making HTTP requests because of axios", and not "I like Axios more than Guzzle3".

jeffersonheard• 4 years ago

If this isn't pronounced Frankenphip I will be disappointed.

pbowyer• 4 years ago

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• 4 years ago

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.

amq• 4 years ago

PHP-FPM has been extremely reliable in my experience.

jijji2• 4 years ago

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.

xorcist2• 4 years ago

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.

whenlambo• 4 years ago

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

habibur• 4 years ago

My experience had been the opposite.

PHP-FPM had been more resilient than the other services I run. Rock solid.

noduerme• 4 years ago

Have to chime in with others... FPM has definitely been the most reliable and easily tweakable system I've had in almost 20 years of PHP work, particularly since I run a lot of legacy code off the same server in different versions of PHP.

I feel like problems with monitoring may be down to lack of proper logging or experience. It's not like FPM is going to leak more memory than your code would in other running contexts. It doesn't "go down" since it spawns a new process for every request. My cold read is that there's something wrong with the code you're running, not with FPM.

abrztam• 4 years ago

What is the difference between this and Roadrunner? It seems to do the same stuff.

https://github.com/roadrunner-server/roadrunner

floppydisc• 4 years ago

no. 1 feature: goofier branding

kdunglas3• 4 years ago

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• 4 years ago

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

rustatian-me• 4 years ago

Hey @kdunglas :) Nice project :) I just wanted to add a few notes:

Roadrunner executes php-cli and connects it to its web server through GRPC;

RR communicates with the PHP process via pipes (stdin/out/err) via our protocol (similar to the IP protocol, we also have a tcp/unix-socket options and shared memory is coming soon). The RR server itself then has various options to connect to the world:

- gRPC (w/o the need to install the `gRPC-php` extension), HTTP (with a lot of different middleware), HTTPS, fCGI. - Queues: kafka, rabbitmq, sqs, beanstalk, nats (with like priorities and so on) - KV/noSQL: memcached, redis, boltdb, memory. - Workflows: Temporal.

I might forget smt, but the main idea is to have a very extensible server. With very little knowledge about Go, you may extend it with your plugins and build your RR binary. Or even embed the RR server into your Go application (https://github.com/roadrunner-server/roadrunner/tree/master/...).

NorwegianDude• 4 years ago

Not really sure what the pros of this is. Simple to deploy in a docker image? Didn't know that was an issue. I guess performance also takes a hit, and that worker mode is a good amount slower than Swoole?

Some benchmarks against mod_php, nginx+php-fpm and swoole would be nice.

sica07• 4 years ago

Not a benchmark but some helpful stats can be found in this slide: https://speakerdeck.com/dunglas/frankenphp-a-modern-app-serv...

p4bl0• 4 years ago

If I understand it correctly the idea of worker mode is to have a persistent application running where you can have the same objects in memory from one request to another rather than relaunching the app from scratch (requiring files, constructing objects, fetching data from some database) again for each request.

Is that it?

borancar• 4 years ago

This is amazing, and way more advanced than what was there. Going to definitely use it on the next project.

Previously, there was https://github.com/deuill/go-php which was PHP5 and PHP7, but you needed to build PHP with ZTS. I had to forke it to focus on PHP5 and bring some improvements - my primary goal was to port some legacy PHP over iteratively via the Strangler pattern. If it can still be useful to some, the fork is here - https://github.com/borancar/go-php

b_sanchez• 4 years ago

I was in the conference (20221014, afup 2022), where frankenphp was released live. The conference was really interesting and answer many (if not all) of the questions raised in comments.

I'v checked and unfortunately the video recording is not available for now, I will post a link here as son as available.

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

Related Stories