EST Apis seem to be taking over the world as of late, and Node has been the platform of choice for building them. However, when you take a look at some of the tooling for building robust REST APIs in the node community, the options are bleak at best. When you take a look at all of the properties that would make an API RESTful, it is easy to see that it is rather complex.

REST

There are a few fundamental properties that make apis RESTful - they should be a Scaleable, Stateless, Cacheable, fit into a Layered System which is apart of a Client / Server model that provides a Uniform Interface. In the confines of a Restful HTTP

aching is often times the first line of defense against poor performing applications and very quickly becomes a critical and complex part of various parts of the stack. One of the more frustrating aspects of caching, is that there are so many very capable solutions available - Redis, memcached, memory etc. Even some databases or plain old `files` can be used to cache data in certain circumstances. Each of them having different strengths, weaknesses, uses cases and different APIs.

Cache ['kash] -n, noun; -v, verb

a component that stores data so future requests for that data can be served faster; the data stored in a cache might be the results of an earlier computation, or the duplicates of data

ommand Line tools are an important component to development, administration and maintenance of most all software projects - large or small. A good command line tool greatly speeds up repetitive operations through simple and flexible abstractions.

The Node.js community has a number of tools out there for quickly building out a command line interfaces, commander being one of the more popular. However, most all of them suffer from the same set of problems, making them difficult to integrate into applications in a clean an re-usable manner. Primarily speaking, there is no way to separate general functionality, from a command, from the argument parsing, or a command from the command line tool itself. This makes building for code re-use

oggng is one of the those things that many developers don't put much thought towards until it is a little too late. Having some kind of audit trail of what the application behavior, state, and any errors that may occur is critical to developing and maintaining complex systems. However, javascript developers are typically accustomed to just peppering `console.log` when ever and where ever they see fit. During development this may seem like a fine idea, but this quickly proves to be a insufficient logging solution.

Firstly, the console interface in Node writes to one of the standard outputs in the host system, which may or may not be captured so you may inspect it. There is also no

ode.js ( and more recently io.js ) has put javascript as a programming language on a fast path. We have seen more improvements and advancement in the last 2 years that we have seen in the previous 2 decades. ECMAScript version 6 ( ES6 ) or `harmony` bring a lot of interesting and very useful features. One of the more useful, and oddly enough, confusing features is the introduction of generators and iterators.

The idea of generators and iterators are not unique to javascript. In fact that are fairly common in other programming languages. The Python language is very well know for it wide support for generator / iterator support. In fact it ships with module dedicated to creating and dealing with

onfiguration is an important piece to not only making your application deployable, but flexible and accommodating to change. We can't predict how an application will need to accept configuration between a local setup, build servers, staging and production. More over, if any of those things were to change, large parts of the application would need to change how it handles configuration. Some systems prefer files, some prefer environment variables some prefer command line arguments.

The Basics

A production ready application should be able to collect configuration from multiple sources and reconcile them into a single entity that is referenced throughout the application. We're going to walk through a sensible way to do this. The first thing we need to

ne of the more frustrating things in JavaScript has always been how Errors are handled. They are difficult to check for, harder to extend and often times have cryptic messages providing little insight into what has gone wrong.

Uncaught TypeError: undefined is not a function

Everyone has seen this at one time or another. It isn't very helpful, and these types of errors are actually difficult to account for in JavaScript applications. The only error handling in JavaScript that the language allows is generic try/catch, where you can catch an error, but trying to recover from specific errors is difficult to do. Large in part the the fact that you can throw anything, not just errors. You can

n previous installments of Summer Of Sockets, we took a look at the basic messaging socket types in [ZeroMQ](http://zeromq.org), **PUSH**/**PULL**, **PUB**/**SUB** and **REQ**/**REP**. Each of these types provides different patterns of messaging between their connected peers. Up to now, we have been passing simple message around to illustrate the patterns. In larger, more complicated applications, the message will need to carry more information.

In JavaScript, that typically means constructing, passing and parsing JSON objects, as well as accounting for missing fields, and event embedding message types and meta data about usage into object. This quickly becomes messy and overly complicated.

JSON is a fine data format, but ZeroMQ provides a very handy facility

ode is still pretty young platform and people are still trying to figure out the best way to build large projects with it. With its highly modular core, and an even more modular ecosystem, it is easy to get lost in the variety of ways to go about anything.

I'm starting this series of articles about my experience in building production ready node projects. We'll be talking about structure, conventions, packages, and all around good things to do. To start, let's talk about one of the less talked about topics in the ecosystem, but in my mind, one of the more important - Project Structure.

Project Structure

The biggest step for new Node.js developers is to think in

ately I have been using [Docker](http://docker.com) for development. It makes it really easy to stand up services and package entire stacks for projects. Most recently, I set up an elastic search instance, and the first thing I wanted to do was install the insanely helpful [Head](http://mobz.github.io/elasticsearch-head) and [Big Desk](http://bigdesk.org/) plugins. The official [elastic search Dockerfile](https://github.com/dockerfile/elasticsearch) is just elastic search, no plugins. And of course, containers are pretty much a black box. Every time it restart, everything is back to square one. Luckily, The image exposes a volume for persistent data, and that is all we really need to have to install plugins. Here