Why subscribe to the SDW newsletter?

  • Insight on business technology trends and news.
  • Case studies on ground-breaking innovation.
  • Invitations to SDW events and webinars.
  • Other worthy dispatches from our expert team.
  • No spam. Just cool stuff.


Please leave this field empty.

Go back to skookum.com

7 Comments

Building a Non-Trivial App in Node.js

The App

We recently launched ClickDummy, a free app for web designers that turns mockups into prototypes, and one of the first systems with node.js powering its full feature set. Interest in node as a platform is huge, but little has been reported on a full development-production cycle. Our experiences with ClickDummy have exposed issues you’ll likely face while building your own node applications.

Why Node?

Others have already explored why node.js is quickly becoming the most popular kid in school. We chose the platform for Clickdummy specifically because we are a team of JavaScript experts building an app for fast collaboration. If you’re making your platform decision right now, consider this:

Pro

  • Familiar, expressive language – If you’re building a web app, it’s likely that your team has strong JavaScript-fu. Don’t get too comfortable though, because there is a bit of a learning curve to the async style.
  • Server and client share data types and syntax – Passing data back and forth via JSON is simple. Do it.
  • Server control – Node is more like Java than PHP as you control the whole server, not just files that are interpreted before being passed out through Apache. Things on the difficult-to-impossible scale on LAMP are within node’s reach (think websockets).
  • Libraries – If you can dream it, somebody has probably built started a node library for it. (Feel like controlling the DOM via a Kinect?)
  • Speed and scale – Node is fast and can serve huge numbers of requests simultaneously due to its async nature.

Con

  • Unstable libraries – Be prepared for lots of woe if you try to keep up to date with the latest interface for all of the libs you’ll end up requiring.
  • Single threaded – It’s one damn fast thread, but it’s still just one. Taking advantage of multiple cores or servers requires extra consideration.
  • Relatively complex deployment – Like the other complaints here, with time, this one will stabilize. However, for now, it takes a little work to set up a non-trivial node deployment.

Node.js Problems and their Solutions

Unstable / Incomplete Libraries and APIs

Node is immature, so much like a teenager, it’s full of energy and passion and constantly changing direction. Specify exact version numbers for npm bundle. If libs are buggy or incomplete, fork them, and use your own github account to freeze your libraries in a working and compatible state.

Uncaught Exceptions taking down your server

That’s right, uncaught errors in app code can kill a node server. You can trap them on the ‘process’ object, but that has the side effect of dumping your stack (weird behavior ensues). Use fugue to run your app code. Fugue is “unicorn for node.js” – it creates worker processes; if they die, it respawns them. Further, this allows you to take advantage of multiple cores. Keep your app 100% stateless! – store sessions with redis or mongo – this is a good architecture decision that’s absolutely crucial to a stable node.js deployment.

No standard deployment solution

As with any new technology, several players are competing to see their deployment stack win out. Joyent and Heroku are the big names with node, but many smaller hosting companies are taking a stab as well (full disclosure: we’re on webbynode, which so far has been excellent). However you decide to push your code (we use git with dev/staging/production remotes), use npm bundle to get your libs in place. It will create a local copy of the libraries (and versions) for your app without requiring a homogenous library environment on the whole server.

Multiple apps on a single server? (“vhosts”)

Fast, easy SSL?

Nginx reverse proxy. Just like Rails. HTTP to HTTPS nginx redirect, SSL enabled

Restarting the server during development

Cmd+Tab, Ctrl+C, Up, (password), Enter … gets old when you’re iterating over a feature or hunting a bug in your code. Use nodemon to automatically restart your server on code changes.

Starting the server as a daemon and monitoring it

Add an upstart script to /etc/init/yourapp.conf – then use monit to poll your homepage occasionally.

What are your solutions?

We think ClickDummy is a really cool node.js web app and have definitely covered some new ground. We’re always interested in better, faster ways to build reliable software. If you’ve discovered alternative solutions to any of these problems… to the comments!