The Node Craftsman Book

Manuel Kiessling

• Publisher: Packt Publishing
• Year: 2017
• eBook ISBN: 9781787289253
• Edition: 1
• Topic: Computer Science
• Subtopic: Entreprise Applications
• Index: Computer Science

Become a Node.js craftsman.About This Book• This book will help readers to dive deeper into software development with Node.js and JavaScript• Takes a craftsman approach to Node.js and object-orientation and test-driven development• Crafts many of the small details of Node.js and through to fully-fledged web applications with REST Who This Book Is ForThis book is written to help you if you're working with Node.js already, but you want to move your craft to the next level with Node.js, so some working knowledge of Node.js is of course already assumed, so that we can look at the work of crafting applications with Node.What You Will Learn• How to connect to databases like MongoDB and MySQL from your Node.js application• How to unit tests and end-to-end tests for your code• When and how to leverage migrations for setting up a continuous deployment workflow• Detailed insight into how the Node Package Manager, NPM works• How object-orientation actually works in JavaScript• Ways to keep your code fast and efficient using asynchronous and non-blocking operations• How to use and create event emitters• How to use REST frameworks to write full-fledged web applications• How to integrate Node.js with AngularIn DetailThe Node Craftsman Book helps JavaScript programmers with basic Node.js knowledge to now thoroughly master Node.js and JavaScript. This book dives you deeper into the craft of software development with Node.js and JavaScript, incuding object-orientation, test-driven development, database handling, web frameworks, and much more.The Node Craftsman Book shows you how to work with Node.js and how to think deeply about how you build your Node projects. You'll master how to build a complete Node.js application across six crafting milestones, and you'll learn many specific skills to achieve that mastery. These skills include how to work with the Node Package Manager in depth, how to connect your Node applications to databases, and how to write unit tests and end-to-end tests for your code. You'll experience the full Node.js development picture, and learn how to craft and control your Node.js applications - right through to fully-fledged web applications using REST, and integration with Angular applications.Style and approachThis book builds on your early knowledge and experience of Node.js and takes a craftsman approach to understanding the whole picture more deeply and shaping your Node applications to perform the way a craftsman would want. So, we take a thoughtful and broad thinking and coding approach to work with Node.js in this book.

Part 1: Node.js Basics in Detail

Introduction to Part 1

The goal of this book is to enable you to write Node.js programs of any level of complexity, from simple utilities to complex applications that use several external modules and consist of several layers of code, talking to external systems and serving thousands of users.

In order to do so, you need to learn about all the different aspects of Node.js – the tools, the methodologies, the libraries, the APIs, the best practices – and you need to learn how to put all of that together to create a working whole.

Therefore, I have split this book into two parts: A collection of different basics in this part, and a thorough tutorial on how to put these basics together to build a complex application in Part 2, Building a Complete Web Application with Node.js and Angular.

In Part 1, every chapter stands on its own and isn't directly related to the other chapters. Part 2 is more like a continuous story that starts from scratch and gives you a finished and working application at the end.

Thus, let's start with Part 1 and look at all the different facets of Node.js software development.

Working with NPM and Packages

We already used NPM, the Node Package Manager, in order to install a single package and its dependencies for the example project in The Node Beginner Book.

However, there is much more to NPM, and a more thorough introduction is in order.

The most useful thing that NPM does isn't installing packages. This could be done manually with slightly more hassle. What's really useful about NPM is that it handles package dependencies. A lot of packages that we need for our own project need other packages themselves. Have a look at h t t p s ://n p m j s . o r g /p a c k a g e /r e q u e s t, for example. It's the overview page for the NPM package request. According to its description, it provides a simplified HTTP request client. But in order to do so, request not only uses its own code. It also needs other packages for doing its job. These are listed under Dependencies: qs, json-stringify-safe, and others.

Whenever we use the NPM command line tool, npm, in order to install a package, NPM not only pulls the package itself, but also its dependencies, and installs those as well.

Using npm install request is simply a manual way to implicitly say my project depends on request, please install it for me. However, there is an explicit way of defining dependencies for our own projects, which also allows to have all dependencies resolved and installed automatically.

In order to use this mechanism, we need to create a control file within our project that defines our dependencies. This control file is then used by NPM to resolve and install those dependencies.

This control file must be located at the top level folder of our project, and must be named package.json.

This is what a package.json file looks like for a project that depends on request:

{
   "dependencies": {
     "request": ""
   }
 }

Having this file as part of our code base makes NPM aware of the dependencies of our project without the need to explicitly tell NPM what to install by hand.

We can now use NPM to automatically pull in all dependencies of our project, simply by executing npm install within the top level folder of our code base.

In this example, this doesn't look like much of a convenience win compared to manually installing request, but once we have more than a handful of dependencies in our projects, it really makes a difference.

The package.json file also allows us to pin dependencies to certain versions, i.e., we can define a version number for every dependency, which ensures that NPM won't pull the latest version automatically, but exactly the version of a package we need:

{
   "dependencies": {
     "request": "2.27.0"
   }
 }

In this case, NPM will always pull request version 2.27.0 (and the dependencies of this version), even if newer versions are available.

Patterns are possible, too:

{
   "dependencies": {
     "request": "2.27.x"
   }
 }

The x is a placeholder for any number. This way, NPM would pull in request version 2.27.0 and 2.27.5, but not 2.28.0.

The official documentation at h t t p s ://d o c s . n p m j s . c o m /m i s c /s e m v e r has more examples of possible dependency definitions.

Please note that the package.json file does much more than just defining dependencies. We will dig deeper in the course of this book.
For now, we are prepared to use NPM for resolving the dependencies that arise in our first project – our first test-driven Node.js application.

Downloading the example code
You can download the example code files for this book from your account at h t t p ://w w w . p a c k t p u b . c o m . The code bundle for the book is also hosted on GitHub at
https://github.com/PacktPublishing/The-Node-Craftsman-Book

Test-driven Node.js Development

The code examples in The Node Beginner Book only described a toy project, and we came away with not writing any tests for it. If writing tests is new for you, and you have not yet worked on software in a test-driven manner, then I invite you to follow along and give it a try.

We need to decide on a test framework that we will use to implement our tests. A lack of choice is not an issue in the JavaScript and Node.js world, as there are dozens of frameworks available. Personally, I prefer Jasmine, and will therefore use it for my examples.

Jasmine is a framework that follows the philosophy of behaviour-driven development, which is kind of a subculture within the community of test-driven developers. This topic alone could easily fill its own book, thus I'll give only a brief introduction.

The idea is to begin development of a new software unit with its specification, followed by its implementation (which, by definition, must satisfy the specification).

Let's make up a real world example: we order a table from a carpenter. We do so by specifying the end result:

I need a table with a top that is 6 x 3 ft. The height of the top must be adjustable—2.5 to 4.0 ft. I want to be able to adjust the top's height without standing up from my chair. I want the table to be black, and cleaning it with a wet cloth should be possible without damaging the material. My budget is $500.

Such a specification allows to share a goal between us and the carpenter. We don't have to care for how exactly the carpenter will achieve this goal. As long as the delivered product fits our specification, both of us can agree that the goal has been reached.

With a test-driven or behaviour-driven approach, this idea is applied to building software. You wouldn't build a piece of software and then define what it's supposed to do. You need to know in advance what you expect a unit of software to do. Instead of doing this vaguely and implicitly, a test-driven approach asks you to do the specification exactly and explicitly. Because we work on software, our specification can be software, too: we only need to write functions that check if our unit does what it is expected to do. These check functions are unit tests.

Let's create a software unit which is covered by tests that describe its expected behaviour. In order to actually drive the creation of the code with the tests, let's write the tests first. We then have a clearly defined goal: making the tests pass by implementing code that fulfills the expected behaviour, and nothing else.

In order to do so, we create a new Node.js project with two folders in it:

 src/ spec/ 

The spec folder is where our test cases go – in Jasmine lingo, these are called specifications, hence spec. The spec folder mirrors the file structure under src, that is, a source file at src/foo.js is mirrored by a specification at spec/fooSpec.js.

Following the tradition, we will test and implement a Hello World code unit. Its expected behaviour is to return a string Hello Joe! if called with Joe as its first and only parameter. This behaviour can be specified by writing a unit test.

To do so, we create a file spec/greetSpec.js, with the following content:

 'use strict';  var greet = require('../src/greet'); describe('greet', function() { it('should greet the given name', function() { expect(greet('Joe')).toEqual('Hello Joe!'); }); it('should greet no-one special if no name is given', function() { expect(greet()).toEqual('Hello world!'); }); }); 

This is a simple, yet complete specification. It is a programmatical description of the behaviour we expect from a yet-to-be-written function named greet.

The specification says that if the function greet is called with Joe as its first and only parameter, the return value of the function call should be the string Hello Joe!. If we don't supply a name, the greeting should be generic.

As you can see, Jasmine specifications have a two-level structure. The top level of this structure is a describe block, which consists of one or more it blocks.

An it block describes a single expected behaviour of a single unit under test, and a describe block summarizes one or more blocks of expected behaviours, therefore completely specifying all expected behaviours of a unit.

Let's illustrate this with a real-world unit described by a Jasmine specification:

 describe( 'A candle' , function() { it( 'should burn when lighted' , function() { // ... }); it( 'should grow smaller while burning' , function() { // ... }); it( 'should no longer burn when all wax has been burned', function(){ // ... }); it( 'should go out when no oxygen is available to it' , function() { // ... }); });  

As you can see, a Jasmine specification gives us a structure to fully describe how a given unit should behave.

Not only can we describe expected behaviour, we can also verify it. This can be done by running the test cases in the specification against the actual implementation.

After all, our Jasmine specification is just another piece of JavaScript code which can be executed. The NPM package jasmine-node ships with a test case runner which allows ...

Table of contents

• Title Page
• Copyright
• Credits
• About the Author
• www.PacktPub.com
• Customer Feedback
• Preface
• Part 1: Node.js Basics in Detail
• Working with NPM and Packages
• Test-driven Node.js Development
• Object-oriented JavaScript
• Synchronous and Asynchronous Operations Explained
• Using and Creating Event Emitters
• Optimizing Code Performance and Control Flow Management Using the Async Library
• Node.js and MySQL
• Node.js and MongoDB
• Part 2: Building a Complete Web Application with Node.js and Angular
• Milestone 1 – A First Passing Test Against the Server
• Milestone 2 – The API Responds with Actual Database Content
• Milestone 3 – Setting the Stage for a Continuous Delivery Workflow
• Milestone 4 – Giving Users a Frontend
• Milestone 5 – More Work on the Backend
• Milestone 6 – Completing the Backend and Finalizing the Application