On his blog today Francois Zaninotto has a post that aims to introduce those with a PHP background to how Node.js works. In this first part of his series, he tries to explain the idea of event-driven programming - parallel processing of different parts of an application based on some action taken in the code.

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.

Henri Bergius has a new post to his blog today sharing details about a messaging protocol that can help PHP and Node.js play together nicely - DNode.

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.

Anthony Wlodarski has put together a new post to his blog talking about authenticating a Zend Framework app against Node.js with the help of the Socket.io component for handling credentials.

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.

Gonzalo Ayuso has an interesting new post today looking at how to go cross-technology in your application and store your PHP sessions in a basic Node.js instance.

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.

Gonzalo Ayuso has a new post to his blog today looking at a method you can use for real-time monitoring of your PHP applications with a combination of websockets and Node.js. The trick is to handle the PHP errors and send them over to a Node.js server for processing.

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.

In an interesting post to his blog Rob Morgan shows how you can log in to a terminal from a Zend Framework application (on OS X) with the help of NodeJS.

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.