In the latest post to his site Gonzalo Ayuso shares some of the results of his "playing with RabbitMQ, PHP and node", creating a queue system that both languages could talk to easily.

I need to use RabbitMQ in one project. I’m a big fan of Gearman, but I must admit Rabbit is much more powerful. In this project I need to handle with PHP code and node, so I want to build a wrapper for those two languages. I don’t want to re-invent the wheel so I will use existing libraries (php-amqplib and amqplib for node).

Basically I need to use three things: First I need to create exchange channels to log different actions. I need to decouple those actions from the main code. I also need to create work queues to ensure those works are executed. It doesn’t matter if work is executed later but it must be executed. And finally RPC commands.

He goes through some of the basics of using RabbitMQ , showing the code for each of the languages - pushing a new value into the queue, registering workers, creating Queue builders and using an exchange and receiver to process the message. The post finishes with the last piece in his requirements: creating the functionality to handle RPC commands to get an answer back from the queue.

The QaFoo blog has written up an interesting post looking at languages and scalability and some of the constraints that can come along with them.

Micro-Services or any set of small services are common again right now. While it can make a lot of sense to use a dedicated service for a well defined problem those services are sometimes used just to play with a different server software. While it is pretty obvious for most that selecting the right database is important the same is true for selecting the right language (virtual machine) for the job.

There are different types of services or server applications where different types of virtual machines (executing the opcodes / bytecode of the compiled source code) make more or less sense. What are the criteria we should base such a decision on and which language should we choose when?

As their primary work is related to PHP, they focus in on it. They talk about why PHP has become such a popular language (the "LCoDC$SS" acronym) and why it fits in with HTTP's statelessness perfectly. On the flip side, they also talk about when it doesn't make sense to use PHP - mostly centering around what would take long-running PHP processes. They then compare this to a similar setup with other languages like Node.js, Go and Java (and how well those scale themselves).

The SitePoint PHP blog has a new tutorial posted introducing you to Elixir, the "Laravel way" of working with assets in your application and making it easier and more unified.

In today’s web applications, we use a wide variety of tools to speed up the development workflow while keeping the code base as lean as possible. [...] One such type of tool are preprocessors for CSS and JavaScript. [...] Besides preprocessors, there are also many tasks we as developers often have to do, including linting JS files, testing, concatenation, minification, just to name a few.

All this led to the creation of JavaScript-based task runners like Grunt and Gulp. [...] Gulp syntax is clean and easy to use, but there’s always room for doing things the easier way. Laravel 5 introduced Elixir: a Node.js based tool developed by Jeffrey Way, which manages our Gulp tasks the easy way.

They start with the requirements you'll need to get Elixir up and running, including Node.js and Gulp itself (it's a "frontend" for it, not a replacement). They talk about where Elixir assumes your assets will live and some examples of:

• Compiling Less files
• Compiling CoffeeScript files
• Compiling multiple files at once
• Using different source and output directories
• Concatenation files

...and much more. They also show how to perform Jade->Blade compilation for templating and how to configure Elixir to match your needs. The post ends with a more "real world" example with a full site structure, how to run the tasks and some more advanced topics (like custom tasks and using the assets in Blade templates).

The SitePoint PHP has posted an interesting tutorial describing a Node.js frontend workflow without Node.js, instead using PHP tools to replace the Node.js functionality needed for the build.

If you’re intimidated, exhausted or irritated by Gulp, Grunt, NPM, Yeoman, and all the other NodeJS tools that aim to help but often do the opposite, a good asset management workflow is possible in PHP, and this tutorial aims to prove it. In this article, we’ll go through a NodeJS-free PHP front end asset management setup.

He uses three tools to create the build process: BowerPHP for installing assets, markstory/mini-asset for minification and Robo for automation. He sets up a Homestead virtual machine instance as a testing ground first then creates a basic Slim-based application from the slim3-skeleton package. He gets the necessary tools installed via Composer then gets into the details of the process. He adds (Twitter) Bootstrap into his assets, shows how to set up the minification and creates a Robo task to watch the CSS for any changes. This task then re-runs the minifaction on the CSS and created the condensed version automatically.

in response to the previously posted Node.js vs PHP "Smackdown" article on the SitePoint Web blog, PHP blog editor Bruno Skvorc and an author from the SitePoint Javascript channel, James Hibbard, come back with their own rebuttal to some of the points made in the previous article from a more "PHP perspective."

In SitePoint's recent PHP vs Node.js Smackdown, Craig Buckler pitted these development disciplines against each other over a series of ten challenges, to determine which is the overall winner. As Craig notes in the article, these comparisons are always somewhat controversial. As a fun followup, we asked Bruno Skvorc (SitePoint's PHP editor) and James Hibbard (one of SitePoint's JavaScript editors) to provide a commentary on each of the rounds.

For each of the rounds, they start with a summary of the related findings by Craig in the first article and share comments from both Bruno and James. With his slant towards Javascript James often agrees with what the original article stated but Bruno usually disagrees or adds comments in to clarify the PHP side of the situation (from a more insider's perspective).

The SitePoint Web blog has posted a "smackdown" comparing two popular languages, PHP and Node.js, based on several different points.

The web is ever-changing technology landscape. Server-side developers have a bewildering choice of long-standing heavy-weights such as Java, C, and Perl to newer, web-focused languages such as Ruby, Clojure and Go. It rarely matters what you choose, presuming your application works.

But how do those new to web development make an informed choice? I hope not to start a holy war, but I’m pitting two development disciplines against each other: PHP and Node.js.

He goes through ten "rounds" of evaluations on various points including how easy it is to get started, help & support options, development tools available and hosting & deployment options. In the end, it's his opinion that the winner overall (it was close) is Node.js. However, he does end with one word of advice:

My advice: assess the options and and pick a language based on your requirements. That’s far more practical than relying on ‘vs’ articles like this!

Frank de Jonge has posted a tutorial to his site showing how you can render React.js templates server-side in PHP. He makes use of the V8JS extension to execute Javascript inside of PHP and echo out the rendered result.

The last couple of months I've been working with ReactJS quite extensively. It's been a very rewarding and insightful journey. There is, however, one part that kept coming back to me: server-side rendering. How on earth am I going to use ReactJS when I want to render my templates on the server? So, I sat down and looked at the possibilities.

He suggests two options, running a small Node application or using the V8JS extension, and opts for trying the second option to meet his needs. He talks about the "why" of rendering server-side JS and gives a brief introduction to V8JS and the workflow he'll follow to use it. He helps you get this library via Composer to make working with it easier and provides an example of how to use it. After trying out this method, he then goes back to option #1, the small Node application (what he ended up choosing). He walks through the setup of this application, showing how to set it up inside a Lumen application and using Express to output the generated templates and data. He then hooks this into the PHP application via a simple HTTP client grabbing the results and pushing them back out to the page.

Gonzalo Ayuso has a quick post to his site showing you how to make a "PHP dumper" for websocket connections based on a simple Silex application.

Another crazy idea. I want to dump my backend output in the browser’s console. There’re several PHP dumpers. For example Raul Fraile’s LadyBug. There’re also libraries to do exactly what I want to do, such as Chrome Logger. But I wanted to use Websockets and dump values in real time, without waiting to the end of backend script. Why? The answer is simple: Because I wanted to it.

He shows how to create a simple socket server (with Express in Javascript) and the basic Silex application with a "DumperServiceProvider" added in that will handle returning the debugging data back to the waiting client. He connects the Silex application with the websocket and shows the code to listen for new messages on the socket and display them back out to the browser. You can see an example of the end result in this video on YouTube.

In this recent post to his site Samuel Stenton shows you how to get Ghost (a recent player in the blogging space) and Node.js installed on a Laravel Forge server. The Laravel Forge service makes it quick and easy to create and launch virtual machines on the cloud service of your choosing.

He's broken it down into five steps (not including signing up for Forge if you haven't already):

• Step 1: Install Node.js
• Step 2: Download and Configure Ghost
• Step 3: Install and Run
• Step 3: Configure NGINX to Serve our Ghost Blog Correctly
• Step 5: Not finished quite yet!

That final step includes the instructions to restart the needed software when/if the server happens to be rebooted.

Konrad Podgórski has a recent post to his site with his suggestion of a better way to deal with assets in Symfony 2-based applications with the help of some other tools, namely NodeJS, Bower and GruntJS.

I will explain how to work with assets in Symfony framework without having to use Assetic Bundle at all. [...] The process will be really fast and easy to understand even if you never used software listed here. However if you experience any problems do not hesitate to ask for help in comments. Post is quite long because it contain a lot of different configs but don't run away just yet. They are ready to copy & paste.

The setup will download the needed dependencies, merge and minify JS/CSS files, copy font files to the right place and deploy it all to an S3 bucket. He first walks you through the installation of the three tools complete with the commands and configurations to get them all integrated. With those installed and working, he then gets into three "scenarios", the steps in the process to build and deploy the completed version:

• Download latest jQuery, Bootstrap, Font Awesome with Bower and copy the only necessary files to web/assets/*
• Download dependencies with Bower, copy necessary files to web/assets/*. Then minify javascript and stylesheet files.
• Download dependencies with Bower, merge them with your custom css and js files, then minify.

Finally, he includes the steps you'll need to follow to get the whole thing deployed out to S3 (or a CDN). In the next part of the series he'll continue the process and look at things like LESS/SASS, watching for changes in assets and how to use RequireJs.