Hey,
So one thing that keeps me up at night (for a while now) is resisting the
urge not to venture down a rabbithole of writing code which is loading the
PHP runtime from Rust/Golang (up to MINIT)
And then at RINIT time, we load the right SAPI and pass across the SERVER
vars that's needed for it..
Here is a use case example. Golang concurrency model on the front, and it
can execute PHP CLI SAPI or HTTP SAPI on the back.
Moreover if you're looking at reasons people have previously or currently
moving away from PHP to other languages, due to limitations like pure async
or concurrency stuff .. then perhaps a new FRONTEND which can execute the
PHP runtime on the backend would be solving some things.
I appreciate this isnt a unique idea and maybe someone else from internals
has raised this before .. but I wanted to raise the topic to check the
viability of this if it is possible, and what blockers are in our way,
currently, if it's not even possible to share SAPI calls from another
language runtime.
Thanks for listening,
Paul Dragoonis.
I wrote this on my phone, so excuse typos and poor grammar :)
Hey,
Am 14.08.22 um 14:29 schrieb Paul Dragoonis:
Hey,
So one thing that keeps me up at night (for a while now) is resisting the
urge not to venture down a rabbithole of writing code which is loading the
PHP runtime from Rust/Golang (up to MINIT)And then at RINIT time, we load the right SAPI and pass across the SERVER
vars that's needed for it..Here is a use case example. Golang concurrency model on the front, and it
can execute PHP CLI SAPI or HTTP SAPI on the back.Moreover if you're looking at reasons people have previously or currently
moving away from PHP to other languages, due to limitations like pure async
or concurrency stuff .. then perhaps a new FRONTEND which can execute the
PHP runtime on the backend would be solving some things.I appreciate this isnt a unique idea and maybe someone else from internals
has raised this before .. but I wanted to raise the topic to check the
viability of this if it is possible, and what blockers are in our way,
currently, if it's not even possible to share SAPI calls from another
language runtime.
I'm not sure about the internals you mention. Are you looking for
something like https://roadrunner.dev/
"RoadRunner is a high-performance PHP application server, load-balancer,
and process manager written in Golang."
Best regards
Thomas
Moreover if you're looking at reasons people have previously or currently
moving away from PHP to other languages, due to limitations like pure async
or concurrency stuff .. then perhaps a new FRONTEND which can execute the
PHP runtime on the backend would be solving some things.
There already are concurrent and asynchronous solutions for PHP: Swoole,
Amp, React, etc
I think part of the reason they aren't more popular is simply that
they're young compared to the language itself - one of PHP's big
advantages is its thriving ecosystem of existing software, frameworks,
and libraries. A lot of those need modifying to take advantage of a
concurrent / asynchronous environment, or even to run safely at all,
because they assume PHP's traditional "shared nothing" model.
By contrast, the ecosystems of node.js, Go, etc have been written with
concurrent / asynchronous already "baked in", so are fully ready to take
advantage of it. If you need to rewrite large chunks of your codebase to
use an async-friendly framework anyway, it's less of a leap to switch
language completely.
Regards,
--
Rowan Tommins
[IMSoP]