node.js

React seems to have taken the front-end development community by storm, and is extremely popular for web UIs.

It's development model is a breath of fresh air compared to many other tools: you just clone your app, and as long as you have Node.js installed in your environment, to start developing you run (either with npm or yarn or whatever today's most popular package manager is):

And then you have a local development server running your code, which updates in real time when you change code.

But when it comes time to deploy a real-world React app to non-local environments, things can get a little... weird.

For most modern projects I work on, there are usually multiple environments:

I was recently futzing around with a Drupal site that has a fairly complex theme setup, and which relies on npm/gulp to setup and build the theme assets. One time after not touching the project for a couple weeks, when I came back and ran the gulp command again, I got the following error:

I'll be presenting Node.js and Drupal — Working Together at the STL.JS meetup this Thursday, May 15, at The Able Few in St. Louis.

In the presentation, I'll basically be covering how Server Check.in uses Drupal and Node.js to deliver a simple, fast, and stable server monitoring service. During the course of the presentation, I'll touch on why and how Server Check.in was built, how Ansible is used to maintain the infrastructure, and the effectiveness of lightweight marketing, blogging, and 'low end box' servers.

Join me and many JS developers in St. Louis on May 15, and after the presentation, we'll hack on some of the things mentioned in the presentation!

If you're running CentOS 6.x (I use 6.4 currently), and you have installed the EPEL yum repository, you can install Node.js simply with:

Done. Check for node's successful installation by running $ node -v (it should return something like v0.10.4).

Adapted from my answer on Server Fault.

Just posted a new blog post to the Server Check.in blog: Moving functionality to Node.js increased per-server capacity by 100x. Here's a snippet from the post:

One feature that we just finished deploying is a small Node.js application that runs in tandem with Drupal to allow for an incredibly large number of servers and websites to be checked in a fraction of the time that we were checking them using only PHP, cron, and Drupal's Queue API.

If you need to do some potentially slow tasks very often, and they're either network or IO-bound, consider moving those tasks away from Drupal/PHP to a Node.js app. Your server and your overloaded queue will thank you!

Read more.

tl;dr Node.js is awesome for running through a large number of network or IO-bound tasks that would otherwise become burdensome at scale using Drupal's Queue API.