Why not focusing only on prod experience?

[shouze]

Hi @Pierstoval very nice project!

I had the same idea few months ago 😉.As we're currently building a project on which we were deploying on AWS ECS, I didn't want building & deploying heavy containers. I can share you our experience because maybe it can orient some choices about your project, depending on your true goals behind it.

As Symfony cli wasn't recommanded for production, we where using it anyway to deploy on our staging/preproduction environments because this was pretty handy: we didn't have to take time on this infra part, on this bootstraping project we wanted to focus on user features.. This was working pretty well... except few drawbacks:

1. Symfony cli detection systems is great but only for development environments. I don't want it on production this is useless overhead.
2. I wasn't able to make my infrastructure fully immutable (read only containers), mainly because it generates fpm configuration at runtime. I prefer from far writing my own configuration and package it by myself into the container image.
3. Some crashes and closed source: after some time the main process was not able to communicate with fpm and it was neither frankly crashing neither restoring a functional state by itself. Also I'm not sure if in Symfony cli fpm runs as a child process of this main process or not and which respawn strategy is in place.

Past week, I've migrated our ECS infra to AWS Lambda so I don't nee anymore such http to fast-cgi proxy at the moment. But... since a lot of people run php in containers and have no other official alternative than running php as an apache module on production (if they use official php images, otherwise they can always try nginx/php-fpm couple but needs to share or copy same filesystem, not very sexy nor simple & elegant setup).

I'm pretty sure there's a big interest for a robust, performant, secure & lightweight http server solution on top of php-fpm that fits well for php production deployments in docker containers. this is why I wanted to share you my mindset on this subject.

[Pierstoval]

After I started Rymfony, I stumbled upon your project at some point 😄

It looks very promising indeed, my goal with Rymfony is to do the same thing as Symfony CLI in the first place, and then make it more customizable than the Symfony binary.

I'd like to make sure one can move from Symfony CLI to Rymfony without any change (hence why I have the same command names and options). Once they have migrated to Rymfony, they will be able to use more features.

I see in your project that you didn't implement the fastcgi proxy yet. Rymfony has it, even though it's not perfect (has tons of issues, hence the current open issues on the repository).

I'm not available currently (was hardly working, now I'm on holiday, I'll continue the work later), but my next milestone is to refactor the php:list command, it's quite tough since I'm still a beginner with Rust.

If you feel okay with working on the current issues with the HTTP layer, feel free to contribute!

Since we're using Rust and the project is open-source, I think we can clear the path to optimize a lot of stuff in order to make Rymfony prod-friendly 😉

However, you might note that I am not considering anything related to Docker for now. I prefer to let users find their own way to use Rymfony with Docker, just the same way you did use Symfony CLI with DOcker (that's also something I do on one of my projects: bundle a docker image with Symfony CLI and use it as HTTP entry point, but it indeed has drawbacks, and I have to restart the server every once in a while...)

[Pierstoval]

@shouze I don't know if you followed the last months of development, but there were some improvements on the php:list command, and the FastCGI implementation should be okay now!

I added some elements in the roadmap (and in issues) to show what I'd like for Rymfony, and supporting read-only filesystems is a good idea, even though it'll need some tweaks (especially because we need to write information about the server's PID, FPM config, servers list, PHP versions, etc.).