Welcome to Part 3 of this review of the Pluralsight course Node Application Patterns by Rob Conery
Rob has been working in the technology field full time since 1998 as a DBA and then a web developer.
His original focus was the Microsoft ASP.NET stack, building tools like Subsonic and the first Micro-ORM: Massive. He co-founded the online training site Tekpub.com with James Avery and co-host This Developer’s Life with Scott Hanselman.
Tekpub was bought out by Pluralsight and he worked there for two years. He is currently working on a new book called The Imposters Handbook.
Node Applications Patterns is the final course in the Node JS learning path.
Building a Registration Module
We start with some basic unit tests for a default user, e.g.
- has an authentication token
- has a pending status
- has a signInCount of 0
In order to run our User tests we need a function defined. Rob exports an empty function.
The constructor and factory patterns are introduced here.
By the end of this lesson we have 7 passing tests.
A Pattern Discussion
Rob picks out the module pattern, revealing module pattern and the prototype pattern for discussion.
Defining a Service
The first couple of minutes cover unit testing with Rob writing registration_spec.js
Then we see registration.js created. Rob creates a function which accepts an args object as the argument. This is preferable to passing in primitive parameters.
We also see application.js being built.
Dealing with Data
In this lesson Rob uses RethinkDB. This project now has an official Windows package so Windows users don’t need to install a VM anymore to try it out.
RethinkDB also has packages for Ubuntu, OS X, CentOS and Debian.
Rob Conery wrote a light wrapper for RethinkDB called Second Thought and we see some code from that.
The RethinkDB Web interface displays. This is where we can manage almost all aspects of our RethinkDB server, including sharding and replication.
Rob explains why it’s good practice to refactor away data access code from application logic and we see dependency injection used to pass the data access into our constructor.
So here we move from a module pattern to a constructor pattern. We must also update registration_spec to work with this new pattern.
We see asynchronous code being used as if it is synchronous code. This is bad.
Using a done flag function we can resolve this problem. Mocha simply waits until done is done before moving on. So although the database function is async, our tests stay in sync.
Saving the User Record
Rob uses bcrypt to hash the user’s private data:
npm install bcrypt-nodejs –save
There’s a timeout before our function is returning. We are seeing a callback hell situation.
Rob fights his way out with console.log messages.
Once it’s working, we see the data via the RethinkDB console.
Pyramid of Doom
Rob runs through the code style mistakes discusses possible alternatives:
- use named functions
- use promises
- use async.js
However, Rob’s preference is to use the EventEmitter.
We start off by requiring Node’s events module and util module.
We can’t remove the callbacks altogether because Node expects them in order to work.
To use both events and a callback, we can create a variable called continueWith and assign the next argument to it. This pattern knocks down the pyramid of doom.
We write function registrationOk and in here we create a callback if continueWith is truthy.
This module has gone through the process quite slowly, but in the next module we ramp things up.