Node.js Design Patterns

Tweet about this on TwitterShare on LinkedIn0Share on Google+0Share on Reddit0Buffer this pageFlattr the authorEmail this to someonePrint this page

Node.js Design Patterns

Javascript on the server? How is this going to be different from Javascript on the client? We are going to cover the way Node does things and understand it to develop efficient Node code.

Contents

Asynchronous code & Synchronous code

As we have seen in an earlier post (here), how node does things Asynchronously. For a “Traditional programmer”, this can be a tough pill to swallow. So lets take a look at how things can be done async.

Tradition programming

Here the  doSomething() executes a set of statements that are not dependent on the response of the db call. But it has to wait till the db operation is completed. This is why we have a server like Node to take care of all the I/O threads separately.

So in an async world, the same will be written like this

Here, the DB request gets fired and doSomething()  will get executed immediately after that. All the actions happen async. Its Node’s event loop’s responsibility to take care of I/O operations and fire the registered callback.

Now, life is always not that simple is it? (tell me about it!..) Take a look at this example

or

Very nested and convoluted? So can we fix this whole nested thing? Yes, you can use any of the following modules

So our code will turn into

Now, lets take a look at Node’s Modules.

Node Modules

If you have interacted with programming languages like C, C++, Java, .Net or PHP, you would have seen statements like import  using  #include  include or  require to get external files/libraries to your current file. Since the code is isolated in these programming languages, we need to explicitly include the required libraries.

But, Javascript runs everything in the global scope and does not have a partition between variables/functions or variables/functions of a file. In simple, there is no namespacing!.

If you have 3 files, fileOne.js , fileTwo.js  & fileThree.js  and you loaded them in your browser in the same order, The function definition or variable values of the prior will be overridden by the later without any warnings.

Lets say fileOne has a method called add(num1,num2);  which adds two numbers & fileTwo has a method called add(str1, str2);  which concats’ two strings. And fileThree is calling the add(5,4);  expecting the method to return the sum. But instead, it receives a concatenated string.

This phenomenon in the programming world is called as the “spaghetti code”. Unless you are careful about your variables names, you might override someone else’s code or some one might override yours!

So we need to use a dependency management system, that will take care of things like these. Node uses CommonJs Modules for handling dependency.

CommonJS dependency management revolves around two methods exports  &  require.

Let’s reconsider the above example, and implement the same via CommonJs modules.

fileOne.js

fileTwo.js

and now in fileThree.js

Neat right? Node uses this for its dependency management & name-spacing and you need to when you are developing code around Node.

Javascript’s Callback

A call back basically is a function that will get invoked after the initiated task is completed.

That means, I want do something after some other thing is completed. Like, after 5 seconds fire an alert.

Or in Node, since everything is async, the callback gets fired on completion of an I/O operation.

Callback function can be named or anonymous.

As we have seen earlier, nesting callbacks can be a nightmare for code readability. We have also seen libraries like async would help clean the code for us. Another way to implement the same without any external module is

Any async function in node accepts a callback as it’s last parameter.

So, this is what you can expect from Node.

And the callback function’s first argument is always an error object (if there an error, else null) and the second argument is the results from the parent Function.

The Event Emitter Pattern

Let’s take a look at some sample code first

The above code is a simple TCP server. Lines 4,7 & 10 register events. And the server gets created. When a client navigates to  http://localhost:1235 the server starts to listen to the new client. And registers events when a data comes in & when a client disconnects from the server.

So when a client connects, we see a console log about the connection. We wait.. wait.. wait.. and then the client emits a data event, the server logs it & finally the client disconnects.

This model is also called as the “PubSub” – A publisher-subscriber. For all you jQuery devs out there, you know this!! (You register an event on a button click and write some code and wait for the button click). Some call this as Observable pattern. You can figure this out here.

So, In simple, our server code will get executed only if there is an action.This is a simple example of event driven development in Node.

Node provides an option to write & trigger custom event too. Take an example of a baseball

What happened here?

  • We created a response ( homeRun())
  • We registered an event (‘ swing’) passing the callback ( homeRun())
  • We Emitted the event (‘ swing’)

Apart from the above way of implementing the eventEmitter, we can inherit the same too. What do I mean? Take a look at this

Pretty neat right? Now you can have your own class that is invisible.

So these are some of the ways, in which node should be implemented. Depending on our requirement, you can pick from above.


Thanks for reading! Do comment.
@arvindr21

Tweet about this on TwitterShare on LinkedIn0Share on Google+0Share on Reddit0Buffer this pageFlattr the authorEmail this to someonePrint this page
  • Parviz HomayunNezhad

    Thanks, Nice and Powerful article.

  • King Julien

    Great article! Thank you!

  • jhong

    thanks for this comprehensive article :)

    • / Arvind Ravulavaru

      Glad you liked it!

  • narasimha

    in base ball swing example

    what is the need of line number 12 (Batter.prototype = events.EventEmitter; // Inheriting EventEmitters methods into Batter. ex: ‘on’, as user below)

    when we already had line number 5 (events.EventEmitter.call(this); // making the Batter class a event emitter )

    • / Arvind Ravulavaru

      Yup, you are right. It is not needed. You can use either approaches to achieve the same result.

  • Tadeo Riveros Koloszwa

    I learned a lot with this post, great code examples.

    Also I think you can improve your code example named ‘fileOne.js’ replacing the ‘else’ sentence just using ‘if(){ return…}’ and then the second ‘return’ sentence outside of the if structure. You save a second and evident evaluation. I just tried out and worked the same way.

    • / Arvind Ravulavaru

      Thanks Tadeo.

      I understand what you are saying. The modified fileOne.js would look like

      This is another way you can write the existing logic. Thanks for the suggestion.

      AFAIK, both the ways are exactly same. In my example, if if condition is met, it will go inside the block, else into the else block. And in the one you have mentioned, if if condition is met, it will go else the block, else it comes out of the if construct and executes the return statement.

      Your thoughts?

      Thanks.

  • Alfred

    I know it may be too late, but in the last code block, you emit “strike” but the event listener is attached to “swing” event… so nothing’s gonna happen in the example. I know it’s just a minor, but beginers will keep on waiting for ever and nothing is gonna happen. I mean, I would expect Babe Ruth to never miss a swing and earn a strike, but that won’t help the example :)

    • / Arvind Ravulavaru

      Thanks Alfred! Fixed it.

  • / Arvind Ravulavaru

    Thanks AppleFreak. Glad I could be of help.

  • AppleFreak

    This is one of the most comprehensive Node introduction I’ve ever read! Clean and clear! Thank you very much!

    • / Arvind Ravulavaru

      Thanks AppleFreak. Glad I could be of help