61–70 of 93 posts
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.
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
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
Can I use an officially released build of Caddy and have that official Caddy executable load FrankenPHP?
Earlier quoted context omitted.
Can I use an officially released build of Caddy and have that official Caddy executable load FrankenPHP?
Caddy plug-ins are statically compiled into the server. Generally you need to build your own binaries if you’re using plugins. There’s an official script, xcaddy, to make that easy.
Earlier quoted context omitted.
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 an…
No one can feel 0.01s faster load time and there will be a dozen more things to tune in your app than shave that tiny bit off.
Earlier quoted context omitted.
Caddy plug-ins are statically compiled into the server. Generally you need to build your own binaries if you’re using plugins. There’s an official script, xcaddy, to make that easy.
Hard to think this method takes off as people are reluctant to run their own binary that can't be updated with the rest of the system which in turn gives less users to report bugs and blogs about usage/reviews.
I know you can using Nix for sure. I think Arch/pacman (Arch Build System) and Gentoo/portage (since it is source-based) also have this concept, but I’ve never used it. No clue about other package managers.
The downside is that package updates will require a recompilation, but you can use binary caches to centralise this slightly.
Earlier quoted context omitted.
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 an…
So, not for everyone, especially when you have to manage your own binary. No one can feel 0.01s faster load time and there will be a dozen more things to tune in your app than shave that tiny bit off.
It's true it's probably not for everyone though; the worker mode will not work with legacy apps that heavily use globals and statics, and works best with frameworks that have infrastructure in place to reset in-memory state on each request. Symfony and Laravel are set up for this, for example. API Platform as well, which the author of FrankenPHP himself authored.
The decreased latency means you can serve more requests with the same hardware, with less of an energy cost. That's a win-win. It's not simply about the user experience.
Also remember that loading a webpage often takes many requests. Every little bit shaved off of one request is multiplied. Add onto this that it supports 103 Early Hints which can tell the client to start loading static assets ahead of time, this dramatically reduces total page load times because it avoids the cascade (i.e. browser needing to wait to read the HTML to know what JS/CSS to load). That definitely has a noticeable effect to users.
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...
Earlier quoted context omitted.
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.
1. Most PHP frameworks are designed to have all state destroyed at the end of a request. I was trying to integrate a commercial ecommerce framework with something like Road Runner and another one that I forget the name of. The framework had a DI system which provides each module with its own private instance of all injected instances, so having a "worker" that doesn't "boot" everything each request sounded like a good idea (boot was expensive, and a lot of logic was storing module-specific state in module-private instances). I hit a few barriers inside the framework, but actually a lot of them were due to dependencies on PHP global state following state-of-the-art conventions and best practices. It lead to spooky side-effects like cache from one page view loading into the next, and worse. Getting frameworks to run in a loop in PHP can often lead to sharing state in code that was designed in a way that state is assumed to be destroyed soon.
2. PHP depends on lots of unexpected things. If you're deep into language internals already you probably know this however. I was putting symfony2 into a PHP Unikernel a long time ago, and it drove me a bit crazy because everything in the file system, SAPI, locales, etc... it was all missing bridges to something it expected the OS to provide. I ended up making an immutable FS with Nginx and PHP all static linked to each other, but it was really just enough for a POC, a real production ready env would have been a lot more effort. The point is, PHP has a lot of unexpected "hooks" into environments it has grown up around that might be well hidden.
Anyway, really cool project and I like the concept of using a SAPI, I think it has big potential.
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.
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".