the padawan menace || Property of lego and lucasfilm. hey guys don’t sue me.

7 tips for a Node.js padawan

Or stuff I wish I knew when I started.

Node.js development is extremely fun and satisfying. There are over 35k modules to choose from, and overall node is very easy to develop a working application that can scale easily.

However for developers just starting off with Node.js development, there are a few bumps along the road. In this short post I cover a few of the things I questioned and ran into while learning Node.js.

Tip 1: Use nodemon for development. pm2 for production.

When you first get started with Node.js development, one of the things that will stick out like a sore thumb is having to run node [file].js over and over again. When I got started with node, this was extremely frustrating and painful. Especially having to control C every time I modified something.

Luckily I discovered a great tool called Nodemon https://github.com/remy/nodemon. Install it by running npm install -g nodemon.

Nodemon is an awesome tool, once you install it globally you can run your node.js scripts via nodemon [file].js. Doing so will tell nodemon to monitor your script and all the scripts that it depends on for changes. This is an awesome way to do Node.js development and speeds everything up.

What about production? Unless you are using Heroku, Nodejitsu or other great Node.js hosting providers, chances are you will be using EC2 or another cloud provider to run your Node.js app. How do you properly run a Node.js app to make sure it’s always running?

The answer to that question is a great tool called PM2 https://github.com/Unitech/pm2. PM2 is a tool like nodemon which is intended to run your node app in production. Like Nodemon it will monitor your app for changes and redeploy them, but unlike Nodemon, if PM2 encounters a crash, it will restart your node.js app right away.

Where PM2 excels though is when you need to scale your app to multiple cores. PM2 comes with a built in “load balancer” that lets you easily specify how many instances of your Node app to run.

pm2 start app.js -i max

The -i parameters lets you specify how many instances to run, in this case PM2 comes with a built in constant called max which auto scales your app to the amoutn of cores you have. Remember Node runs only on one core!

Tip 2: Async or Q

The more you start to write node.js apps, the sooner you’ll realize the pain of callback hell. If you don’t know what callback hell is, here is an example:

 function register(name, password, cb){
checkIfNameExists(name, function(err, result){
if(err){
return cb(“error”);
}
checkIfPasswordGood(password, function(err, result){
if(err){
return cb(“error”);
}

createAccount(name,password, function(err,result){
if(err){
return cb(“error”);
}
createBlog(name, function(err, result){
sendEmail(name, function(err, result){
callback(result);
});
});
});
});
});
}

While not a very useful or amazing block of code, it should get the point across that callback hell is a very real thing. But how do you avoid this?

One simple way is to use events. I personally don’t like using events because then you are using events to call private functions which have only one purpose, which defeats the point of a function.

How do you do this then? There are two competing libraries out there, async.js and Q. Both offer their own take on how callback hell should be prevents.

Async.js https://github.com/caolan/async or “async” allows you to easily execute functions in series or parallel without the need of nesting them back to back.

Below are some of the patterns that Async supports taken from their readme. For a list of all the patterns async supports check out their repo.

 async.map([‘file1',’file2',’file3'], fs.stat, function(err, results){
// results is now an array of stats for each file
});

async.filter([‘file1',’file2',’file3'], fs.exists, function(results){
// results now equals an array of the existing files
});

async.parallel([
function(){ … },
function(){ … }
], callback);

async.series([
function(){ … },
function(){ … }
]);

async.waterfall([
function(callback){
callback(null, ‘one’, ‘two’);
},
function(arg1, arg2, callback){
callback(null, ‘three’);
},
function(arg1, callback){
// arg1 now equals ‘three’
callback(null, ‘done’);
}
], function (err, result) {
// result now equals ‘done’
});

If we take what we did previously with register, we can apply the waterfall pattern in async. The result of this is a very readable code pattern that doesn’t involve the pyramid of doom.

Another great library is Q https://github.com/kriskowal/q. This library is exposes the concept of promises. A promise is basically an object that is returned from a method with the “promise” that it will eventually provide a return value. This ties is very neatly with the asynchronous nature of javascript and node.js.

For example, taken from Q’s repo page.

 promiseMeSomething()
.then(function (value) {
}, function (reason) {
});

The promise me function returns an object right away. Calling then on the object will call the function you pass in with the value you want returned. Then also takes an additional callback which is run when the object fails to return the value.

This is a very neat way to avoid the insanity of callback hell. If we take our registration example, you can easily make it so that each of those functions is called when then is executed.

 Q.fcall(checkIfNameExists)
.then(checkIfPasswordIsGood)
.then(createAccount)
.then(createBlog)
.then(function (result) {
// Do something with the result
})
.catch(function (error) {
// Handle any error from all above steps
})
.done();

As I said previously, I dislike creating single purpose functions. Instead of passing in the function name to “then”, I would just create an anonymous inner function and pass that in, however the choice is yours.

In summary, if you start to realize you’re creating callback hell for yourself then it’s time to look into async.js or Q.

My personal fav? Q all the way!

Tip 3: Debugging Node.js apps easily

Debugging Node.js apps will be confusing if you are coming from a language with heavy IDE integration like Java or C#. Most new node developers adopt the “flow” debugging pattern, where your best friend becomes console.log.

However there are still alternatives that are more convention to debugging. Node.js comes with a built in debugger that you can run by calling node debug, however the one I love is node-inspector.

Taken from their github repo “Node Inspector is a debugger interface for node.js using the Blink Developer Tools (former WebKit Web Inspector).”

In a nutshell node-inspector lets you debug your applications using whatever editor of your choice and chrome web tools. That is sexy.

Node-inspector lets you do some really cool things like live code changing, step debugging, scope injection and a bunch of other cool stuff.

It’s bit involved to setup, so I’ll let you follow the instructions over at

https://github.com/node-inspector/node-inspector

Tip 4: Nodefly

Once you have your application up and running, you might ask yourself how you could monitor it’s performance and profile it to make sure your app is running at optimum speed. The simplest answer to that is a great service I use called Nodefly.

Nodefly with a simple line of code starts to monitor your application for memory leaks, measure how long it takes for redis, mongo queries and a bunch of other cool stuff.

http://www.nodefly.com

Tip 5: Module management with NPM.

One of the most common things to do in node is installing packages via NPM. Node has an amazing package manager which installs all the modules specified in your package.json manifest file. However one thing all beginers run into is keeping this package.json file updated with all the modules you are using.

It seems like a pain to always be opening your package.json to update the dependcies property with the new module you just installed, but what many don’t know is npm will do this for you!

Simple run npm install — save module_name and npm will automaticly update your package.json with the correct module and version name. npm install —save module_name

Tip 6: Don’t check in your node_modules folder

While we are on the topic of modules and npm, not many know that you shouldn’t check in your node_modules folder. The biggest reason behind this is there is no need for you to check this folder in. Whenever someone checks your source out they can just run npm install and download all the modules required.

You might say that it’s not a big deal if you check in node_modules, but what if the person checking out your source is using an operating system other than yours and one of the modules that your app uses is compiled when it’s installed via npm? Your app will crash and the person that checked out your source will have no idea why!

For example modules like bcrypt and sentimental are compiled on the host system when you install them because they have native components written in C.

The best way to avoid checking in your node_modules folder is by adding it to .gitignore.

// .gitignore node_modules/*

Tip 7: Don’t forget to return

A common mistake made by all early node developers is forgetting to return after a callback. While some times this has no implications, there are many times where you’ll run into odd issues because your callback is being called twice.

Lets take a look at a quick example

 function do(err,result, callback){
if(err){
callback(“error”);
}
callback(“good”);
}

At first glance, this snippet makes sense. If there is an error, send “error” in the callback, if not send good. But calling the callaback is not stopping the method from completing the execution. It will just move on to calling callback(“good”).

Inside long and complex lines of code, doing this will save you hours and hours of debugging.


Node.js is great platform to develop on. If you keep these 7 things in mind while developing, debugging and deploying to production you can save your time and prevent your hair from graying out.

Need help with a Node, Dart, Angular, or Android project? Connect with me http://linkedin.com/in/faisalabid

Next Story — Hear Google Now’s Audio History of your spoken searches
Currently Reading - Hear Google Now’s Audio History of your spoken searches

Hear Google Now’s Audio History of your spoken searches

Google now is great, and I depend on it every day. Despite the voice search feature being mostly accurate, there are times where it picks up background audio or random conversations and makes a search for you.

Something I recently discovered is all these audio clips are logged to your Google Activity Dashboard and you can play them back anytime! The best audio clips are the ones where it randomly picks up on-going conversations.

Check out your audio history here https://history.google.com/history/audio?hl=en

My first audio clip dates back to 2014!

Am I going to turn this off? Nah. It doesn’t bother me, and it helps make Google Voice search better. I also think there is a setting in the past where I’ve explicitly turned Audio History on?

Most of the searches are stuff I’ve spoken into the mic. It’s just the false positives ones that make for some good hearing.

Next Story — [Video] Moving from Node.js to Dart
Currently Reading - [Video] Moving from Node.js to Dart



[Video] Moving from Node.js to Dart

The talk I gave at Dart Summit, Moving from Node.js to Dart.

Slides below the video

Next Story — Dart tooling options
Currently Reading - Dart tooling options

Dart tooling options

At Dart Summit, the Dart team announced they will be deprecating eclipse support in favor of WebStorm.

This led to the following common misconception

“Wait a minute, WebStorm costs $. I have to pay to develop Dart?”.

Yes, WebStorm does cost money, but this is NOT your only option and NO you do not have to pay to develop Dart applications.

WebStorm is actually a version of IntelliJ IDEA. The only difference is that Webstorm has a few different features built in optimized for web development. But these features have nothing to do with Dart and you could really care less about them.

According to their documentation

“IntelliJ IDEA remains JetBrains’ flagship product and IntelliJ IDEA provides full JavaScript support along with *all* other features of WebStorm via bundled or downloadable plugins. The only thing missing is the simplified project setup.”

The cool thing here is IntelliJ IDEA has a community edition which has all the features WebStorm has and all the features you need to build Dart apps, just install the Dart plugin. See: https://www.jetbrains.com/idea/download/

The pro version of IntelliJ IDEA has features like UML diagrams, but really, are you doing UML diagrams these days? ☺. See: https://www.jetbrains.com/idea/features/editions_comparison_matrix.html

The other option is Sublime & Atom. Both are solid editors and both have really great support for Dart. See: https://github.com/guillermooo/dart-sublime-bundle

Developing Dart applications does not cost money and it’s more accessible now than before!

Next Story — Using RethinkDB with Dart
Currently Reading - Using RethinkDB with Dart

Dart meets RethinkDB

Using RethinkDB with Dart

30 second quickstart in Dart

Dart isn’t just for the front-end, it’s also a powerful server-side platform to build api’s and command line tools.

One great example of how powerful Dart is on the server-side is by using it with an equally powerful database RethinkDB.

Yes, you can use RethinkDB with Dart!

The driver is updated to support the latest version of RethinkDB and using it is very simple.

I’ll be using Webstorm in this tutorial, which I think is the best IDE for Dart.

First, you’ll need to create a new project.

We’re going to use a console application for this, since the driver is intended to run on a server.

Next you want to add the dependency to pub.yaml. You can find the github repo for the driver if you ever want to contribute or build from source. https://github.com/billysometimes/rethinkdb. Props to BillySometimes for building this.

The current version is 0.7.0 and works with the latest version of RethinkDB, which at the time of writing is 1.16

Notice the rethinkdb_driver entry under dependecies

Now that all the boring stuff is out of the way, it’s time to write some code.

To keep things simple lets take the Javascript driver example and see how we do the same in Dart. This will give you an easy understanding of how to write RethinkDB queries in Dart when looking at RethinkDB’s documentation and examples.

http://rethinkdb.com/docs/install-drivers/javascript/

r = require('rethinkdb')
r.connect({ host: 'localhost', port: 28015 }, function(err, conn) {
if(err) throw err;
r.db('test').tableCreate('tv_shows').run(conn, function(err, res) {
if(err) throw err;
console.log(res);
r.table('tv_shows').insert({ name: 'Star Trek TNG' }).run(conn, function(err, res)
{
if(err) throw err;
console.log(res);
});
});
});

Typical Javascript, nothing fancy or new.

Lets see how we can acheive the same in Dart.

First you’ll need to import the Dart driver in your main.dart file.

import 'package:rethinkdb_driver/rethinkdb_driver.dart';

Next to keep things aligned with the recommended RethinkDB patterns, create a variable r and assign it to the RethinkDB object

Rethinkdb r = new Rethinkdb();

Excellent. We’re making progress.

Next create a method called connectToDriverAndQuery. You can and should come up with a better name but for the sake of the demo we’ll stick to this.

connectToDriverAndQuery(){}

Straight forward Dart.

One thing I want to add though is async/await support. If you want to learn more about how async/await works, check out https://www.dartlang.org/articles/await-async/

To make a method support async/await, just add the async keyword after the method declaration.

connectToDriverAndQuery() async {}

Boom. It’s that simple.

Next up, we want to connect to our RethinkDB server. Since the method is async enabled, we can connect to our server like such.

var connection = await r.connect(db:"test");

No need for callbacks.

The connection variable is important as it will be passed into all our queries. You can also add host: and port: parameters to the method like such

var connection = await r.connect(db:"test", host:"192.168.99.100", port:49154);

That funky port is thanks to the docker instance I run with RethinkDB. www.kitematic.com

Next up, staying true to the 30 second javascript example above, we want to create a table called tv_shows.

var tableCreate = await r.tableCreate("tv_shows").run(connection);

Notice that we pass in the connection variable from above.

Not only is RethinkDB’s syntax clear, but async/await makes it too easy.

Lastly, following the Javascript example, we want to insert a tv show.

var insertRow = await r.table("tv_shows").insert({ "name": 'Star Trek TNG' }).run(connection);

It is that simple. No need for messy callbacks and it’s all asynchrnous.

If you print(insertRow) you’ll see the same output as you would in the javascript driver.

print(insertRow);
{deleted: 0, errors: 0, generated_keys: [f6690740-cb9f-4901-9b2f-243f67744418], inserted: 1, replaced: 0, skipped: 0, unchanged: 0}

Lets take a look at the entire main.dart for reference.

import 'package:rethinkdb_driver/rethinkdb_driver.dart';

Rethinkdb r = new Rethinkdb();

main() {
connectToDriver();
}

connectToDriver() async {
  var connection = await r.connect(db:"test", host:"192.168.99.100", port:49154);
  var insertRow = await r.table("tv_shows").insert({ "name": 'Star Trek TNG' }).run(connection);
  print(insertRow);
 }

Dart and RethinkDB work great together. Using Dart’s async/await syntax, I personally find it much better to develop in than the Node.js driver.

Want to learn more? Check out the docs at http://rethinkdb.com/docs/ and the great documentation at Dart https://www.dartlang.org/docs/

Sign up to continue reading what matters most to you

Great stories deserve a great audience

Continue reading