u/sibidharan

I am working on ZealPHP, a coroutine native PHP runtime built on OpenSwoole, an OSS project, MIT, to swap the PHP execution model to make it asynchronous, have a legacy app CGI bridge that works like PHP-FPM with Apache Parity. The framework took shape with PHPStan Level 10, and you can see it here: https://php.zeal.ninja, a full stack framework that runs the HTTP server, WS server, does SSE, SSR, all the PHP you love and know. Still under development, but useable.

Github: https://github.com/sibidharan/zealphp

If you have the question Why ZealPHP? - https://php.zeal.ninja/why-zealphp

And if want to know the tradeoffs and design tax of ZealPHP - https://php.zeal.ninja/design-tradeoffs

So that the project makes sense in first place!!! It is a pure experiment, and if it works, it may help so many projects become async with minimal rewrite, thats the idea!

When I was at a point to move one of the big apps we use internally, I realised MongoDB PHP driver is the biggest blocker and it cant do Async!

So I am experimenting with this https://github.com/sibidharan/zealphp-mongodb (actively developing) to make MongoDB Asynchronous with Rust Drivers under the hood! The idea is: Bridges the official Rust MongoDB driver (mongo-rust-driver/tokio) into OpenSwoole's coroutine system. Drop-in replacement for mongodb/mongodb.

v0.1.0 is useable with full API parity with official mongodb PHP drivers!!

Now, help me understand if this is good, bad or worst? And what are the caveats I need to take into account?

I just want to make the PHP we all love Asynchronous keeping it FPM like (I did it almost I believe), and use MongoDB in it (still working on the rust port, adding more and more features comparing https://github.com/mongodb/mongo-php-driver ).

Or if there is an existing solution and I am pointlessly wasting time, guide me towards it!

I'm building ZealPHP, an open-source PHP framework on top of OpenSwoole. MIT licensed, alpha but usable.

Not trying to replace Laravel/Symfony. Not another MVC framework experiment. The goal is to modernize the traditional PHP request model itself.

In the classic LAMP / PHP-FPM model, Nginx/Apache forwards the request to PHP, PHP handles it, the process context dies. Simple and reliable — but every "modern" feature your product needs (WebSocket, queues, Redis for shared state, cron, SSE streaming) becomes a separate moving part. Six services, six failure points, six config files.

ZealPHP explores a different model: PHP runs as a long-running OpenSwoole-powered runtime and natively handles HTTP, WebSocket, SSE, sessions, shared memory (OpenSwoole\Table), timers, task workers, and coroutine-based I/O — all in one php app.php.

Mental model I'm aiming for: keep the simplicity PHP devs liked from the LAMP era, give PHP a modern async runtime.

What's in the repo:

• ~117k req/s text, ~106k req/s JSON on 4 workers with full PSR-15 middleware stack (CORS, ETag, sessions, routing). Methodology and reproduction scripts are in PERF.md — happy to be told where I'm wrong.
• Legacy code compatibility: session_start(), header(), $_GET, echo all work as expected inside coroutines via uopzoverrides.
• WordPress runs unmodified on it via a CGI worker (Apache mod_php compat layer). Zero WP code changes. That's the real test for whether the migration story holds.
• Built on OpenSwoole 22.1+, PHP 8.3+

Learn section — a handcrafted step-by-step where you build a real Personal Notes + AI Chat app using ZealPHP, htmx, server-rendered PHP components, sessions, notes CRUD, AI chat, and real-time sync. Trying to teach the framework through a realistic app, not toy examples.

Links:

• Site: https://php.zeal.ninja
• Learn (build a real app): https://php.zeal.ninja/learn
• Migration ladder: https://php.zeal.ninja/migration
• WordPress on ZealPHP: https://php.zeal.ninja/legacy-apps
• Repo: https://github.com/sibidharan/zealphp

What I'd actually like this sub to weigh in on:

1. Does the "modernized LAMP request model" framing make sense, or does it muddy the pitch?
2. Are the PHP-FPM-vs-OpenSwoole-runtime claims fair, or do they overclaim?
3. Does the gradual legacy migration idea feel practical to people who've actually maintained big PHP codebases?
4. Is htmx + server-rendered PHP components a sound teaching direction, or am I betting on the wrong horse?
5. What would make you trust — or distrust — a long-running PHP app runtime in production?

Honest about where it is: alpha, v0.2.x, APIs may shift before 1.0. Not asking anyone to put it in production tomorrow. Asking whether the architecture and migration approach are sound before I push for v1.0.

Roast welcome.