Developing with Derby JS - Installation

In this series, I will try to show how to build a step by step web application. My ultimate goal will be to write an app that could gather user statistics from Facebook, similar to Wolfram Alpha Facebook Report.

The first step in the series is installation:

There are several ways to install NodeJs. For Ubuntu, the easiest way is to install through apt-get

sudo apt-get install node

Although this is convenient, I try not to go with the apt-get route because they tend to be outdated. For me, opensource means living on the edge with latest release, sometimes with alpha software.

Here are the steps you will need to follow to install node js. Note that we are installing nodeJS locally. I tried to install with sudo, then there were permission issues which led me to do it this way.

wget http://nodejs.org/dist/v0.10.12/node-v0.10.12-linux-x64.tar.gz
tar -xvf node-v0.10.12-linux-x64.tar.gz
cd node-v0.10.12-linux-x64
./configure --prefix=/home/alias/Applications/node/
make install
echo 'export PATH=$PATH:/home/alias/Applications/node/bin' >> ~/.bashrc

Now that you are done with installing this node, next on our stack is to install Redis

wget http://redis.googlecode.com/files/redis-2.6.14.tar.gz
tar -xvf redis-2.6.14.tar.gz
make -j 6
make test
make PREFIX=/home/alias/Applications/redis/ install
echo 'export PATH=$PATH:/home/alias/Applications/redis/bin' >> ~/.bashrc
cd utils 
./install_server

This will ask a bunch of questions. Defaults are usually fine unless you are not comfortable with it. At the last step, it will ask for redis executable location, and you are going to respond with

/home/alias/Applications/redis/bin/redis-server

Next step and the final step is to install MongoDB: For this, I used bare apt-get

sudo apt-get install mongodb-server

If all is well, you should be good to go.

For now, let's start the servers and let's not do this using services, but use console instead (except for mongo):

/home/alias/Applications/redis/bin/redis-server 
sudo /etc/init.d/mongodb restart

Now that we are good to go, we are ready to prepare the initial dummy web app. To do that, we first need to install derby through node package manager (NPM) which is a repository of projects just like apt-get is, except it's more frequently updated.

npm install -g derby

The -g implies that the module should be installed globally. Now that we specified node folder to be "/home/alias/Applications/node", the installed module has gone into "/home/alias/Applications/nod/lib/node_modules". It's time to invoke our project generator

derby new SocialReport

Now note that the project is installed together with its dependencies which are found in the node_modules folder.

If we go into SocialReport and type

npm start

we are going to end up with the following bootstrap template (haters gonna hate).

It's all well.

Derby uses MVC paradigm which creates a clear layer between model, controller and the view. It's a realtime framework, making it easier to build scalable realtime websites so that users can interact with the site, see data changes are reflected immediately and so on. Being a NodeJS tool, you don't have to write your backend code and front end code in different languages which makes "Context Switch" really easy. Since it's javascript (read: single thread), it clears you from having to think about concurrency issues. Using its event queue, it enables you to quickly write scalable code (well, to an extent - probably more on that later).

Let's now look at the folder structure.

lib
styles
ui
views
package.json
server.js

• package.json: This is the manifest for the project. You can put information about project, as well as dependencies and initialization scripts. A sample is as follows:
  { "name": "web", "description": "", "version": "0.0.0", "repository": { "type": "git", "url": "" }, "scripts": { "start": "node server.js" }, "dependencies": { "connect-mongo": "~0.3.2", "derby": "0.5.x", "derby-auth": "git://github.com/lefnire/derby-auth.git#0.5", } "engines": { "node": "0.10.x" }, }

Note that the format is unsurprisingly JSON - no more eye hurting XML. I tried to give examples of multiple use cases for dependencies. If you specify your dependency like connect-mongo or derby, it will fetch it from the global node repository. If you would like to go with the sourcecode directly and like to live dangerously, 3rd row is your friend. If you want to lock your project to a specific version of a specific packet, you should specify the version number, otherwise you can pass "", my personal opinion is that locking to a specific version ensures that it's going to work in the future. Otherwise, if you think new stuff is always the best, go with "", and occasionally deal with breakages - which is mostly fine. In the same file, you provide the node version to make sure it's working against the right version.

• server/index.js

This is the file that does the initialization for mongodb, derbyjs, redis and so on. For each of the components, it's possible to specify multiple configurations depending on if you're in production or not.

The file has several defaults you might need to enable.

• app/index.js

This is the controller, but interestingly it is named App. In the index.js file, you define the routes (ie what url invokes which action), and also specify the action i.e., what would happen if a request is made.

// Derby routes are rendered on the client and the server
app.get('/', function(page) {
  page.render('home');
});

• views Views folder have the templates that you use to render actions. DerbyJS use handlebar like templates for it's operations. You can use htmls, and you should also separate your design into sections like

and so on.

What's next?

Passport JS Configuration and Facebook integration is next on our list. It will involve configuring passportJS for authentication using facebook and setting up routes for the authentication logic. Google plus integration will also be shown.

After that we will work on some of the data collection/mongodb aspect using facebook graph queries/fql.