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

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

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