PHP8 Fibers Discussion

[marcellov7]

Have you already thought about the benefits of PHP8 and the Fibers feature? It could really be a boost for Slim.

[odan]

Hi! Here are some thoughts.

The introduction of Fibers in PHP 8 is indeed an exciting feature, allowing for more elegant cooperative multitasking. It has the potential to transform how we handle asynchronous operations in PHP.

However, it's essential to consider PHP's inherent shared-nothing architecture. This architecture means that each request starts with a clean state, without any shared state from the previous requests. While this model simplifies concurrency and reduces concerns about thread safety, it can pose challenges when implementing asynchronous features like Fibers.

That said, Slim Framework, being a micro-framework, is primarily designed to provide the minimal essentials to quickly build web applications. Its philosophy revolves around staying lightweight and leaving additional features to be handled by third-party libraries.

While Fibers offer a fresh approach to concurrency, it's worth noting that asynchronous functionality can already be achieved in PHP using libraries like AMPHP and react/http. These libraries have matured over the years and can be integrated with Slim or any other PHP framework if needed.

I have already blogged about this topic and made some performance tests. The results were impressive, but in practice it was hard to manage because everything (IO, database access) needs to be asynchronous then. But PHP itself is not build for that, and the support in the PHP community is not that big in this area.

In essence, while Fibers could be a boost for some projects, the integration of such features might be beyond the intended scope of a micro-framework like Slim.

[mikespub]

As a micro-framework the question should rather be:

is there anything in how Slim handles requests that would stop someone from using it as part of a larger application running on AMPHP/ReactPHP/Swoole/...?

In other words, if you created the app once and then let it handle requests concurrently, what would accidently leak between requests or block them unnecessarily?

The example I found for Slim 4 e.g. on https://discourse.slimframework.com/t/slim4-micro-services-reactphp-html-server/4914 still creates a new app instance for each request, which may work OK but hardly makes it "compatible"

Older experiments with Slim 3 like https://github.com/mbarquin/reactphp-slim show that (at that point) Slim required some tweaks to make it work as intended. How are we today (or tomorrow)?

[odan]

@mikespub As far as I know, there are no tweaks needed to make Slim 4 "compatible" with ReactPHP. It works if you create the Slim App instance as shown here:

https://discourse.slimframework.com/t/slim4-micro-services-reactphp-html-server/4914/2?u=odan

[mikespub]

Oops - sorry, somehow I missed the second version that does exactly that :-( Nicely done :-)

[odahcam]

Disclaimer: this might not be the best place to post this, but I couldn't find a good place in the forum

@odan Slim v4 works fine with ReactPHP HTTP server, I've shipped a few servers to production already, I just wish there was a cleaner way of using separate elements of Slim without using the App class. I love Slim's features but my architecture heavily rely on the container, a lot of middleware and some Slim objects, with a special middleware dispatcher I've created to track the multiple requests. The App itself is a little useless for me since I don't serve my application with the classic old approach, I don't need request parsers, I don't need emitters, I just use the app to trigger the middleware dispatcher and abstract some error handling in the end. I wish those concepts were a little more separated so it would make it easier to enjoy nice Slim features in a more modern PHP server. We'd love to have this taken into consideration for Slim 5.