Let's Make a Web App: Nodepad

2010-11-01 00:00:00 +0000 by Alex R. Young

Welcome to part 1 of Let's Make a Web App, a new tutorial series about
building a web app with Node. This series will
walk you through building a web app with Node, covering all the major
areas you'll need to face when building your own applications.

The app we're going to build is a web notepad called Nodepad. Not
particularly original, but well-defined and easy to understand.

Selecting Frameworks and Tools

Modern web applications depend on several components:

Ultimately, the choice is down to context. I've had to use certain
technologies due to the deployment environment, and when I build open
source software I'm likely to use something I know people can easily

In this case my criteria for selection will be based on feedback we've
had about what our readers are interested in, and my own areas of


Building web apps with Node typically involves a framework of some kind.
If you read our weekly Node Roundups you'll know there are plenty of
excellent web application frameworks out there. Some aim to port
complete solutions like Rails or Django to Node, and others are more
focused on the routing and HTTP layers.

An example of a popular Rails-like framework
is Geddy. It has been around for about 7
months, and continues to be updated. A simpler,
Sinatra style framework is Express which has been around since June 2009, and is still regularly updated.

The larger frameworks usually provide one-to-many mapping of resources
to files through a Model View Controller abstraction. A project might be
organised like this:

Not all frameworks are MVC, though. And in the Node world there's also a
lot of so-called microframeworks. I originally thought Express was a
microframework, but it provides abstractions for dealing with the whole
stack, so it's a bit fatter.

I feel like Express has the right balance for this project. We could
successfully use any framework within reason, but Express bundles enough
things to make this project pleasant to work on without being too heavy.


A UI framework of some kind will reduce the chore of interface
development. The JavaScript UI frameworks scene has exploded over the
last few years. The following framework types are available:

I feel like SproutCore and Cappuccino would be too heavy for this
particular project. jQuery UI and the Aristo
work well
together -- you can get great results without making the app feel too


In Let's Make a Framework I recently mentioned that there's a
CommonJS Unit Testing Specification.
Nodeunit is based on the CommonJS assert module, and the tests should look very familiar to those of you
who have written unit tests before.

On the other hand, Expresso
offers assert.response, which makes testing servers a
little bit cleaner. Expresso is written by the same author as Express
(TJ Holowaychuk), so it's not surprising that it has this type of feature.

I'm not sure which route to take yet, so I'll try both when I start
building the app and select the most suitable.


Storage has gone insane in the last two years. When I started out, it
was either relational databases or object databases that I never really
got to use. That meant I used either Oracle, PostgreSQL, or MySQL. Now
NoSQL has started to take up mindshare, we've got CouchDB, MongoDB,
Riak, Redis, Tokyo Cabinet, and many more.

If you've used any of these NoSQL frameworks you'll know some are kind
of enough to have JavaScript shells, which makes life easy for us.
They're also broadly grouped into key value stores and document storage
systems. Document storage sounds suspiciously like what we want given
that we're writing a notepad.

Choosing a storage system is one thing, but then you need to choose a
library for your language and framework. Express doesn't prescribe
model-layer abstractions, so we can use any storage library and system
we want.

I'd like to use MongoDB for this project. I feel like CouchDB would also
be a good choice, but I've written a lot of code that uses
Mongoose so I'd like to draw on that knowledge.

The Mongoose API makes asynchronous database access less syntax-heavy
than it could be. The popular "default" MongoDB library for Node uses
callbacks everywhere, rather than some clean abstractions and function
call chains, so it becomes incredibly hard to read.

So far I've been using Heroku with
MongoHQ and these services have simplified my sysadmin chores a great deal. Because the underlying technology is open
I can download MongoDB and run it locally for development, then deploy
to something I'm effectively paying someone else to maintain. If I had
the time I'd deploy to my own servers, but it turns out I like writing
these articles too much!


I've tried to write this part of the tutorial in a way that demonstrates
how to select suitable technologies for real open source or commercial
projects. If you're in a similar position, here are some helpful


In the next part, I'll go through getting a development environment and
basic app set up.

The areas the tutorial will cover will be:

Some parts might take several weeks to cover depending on how involved
they are, like the Framework series.