By Chad Wyszynski
2014.06.22

Solving Coding Challenges with Streams

My first experience using Node.js for a programming challenge was agonizing. I devised a viable solution, but I couldn’t figure out an effective way to parse the input. The format was painfully simple: text piped via stdin. No problem, right? I burned over half my time on what should have been a minor detail, and I ended up with a fragile, zip-tie and duct tape hack that still makes me shudder.

The experience inspired me to find an idiomatic approach to programming challenges. After working through more problems, I arrived at a pattern I hope others will find useful.

Read more...
By Caroline BDA
2014.02.18

Mocking Dependencies using [rewire]

Read more...
By Tim Caswell
2013.09.02

Generators vs Fibers

Both ES6 generators and node-fibers can be used to block a coroutine while waiting on some I/O without blocking the entire process.

This means that you can wait for an I/O result within your code but still have the performance benefits of the single-threaded, non-blocking I/O model you all know and love.

Both can do this for arbitrarily deep call stacks. The main difference between the capabilities of the two is how explicit the syntax is. It's the classic battle between wanting to be safe while wanting to be flexible.


Read more...
By Swapnil Mishra
2013.08.05

Simplifying Chores with Grunt

Often in various stages of development we perform repetitive tasks e.g minification, compilation, unit testing, linting and we would definitely want to automate them. But each of these task require different configurations or installations. What if there is a system where in we can easily configure and run these tasks from a single place. Also it would be really nice if it gels well with Node.js system. Meet Grunt a task runner for simplifying chores. Apart from being simple Grunt ecosystem is huge and it's growing every day with literally hundreds of plugins to choose from.

Note that I will be using grunt task/plugin interchangeably which means the same.

Read more...
By Tim Caswell
2013.04.28

Daddy, what's a stream?

At dinner tonight, I was discussing that I've been thinking about streams and how to simplify them in JavaScript. My 7-year-old perked up and asked me:

Daddy, what's a stream?

I explained that a stream is like a line of water along the ground. If you dig a trench on a hill and fill up the high end using a water hose the water will run down the hill along the trench. This is one of his favorite hobbies in the back yard, so he understood completely. I explained that when new water is added to the top, it eventually makes its way to the bottom of the stream. The end where water comes from is called the upstream and the other end is the downstream. Gravity pulls water down.

Read more...
By Jean-Philippe Monette
2013.03.01

Content Syndication with Node.js

Web syndication is a must for any Website wishing to share some entries easily to other systems. Better known under their format name like RSS) or Atom), they can be quite time consuming to generate without a module handling all their formating. Thanks to the power of Node's package manager NPM, you can generate yours in no time.

Read more...
By Shahar Kedar
2012.12.12

Session-based Authorization with Socket.IO

Finding a decent article about session based authorization in socket.io is more difficult than one expected. This article will show how you can take advantage of Express session middleware and socket.io authorization middleware to create a very simple authorization mechanism when establishing new socket.io connections.

Read more...
By Vojta Jina
2012.08.13

Make Your Tests Deterministic

Non-deterministic issues like race conditions or thread deadlocks are very difficult to test, because they are by nature hard to reproduce. Fortunately, in the JavaScript world, we only have a single thread, so we are safe, right? Well, not really because...

Execution order of callbacks can cause the same race condition issues that plague multi-threaded environments.

Read more...
By Dumitru Glavan
2012.06.18

Sending e-mails with Node and NodeMailer

Sending e-mails with NodeJS is almost a breeze. Almost. First, you have to plug-in the NodeMailer module than set up a transport type, load the templates, add attachments and finally send...

Read more...
By Srirangan
2012.02.06

Node.js and MongoDB - Getting started with MongoJS

It won't be an exaggeration if one claims that in the past few months Node.js and MongoDB have literally taken the software and web industries by storm.

Not just bleeding-edge startups but even medium and large enterprises are leveraging these two technologies to deliver a better experience to their users by build more capable, performant and scalable apps.

So what is Node.js?

Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

..and what is MongoDB?

MongoDB is a scalable, high-performance, open source NoSQL database.

This post will cover the basics and get you started with your Node.js + MongoDB app. Make sure you have Node.js installed and MongoDB setup on your developer machine.

Let's verify your Node.js installation and start the MongoDB server:

$ node -v
$ mongod
Read more...
By Srirangan
2012.02.05

Really simple file uploads with Express

Few days ago I was working on a fairly typical web application and I faced the challenge of implementing a fairly typical web application feature - file uploads. It was the first time I was implementing file uploads with Node (and Express) and I did what anyone else would do - I googled it.

Unfortunately all the articles / posts out there are either outdated, too complex or plain wrong. So I did the next most obvious thing - post a question on the mailing list. As always Mr. Holowaychuk was incredibly quick to respond. His answer lead me to do what I should have done in the first place - read the docs.

Read more...
By Kishore Nallan
2012.01.24

Understanding process.nextTick()

I have seen quite a few people being confused about process.nextTick(). Let's take a look at what process.nextTick() does, and when to use it.

As you might already know, every Node application runs on a single thread. What this means is that apart from I/O - at any time, only one task/event is processed by Node's event loop. You can imagine this event loop to be a queue of callbacks that are processed by Node on every tick of the event loop. So, even if you are running Node on a multi-core machine, you will not get any parallelism in terms of actual processing - all events will be processed only one at a time. This is why Node is a great fit for I/O bound tasks, and definitely not for CPU intensive tasks. For every I/O bound task, you can simply define a callback that will get added to the event queue. The callback will fire when the I/O operation is done, and in the mean time, the application can continue to process other I/O bound requests.

Given this model, what process.nextTick() actually does is defer the execution of an action till the next pass around the event loop. Let's take a simple example. If we had a function foo() which we wanted to invoke in the next tick, this is how we do it:

function foo() {
    console
.error('foo');
}

process
.nextTick(foo);
console
.error('bar');

If you ran the above snippet, you will notice that bar will be printed in your console before foo, as we have delayed the invokation of foo() till the next tick of the event loop:

bar
foo

In fact, you can get the same result by using setTimeout() this way:

setTimeout(foo, 0);
console
.log('bar');

However, process.nextTick() is not just a simple alias to setTimeout(fn, 0) - it's far more efficient.

More precisely, process.nextTick() defers the function until a completely new stack. You can call as many functions as you want in the current stack. The function that called nextTick has to return, as well as its parent, all the way up to the root of the stack. Then when the event loop is looking for a new event to execute, your nextTick'ed function will be there in the event queue and execute on a whole new stack.

Let's see where we can use process.nextTick():

Read more...
By Vojta Jina
2012.01.08

Testing Private State and Mocking Dependencies

During Christmas I've been working on Testacular and found some tricks how to make my testing life easier. It's nothing special at all, just a simple way how to access private state of a module and how to mock out some dependencies. I've found these two techniques pretty usefull, so I believe it might help someone else as well...

Why would you need to access private state of a module?

Private should be private, right? Yes, for sure. But during unit tests, it can be very helpful to have access to private state of a module - I always try to cover functionality or bug at the lowest possible level, because it's simply cheaper:

  • faster test execution
  • less code is required to bootstrap the test

Let's say we are building very simple static web server, the skeleton might look something like this:

var http = require('http');

var handleRequest = function(request, response) {
 
// read file from fs and send response
};

exports
.createServer = function() {
 
return http.createServer(handleRequest);
};

This module has only one public method createServer, so unless we make it public, we can't get hold of anything else but this method. That sucks, because HttpServer doesn't have any public method to call the handler, so we would have to send some data through socket to test it. That's way too much effort, especially when you realize that the only code we really need to test is the handleRequest function - everything else is just Node and we trust Node, because it's awesome. We need to test our code - that's where all the bugs are.

Why would you need to mock out dependencies?

Some dependencies are cheap, some not. When our code uses modules like util or path, we are fine. Nothing bad happens there. But when it comes to some other modules like fs, net or http, it's totally different story. We simply don't want to deal with real filesystem in unit tests. There are many reasons for that, such as:

  • accessing file system is slow
  • it requires seting up some state of filesystem
  • there is only one instance of filesystem, so conflicts between different unit tests might happen

So we want our module to use something different - we call these objects test doubles (I actually like using mock/stub/dummy definition from G.Meszaros). The question is, how can we persuade our awesome module, to use a different instance during testing and different instance in production?

Dependency Injection is great for this - it wires all the pieces together (yep, it saves us lot of work) - and more than that, it does allow us to use different instances during testing. Yep, DI is just awesome! I actually think, that new languages such as Dart should support DI natively - in the same way as they do support memory management.

Unfortunately, there is no DI in Node, at least I haven't found any sufficient implementation. Writing a Dependency Injection framework is definitely a solution, but I was looking for something faster...

Read more...
By Nathan Stott
2011.12.20

Asynchronous Control Flow with Promises

A Promise is an object that represents the result of an asynchronous function call. Promises are also called futures and deferreds in some communities.

Read more...
By Nuno Job
2011.12.06

Easy HTTP Mock Testing with Nock and node-tap

One of my first node.js libraries was nano: A no fuss CouchDB client based on the super pervasive request. In foresight that was a good idea, even though there's a ton of clients for CouchDB none of them is as simple as nano, and the fact that its based on request is great.

When you are writing a HTTP client you need to test with one (or several) HTTP endpoints. I was lazy about it so I choose to point nano to iriscouch and run the tests on real HTTP requests. This was a problematic but overall ok approach.

Then some weeks ago I started automating the tests using travis. And builds started to fail. To make this work and fix all the shortcomings of a direct connection to iriscouch. I needed a HTTP Mocking module.

By the way Travis is super cool. You should test all your node.js libraries with it. All you need to do is go to the site, sign in with github and place a .travis.yml file like this one in the root of your lib:

  language: "node_js"
  node_js
:
   
- 0.4
   
- 0.6
Read more...