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:

Storage: Relational database, NoSQL

Storage library: simple, ORM

Web server

Package manager

Server-side framework

Client-side framework

Testing libraries

Version control

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 install.

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 expertise.

Server-Side

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:

Models: user.js, note.js

Controllers: users.js, notes.js

Views: index.html (item list), edit.html, new.html

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.

Frontend

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:

Interface-specific libraries that sit on top of lower-level frameworks: Scriptaculous, jQuery UI

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

Testing

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

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!

Resources

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 resources: