Last saturday I meet a new hype: "React" also known as "node.php". Basically it's the same idea than node.js but built with PHP instead of javascript. [...] Basically I want to create a database connection pooling. It's one of the things that I miss in PHP. I wrote a post here some time ago with this idea with one exotic experiment building one connection pooling using gearman. Today the idea is the same but now with React.

He includes the sample script, also including the line to add to your composer.json file to install React and the SQL to create the sample tables. The script makes a PDO connection and assigns it to the pool, an instance of his "CPool" class. If you want to try it out, you can find the code over on github.

All hail Node.js! Boo PHP! Except there are various things where PHP is better than Node…

His five reasons are:

• Easier to find hosting
• It's easier to get started with PHP
• If your PHP code breaks, it doesn't bring your whole server down
• PHP processes are short lived
• Bigger standard library

There's a few comments on the post already, one noting that some of the points could be turned around to make PHP fall more on the "bad" side.

Recently on a project I had to make changes to a underlying portion of the sites architecture to move sessions in Zend Framework from file storage to database storage. However this affected a piece of the architecture. Node.js, which manages all our real time interaction, looked at sessions at the file level. This was quite a easy transition for the function as it was abstracted away in a function call so the theory was to just replace the function "guts" with a new component.

The post shows the code he came from (which pulled in the PHP session file and extracted the session data manually) over to a new database-based version that selects from the SESSIONS table and pulls out the data. It's based on the table having an "id" column and the Zend_Auth namespace it uses.

For a PHP developer, asynchronicity is the most puzzling aspect of the Node.js runtime. It's simply a new way to write programs. And once you pass the first learning steps, event-driven programming opens a world of possibilities PHP programmers would never dream of. I'll try to explain you how it works, but first, let's talk about pasta.

In his "pasta" example, he shows how a typical PHP application would make a "Pan" object, call a "warm" action, "add olive oil", etc. All of this happens in sequence, though and takes 29 "minutes" to complete. To help things along, he implements an "EventLoop" class that handles tracking the timing and includes two methods to execute callbacks and delayed methods. He expands on this example with asynchronous objects and method calls to handle multiple things at once. He relates this to what Node.js offers - a built in event handling system, an included EventLoop object and native blocking I/O operations.

Both environments have their strong points. Node.js is very fast and flexible, but PHP has a lot more mature tools and libraries available. So in a lot of projects it is hard to choose between the two. But now you might not have to. DNode is a remote method invocation protocol originally written for Node.js, as the name probably tells. But as the protocol itself is quite simple, just sending newline-terminated JSON packets over TCP connections, implementations have started popping up in other languages. You can talk DNode in Ruby, Perl, Python, Java, and now PHP.

He includes a quick example of both sides of the messaging - a simple server on the Node.js side that looks for a DNode request and using the dnode PHP client to connect to it (and return the input number multiplied by 100). He also includes a method that allows for bidirectional communication with a service that converts from Celsius to Fahrenheit.

Zend Framework which is PHP based and Node.js which is JavaScript based don't have a common connection to pass data in a bi-directional nature. I was tasked with building a bridge of sorts that would utilize existing information from Zend Framework with the latest release of Socket.io's authorization mechanisms. (If you don't do this then arbitrary connections can happen and will be authorized.)

He starts with the code (on the Node.js side) to create a simple HTTP server to listen for the requests from the Zend Framework application. He gets into the details of how that all works before moving to the other side - a simple update to the authentication to store a session cookie with the information that is passed, via Socket.io to the waiting Node.js server for handling.

We use sessions when we want to preserve certain data across subsequent accesses. PHP allows us to use different handlers when we're using sessions. The default one is filesystem, but we can change it with session.save_handler in the php.ini. session.save_handler defines the name of the handler which is used for storing and retrieving data associated with a session. We also can create our own handler to manage sessions. In this post we're going to create a custom handler to store sessions in a node.js service.

He includes the full code you'll need (also here on github) to make a custom session handling class on the PHP side and some simple unit tests done on the Node.js side to ensure for proper handling and garbage collection.

The inspection of the error logs is a common way to detect errors and bugs. We also can show errors on-screen within our developement server, or we even can use great tools like firePHP to show our PHP errors and warnings inside our firebug console. That's cool, but we only can see our session errors/warnings. If we want to see another's errors we need to inspect the error log. tail -f is our friend, but we need to surf against all the warnings of all sessions to see our desired ones. Because of that I want to build a tool to monitor my PHP applications in real-time.

The service will work similar to a chat server, sending messages one at a time to the remote server via a web client (HTML5-based) and some backend PHP. He includes all the code you'll need to create the HTTP and web socket server as well as the web client (with some Javascript) and some example server-side PHP. It throws an exception and catches it to send to the waiting Node.js server. A screencast is also included showing the full process. You can get the complete code for this example in this repository on Gonzalo's github account.

NodeJS is a tool designed to provide an easy way to build scalable network programs. By using the I/O capabilities of NodeJS, I have built a simple TCP server that writes log messages to the OS X terminal (via STDOUT).

He shows how to take his example script and run NodeJS as a server on a local port (like 8003). You can then use his log writer plugin in your Zend Framework app to write directly to the waiting NodeJS server.