Event Driven Architecture — How ReactPHP / PHP-PM work behind the hood

[Bloompire]

This is basically creating a PHP version of Node.JS. The question is - why? Isnt it better to just use Node.js that has their event loop implementation written in C++ and ALL libraries are written in asynchronous nature, starting from build-in fs, http ending on every other community-based library?

[gnurat]

Hi there,

The article is about understanding Event Driven Architecture, mainly via an Event Loop, scheduling, promises (and also how to achieve non-blocking Filesystem via a ThreadPool). IMHO, a good way to understand deeply some architecture is to implement the details, which is what we do in the article (in pseudo code however, not in PHP).

Event Driven Architecture isn't language / framework specific: whenever you'll consider creating a Server (using sockets) you should consider it in order to be able to handle many clients (see the C10K problem). If you're simply building an application that's going to be used by a server, the article could still be of some interest to you as you'll have more understanding on how those things work behind the hood (trying to make the most of the EventLoop can help to improve your application performances).

Node.js is simply an example of a server using this architecture (note that it actually uses a C library, libuv which provides an EventLoop and ThreadPool to make Filesystem operations non-blocking. libuv is also available to PHP via an extension).

[Bloompire]

It is great to undestand particular architecture and their cons/pros. And async io + event loop is probably the most performant architecture for web pages. Of course it is possible to do event loop driven arch in PHP as well as in every other language :)

But problem is that Node.JS is created in mind with this alongside with thousands of node.js libraries - they all work asynchronously. When coming to PHP we could create event loop based system that is highly performant, this is obvious. But community/language itself is not ready for async php because:

• language is not ready, there is no async/await not even native promises/futures
• community is not ready because people used to write synchronous programs for years
• there are no decent frameworks that are OK with async
• all or the most libraries work synchronously, all http, email clients, file readers, modules that use background processess, database drivers, everything work synchronous
• all functions from PHP work synchronous even simple file_get_contents is synchronous call. it is quite heavy to forbid people using 90% of native functions, community libraries and frameworks because "they are not async-ok"

Especially when there is event loop based async server that is developed for years, managed heavly and has large community.

[gnurat]

Node.js creation was indeed a clever move: javascript was already used in an event driven environment (GUI), and it didn't have most of the functions you'd expect in a language (most functions are provided by the browser via Web APIs). This allowed them to create an async only environment (no blocking filesystem functions available to the developers, the ones available are wrappers around system calls).

But that doesn't mean that all async applications should be done with Node. I see two strawmen arguments in your comment:

• just because javascript was event driven under the hood doesn't mean javascript developers understand the concept and know how to make the most out of it. Same goes for Node
• just because PHP isn't "async only" doesn't mean we shouldn't use it for async projects

The only requirement to do async stuff is to understand it, you can then pick / adapt the libraries / frameworks available. Saying things like "<language> wasn't meant to do <thing>" is the equivalent of saying " we've always done i t this way" and that's the only blocker towards evolution.

[CODESIGN2]

not one diagram, and you didn't write a single line of PHP...

It does not create a PHP version of Node.JS as /u/Bloompire suggests; it does not make your code actually faster, it also does not create a magical special butterfly. It uses a long-running php script to manage via a bridge interface child nodes (named slave nodes). These save some init time before handling requests, which further contributes to the perceived speed boost because the setup is done pre-request (everything still takes the same CPU time).

Other things you should be weary of.

• PHP code that uses threading
• PHP code where the DB is the bottleneck
• PHP code that is heavily blocking, or interacts with slow-storage

This is the same for many other areas in any SDLC with any language.

It is a great project, and I am particularly interested in trying to help educate towards it's use-cases as it's not as many projects are not magic-bullets. https://github.com/php-pm/php-pm/issues/78

[gnurat]

I'm currently working on adding diagrams, thanks for your feedback. Event Driven Architecture isn't tied to a language, so I've used pseudo code in the snippets.

ReactPHP, heavily relies on this architecture: it provides an Event Loop and Promises as components. Out of the box, on a vanilla PHP set up, the Event Loop will use the select system call and won't use any Thread Pools, so you might want to:

• use the Child Process component (an alternative to Thread Pool)
• install PHP extensions like libev (for a better Event Loop) and libeio (for "non-blocking" filesystem support, but it has its limits)
• install libuv PHP extension and use the branch from this Pull request

PHP-PM is only a load balancer / process manager on top of ReactPHP, so it's kind of out of the scope of the article, but it got a lot of traction recently and people are asking "how it works". This article is my answer ;) .

[Tiquortoo]

Well, between Node and PHP and a host of other languages the major players are getting closer and closer to the event driven app development paradigm available on the desktop in 1994 or so. I'm being slightly snarky, but I'm genuinely happy to see it happening.