# data[].attributes.body
1. Finish Node.js series

# data[].attributes.body
Resources for new Go programmers - https://dave.cheney.net/resources-for-new-go-programmers

Must Reads (in order):

A tour of Go - https://tour.golang.org/list

How to Write Go Code - https://golang.org/doc/code.html

Effective Go - https://golang.org/doc/effective_go.html

SOLID Go Design - https://dave.cheney.net/2016/08/20/solid-go-design

Writing Web Applications - https://golang.org/doc/articles/wiki/

Other:

Tutorials and apps - https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw

blog - https://dave.cheney.net/category/golang

awesome-go - https://github.com/avelino/awesome-go

Essential Go - https://www.programming-books.io/essential/go/

(not sure) Build web applications with Golang - https://astaxie.gitbooks.io/build-web-application-with-golang/content/en/

50 shades of Go - http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/

# data[].attributes.attachment_link.description
Mocha is a simple, extensible and fast testing library for Node.js. This article will walk you through its installation, configuration and usage.

# data[].attributes.attachment_link.description
The event loop follows the rather usual single threaded asynchronous I/O approach: all (network) I/O is performed on non-blocking sockets which are polled using the best mechanism available on the given platform: epoll on Linux, kqueue on OSX and other BSDs, event ports on SunOS and IOCP on Windows.

# data[].attributes.attachment_link.title
Express Tutorial Part 4: Routes and controllers

# data[].attributes.attachment_link.description
We've now created all the routes for our site, along with dummy controller functions that we can populate with a full implementation in later articles. Along the way we've learned a lot of fundamental information about Express routes, and some approaches for structuring our routes and controllers.

# data[].attributes.body
https://blog.risingstack.com/node-hero-tutorial-getting-started-with-node-js/

https://nodejs.org/en/docs/guides/

https://blog.risingstack.com/node-js-at-scale-understanding-node-js-event-loop/

https://developer.mozilla.org/en-US/

https://nodejs.org/docs/latest-v8.x/api/index.html .
https://expressjs.com/

http://iproduct.org/wp-content/uploads/2018/03/IPT_JS_App_Development_2018_011.pdf
event loop: https://www.youtube.com/watch?v=8aGhZQkoFbQ&index=3&list=PLZkqyoGSU7ndgrJzcs9u3nx1UcBMuV-qU&t=0s

OOP in JS - https://www.youtube.com/watch?v=PMfcsYzj-9M&index=2&list=PLZkqyoGSU7ndgrJzcs9u3nx1UcBMuV-qU&t=2s

https://www.youtube.com/watch?v=Mus_vwhTCq0&index=3&list=PLZkqyoGSU7ndgrJzcs9u3nx1UcBMuV-qU
Books - https://github.com/aisuhua/books-1/tree/master/nodejs/

# data[].attributes.attachment_link.readable_text
Node.js can be intimidating to beginners. But its flexible structure and lack of strict guidelines makes it seem more complicated than it is.

This tutorial is a quick and simple guide to Node.js, the Express framework, and MongoDB, focusing on the fundamental REST routes and basic database interaction. You'll build a simple API boilerplate that can then be used as the foundation for any app.

Who This Tutorial Is For: You should have a basic understanding of REST APIs and CRUD operations, plus basic JavaScript knowledge. I use ES6 (mainly fat-arrow functions), but nothing too complex.

For this tutorial, you'll create the skeleton of a back-end for a note-taking application - think Google Keep. You want to be able to do all four CRUD actions on your notes: create, read, update, and delete.

Setting Up

If you don't have Node installed, see here.

In a new directory, run npm init, and follow along with the prompts, giving your app the name of 'notable' (or whatever else you might like).

npm init

Once that's done, you should have a package.json ready to go in your directory. This means you can start installing the dependencies you need for your project.

You're going to use Express as your framework, MongoDB as the database, and a package called body-parser to help deal with JSON requests.

npm install --save express mongodb@2.2.16 body-parser

I also highly recommend installing Nodemon as a dev dependency. It's a simple little package that automatically restarts your server when files change.

If you run:

npm install --save-dev nodemon

You can then add the following script to package.json:

// package.json

  "scripts": {
 "dev": "nodemon server.js"
 },

Your complete package.json should look like this:

// package.json

Now you can create your server.js fileand start building your API.

Our Server

Let's start by requiring all your dependencies in server.js.

// server.js

const express        = require('express');
const MongoClient = require('mongodb').MongoClient;
const bodyParser = require('body-parser');

const app            = express();

You're going to use the MongoClient to interact with your database. Note that you also initialize your app as an instance of Express, your framework.

The last thing you need to do to get your server up and running is to tell your app to start listening for HTTP requests.

You can specify a port, and start the listening like so:

// server.js

const port = 8000;

app.listen(port, () => {
 console.log('We are live on ' + port);
});

Now if you run npm run dev (or node server.js if you didn't install Nodemon) you should see 'We are live on port 8000' in the terminal.

Your server is live. But it doesn't do a whole lot. Or anything, really.

Let's fix that.

CRUDdy Routes

For this example, you want to build 4 routes; to CREATE a note, to READ your notes, to UPDATE a note, and to DELETE a note.

This will give you a good idea of how to structure almost any basic route with Node.

To test your API, though, you need to mimic a client side making requests. To do so, you'll use a great app called Postman. It allows you to make simple HTTP requests with custom bodies and parameters.

Install Postman, and let's start setting up your routes.

Super Organized

Most Node.js tutorials (and many real apps) put all their routes in one big routes.js file. This makes me a wee bit uncomfortable. In contrast, splitting up your files into separate folders leads to good readability, and makes big apps more manageable.

You don't have a big app, but let's do this right. Make the following directories: an app folder with a routes folder inside it, with an index.js and a note_routes.js file inside it.

In other words: root > app > routes > index.js and note_routes.js.

mkdir app
cd app
mkdir routes
cd routes
touch index.js
touch note_routes.js

These directories may seem like overkill for your simple small app, but it's always good to start with best practices.

Your First Route

Let's start with the C in CRUD- create. How would you create a note?

Well, before you do that, you have to build a bit more infrastructure. In Express, routes are wrapped in a function, which takes the Express instance and a database as arguments.

Like this:

// routes/note_routes.js

module.exports = function(app, db) {

};

You can then export this function through your index.js:

// routes/index.js

const noteRoutes = require('./note_routes');

module.exports = function(app, db) {
 noteRoutes(app, db);
 // Other route groups could go here, in the future
};

Then import it for use in server.js:

// server.js

const express        = require('express');
const MongoClient = require('mongodb').MongoClient;
const bodyParser = require('body-parser');

const app            = express();

const port = 8000;

require('./app/routes')(app, {});
app.listen(port, () => {
 console.log('We are live on ' + port);
});

Note that since you don't have a database yet set up, you're just passing in an empty object.

Okay, now you can make your CREATE route.

The syntax is simple:

// note_routes.js

module.exports = function(app, db) {
 app.post('/notes', (req, res) => {
 // You'll create your note here.
 res.send('Hello')
 });
};

When the app receives a post request to the '/notes' path, it will execute the code inside the callback- passing in a request object (which contains the parameters or JSON of the request) and a response object (used to reply).

You can test this by using Postman to send a POST request to localhost:8000/notes.

Nice! You created your first real route.

Next step is to add some parameters to your request and process them in your API and, finally, add in your database.

Request Parameters

In Postman, go to the Body tab and add some key-value pairs, after selecting the x-www-form-urlencoded radio button.

This will add encoded form data to your request, which you'll be able to process with your API.

Now in your note_routes.js, let's just log out the body.

// note_routes.js

module.exports = function(app, db) {
 app.post('/notes', (req, res) => {
 console.log(req.body)
 res.send('Hello')
 });
};

Try sending the Postman request and you'll see... undefined.

Unfortunately, Express can't process URL encoded forms on its own. But you did install that body-parser package...

// server.

const express        = require('express');
const MongoClient = require('mongodb').MongoClient;
const bodyParser = require('body-parser');

const app            = express();

const port = 8000;

app.use(bodyParser.urlencoded({ extended: true }));

require('./app/routes')(app, {});
app.listen(port, () => {
 console.log('We are live on ' + port);
});

Now you should see the body as an object in the terminal.

{ title: 'My Note Title', body: 'What a great note.' }

Last step to your preliminary route: set up the database, and then add your data in.

The easiest way to set up a Mongo database is through mLab: it's free for the smallest size, and quite fast to setup.

Once you create an account and a MongoDB deployment, add a user to the database with a username and password:

then grab the URL here (the second one):

And in a directory config in the root of your project, create a db.js file.

mkdir config
cd config
touch db.js

Inside, add the URL:

module.exports = {
 url : YOUR URL HERE
};

Don't forget to add your username and password (the ones from the database user, not your mLab account) into the URL. (If you're committing this project to Github, be sure to include a .gitignore file like so, so you don't share your password with everyone.)

Now in your server.js, you can use the MongoClient to connect to your DB, and use this to wrap your app setup:

// server.js

const express        = require('express');
const MongoClient = require('mongodb').MongoClient;
const bodyParser = require('body-parser');
const db = require('./config/db');

const app            = express();

const port = 8000;

app.use(bodyParser.urlencoded({ extended: true }));

MongoClient.connect(db.url, (err, database) => {
 if (err) return console.log(err)
 require('./app/routes')(app, database);

 app.listen(port, () => {
 console.log('We are live on ' + port);
 });
})

If you're using the latest version of the MongoDB (3.0+), modify it like so:

// server.js

const express        = require('express');
const MongoClient = require('mongodb').MongoClient;
const bodyParser = require('body-parser');
const db = require('./config/db');

const app            = express();

const port = 8000;

app.use(bodyParser.urlencoded({ extended: true }));

MongoClient.connect(db.url, (err, database) => {
 if (err) return console.log(err)

  // Make sure you add the database name and not the collection name
 db = database.db("note-api")
 require('./app/routes')(app, db);

  app.listen(port, () => {
 console.log('We are live on ' + port);
 });
})

That's the last of your infrastructure setup! It's all route-building from here.

Adding to your Database

MongoDB stores data in collections- which are exactly how they sound. In your case, you want to store your notes in a collection called - you guessed it - notes.

Since you pass in your database as the db argument in your routes, you can then access it like so:

db.collection('notes')

Creating a note is as simple as calling insert on your collection:

const note = { text: req.body.body, title: req.body.title}
 db.collection('notes').insert(note, (err, results) => {
}

Once the insert is complete (or has failed for whatever reason), you want to either send back an error or send back the newly created note object. Here's the full note_routes.js:

// note_routes.js

module.exports = function(app, db) {
 const collection =
 app.post('/notes', (req, res) => {
 const note = { text: req.body.body, title: req.body.title };
 db.collection('notes').insert(note, (err, result) => {
 if (err) {
 res.send({ 'error': 'An error has occurred' });
 } else {
 res.send(result.ops[0]);
 }
 });
 });
};

Try it out! Send an x-www-form-urlencoded POST request with Postman, with a title and body set under the Body tab.

The response should look like this:

If you log into mLab, you should also see the created note in the database.

Your READ Route

Now you can pick up the pace a bit.

Say you wanted to get back the note you just created, by navigating to localhost:8000/notes/{the id}. In this case, that would be localhost:8000/notes/585182bd42ac5b07a9755ea3.

(If you don't have the ID for one of your notes, you can check on mLab or just create a new one).

Here's what this would look like in note_routes.js:

// note_routes.js

module.exports = function(app, db) {

  app.post('/notes', (req, res) => {
 const note = { text: req.body.body, title: req.body.title };
 db.collection('notes').insert(note, (err, result) => {
 if (err) {
 res.send({ 'error': 'An error has occurred' });
 } else {
 res.send(result.ops[0]);
 }
 });
 });
};

Just like before, you're going to call a method on your database collection of notes. Here, it's the aptly named findOne.

// note_routes.js

module.exports = function(app, db) {
 app.get('/notes/:id', (req, res) => {
 const details = { '_id': <ID GOES HERE> };
 db.collection('notes').findOne(details, (err, item) => {
 if (err) {
 res.send({'error':'An error has occurred'});
 } else {
 res.send(item);
 }
 });
 });

app.post('/notes', (req, res) => {
 const note = { text: req.body.body, title: req.body.title };
 db.collection('notes').insert(note, (err, result) => {
 if (err) {
 res.send({ 'error': 'An error has occurred' });
 } else {
 res.send(result.ops[0]);
 }
 });
 });
};

You can grab the id from the URL parameters via req.params.id. However, if you try to just plop in the string into the <> above, it won't work.

MongoDB requires not just an ID as a string, but as an ID object or, as they call it, an ObjectID.

Don't worry, it's an easy fix. Here's the full code:

// note_routes.js

var ObjectID = require('mongodb').ObjectID;

module.exports = function(app, db) {
 app.get('/notes/:id', (req, res) => {
 const id = req.params.id;
 const details = { '_id': new ObjectID(id) };
 db.collection('notes').findOne(details, (err, item) => {
 if (err) {
 res.send({'error':'An error has occurred'});
 } else {
 res.send(item);
 }
 });
 });

app.post('/notes', (req, res) => {
 const note = { text: req.body.body, title: req.body.title };
 db.collection('notes').insert(note, (err, result) => {
 if (err) {
 res.send({ 'error': 'An error has occurred' });
 } else {
 res.send(result.ops[0]);
 }
 });
 });
};

Try it out with one of your note ID's, and it should look like this:

Your DELETE Route

Deleting an object is actually pretty much the same as finding an object. You just use the remove function instead of the findOne. Here's the full code. I've highlighted what's different from your GET:

// note_routes.js

// ...

  app.delete('/notes/:id', (req, res) => {
 const id = req.params.id;
 const details = { '_id': new ObjectID(id) };
 db.collection('notes').remove(details, (err, item) => {
 if (err) {
 res.send({'error':'An error has occurred'});
 } else {
 res.send('Note ' + id + ' deleted!');
 }
 });
 });

// ...

Your UPDATE Route

Last one! The PUT is basically a hybrid between READ and CREATE. You find the object, then update it accordingly. If you deleted your only note, time to make another one!

The code:

// note_routes.js

// ...

  app.put('/notes/:id', (req, res) => {
 const id = req.params.id;
 const details = { '_id': new ObjectID(id) };
 const note = { text: req.body.body, title: req.body.title };
 db.collection('notes').update(details, note, (err, result) => {
 if (err) {
 res.send({'error':'An error has occurred'});
 } else {
 res.send(note);
 }
 });
 });

// ...

Now you can update any of your notes, like so:

Note the imperfection with this code- if you fail to supply a body or title, the PUT request will nullify those fields on the note in the database.

You could easily add some conditional logic to update the fields only if they're present in the request- I left that out just to keep it simple.

API Complete

That's it! You have a working Node API with each of the four major CRUD operations.

The goal of this tutorial was to give you a degree of familiarity with Express, Node, and MongoDB - you can use your simple app as a launching pad for more complex projects.

In the future I'll be writing tutorials to create more simple API's in different languages and frameworks. Hit the follow button if you're interested!

If this tutorial was any help to you, please hit the green heart below- it means a lot. Feel free to also leave me a comment with any feedback or questions.

Thanks for reading!

# data[].attributes.attachment_link.title
Build a Node.js API in Under 30 Minutes - freeCodeCamp.org

# data[].attributes.attachment_link.description
Node.js can be intimidating to beginners. But its flexible structure and lack of strict guidelines makes it seem more complicated than it is. This tutorial is a quick and simple guide to Node.js, the Express framework, and MongoDB, focusing on the fundamental REST routes and basic database interaction.

# data[].attributes.attachment_link.title
Express - Node.js web application framework

# data[].attributes.attachment_link.description
Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

# data[].attributes.body
rabitmq
cassandra
kafka
ealsticsearch
bosch
redis
joi validator
picocli

# data[].attributes.attachment_link.provider_name
RisingStack Engineering - Node.js Tutorials & Resources

# data[].attributes.attachment_link.readable_text
One of our client's microservices started to produce the following memory usage:
Memory usage grabbed with Trace
You may spend quite a few days on things like this: profiling the application and looking for the root cause. In this post, I would like to summarize what tools you can use and how, so you can learn from it.

UPDATE: This article mentions Trace, RisingStack's Node.js Monitoring platform several times. On 2017 October, Trace has been merged with Keymetrics's APM solution. Click here to give it a try!

The TL;DR version

In our particular case the service was running on a small instance, with only 512MB of memory. As it turned out, the application didn't leak any memory, simply the GC didn't start collecting unreferenced objects.

Why was it happening? As a default, Node.js will try to use about 1.5GBs of memory, which has to be capped when running on systems with less memory. This is the expected behaviour as garbage collection is a very costly operation.

The solution for it was adding an extra parameter to the Node.js process:

node --max_old_space_size=400 server.js --production

*Still, if it is not this obvious, what are your options to find memory leaks?*The React.js Way: Getting Started Tutorial

Understanding V8's Memory Handling

Before diving into the technics that you can employ to find and fix memory leaks in Node.js applications, let's take a look at how memory is handled in V8.

Definitions

resident set size: is the portion of memory occupied by a process that is held in the RAM, this contains:

stack: contains primitive types and references to objects

heap: stores reference types, like objects, strings or closures

shallow size of an object: the size of memory that is held by the object itself

retained size of an object: the size of the memory that is freed up once the object is deleted along with its' dependent objects

How The Garbage Collector Works

Garbage collection is the process of reclaiming the memory occupied by objects that are no longer in use by the application. Usually, memory allocation is cheap while it's expensive to collect when the memory pool is exhausted.

An object is a candidate for garbage collection when it is unreachable from the root node, so not referenced by the root object or any other active objects. Root objects can be global objects, DOM elements or local variables.

The heap has two main segments, the New Space and the Old Space. The New Space is where new allocations are happening; it is fast to collect garbage here and has a size of ~1-8MBs. Objects living in the New Space are called Young Generation. The Old Space where the objects that survived the collector in the New Space are promoted into - they are called the Old Generation. Allocation in the Old Space is fast, however collection is expensive so it is infrequently performed .

Why is garbage collection expensive? The V8 JavaScript engine employs a stop-the-world garbage collector mechanism. In practice, it means that the program stops execution while garbage collection is in progress.

Usually, ~20% of the Young Generation survives into the Old Generation. Collection in the Old Space will only commence once it is getting exhausted. To do so the V8 engine uses two different collection algorithms:

Scavenge collection, which is fast and runs on the Young Generation,

Mark-Sweep collection, which is slower and runs on the Old Generation.

For more information on how this works check out the A tour of V8: Garbage Collection article. For more information on general memory management, visit the Memory Management Reference.
Tools / Technics You Can Use to Find a Memory Leak in Node.js

The heapdump module

With the heapdump module, you can create a heap snapshot for later inspection. Adding it to your project is as easy as:

npm install heapdump --save

Then in your entry point just add:

var heapdump = require('heapdump');

Once you are done with it, you can start collecting heapdump with either using the $ kill -USR2 <pid> command or by calling:

heapdump.writeSnapshot(function(err, filename) { console.log('dump written to', filename); });

Once you have your snapshots, it's time to make sense of them. Make sure you capture multiple of them with some time difference so you can compare them.

Google Chrome DevTools

First you have to load your memory snapshots into the Chrome profiler. To do so, open up Chrome DevTools, go to profiles and Load your heap snapshots.

Once you loaded them it should be something like this:
So far so good, but what can be seen exactly in this screenshot?
One of the most important things here to notice is the selected view: Comparison. This mode enables you to compare two (or more) heap snapshots taken at different times, so you can pinpoint exactly what objects were allocated and not freed up in the meantime.

The other important tab is the Retainers. It shows exactly why an object cannot be garbage collected, what is holding a reference to it. In this case the global variable called log is holding a reference to the object itself, preventing the garbage collector to free up space.

Low-Level Tools

mdb

The mdb utility is an extensible utility for low-level debugging and editing of the live operating system, operating system crash dumps, user processes, user process core dumps, and object files.

gcore

Generate a core dump of a running program with process ID pid.

Putting it together

To investigate dumps, first we have to create one. You can easily do so with:

gcore `pgrep node`

After you have it, you can search for the all the JS Objects on the heap using:

> ::findjsobjects

Of course, you have to take successive core dumps so that you can compare different dumps.

Once you identified objects that look suspicious, you can analyze them using:

object_id::jsprint

Now all you have to do is find the retainer of the object (the root).

object_id::findjsobjects -r

This command will return with id of the retainer. Then you can use ::jsprint again to analyze the retainer.

For a detailed version check out Yunong Xiao's talk from Netflix on how to use it:

Recommended Reading

UPDATE: Read the story of how we found a memory leak in our blogging platform by comparing heapshots with Trace and Chrome's DevTools.

You have additional thoughts or insights on Node.js memory leaks? Share it in the comments.

# data[].attributes.attachment_link.title
Hunting a Ghost - Finding a Memory Leak in Node.js

# data[].attributes.attachment_link.description
One of our client's microservices started to produce the following memory usage: Memory usage grabbed with Trace You may spend quite a few days on things like this: profiling the application and looking for the root cause. In this post, I would like to summarize what tools you can use and how, so you can learn from it.

# data[].attributes.attachment_link.provider_name
RisingStack Engineering - Node.js Tutorials & Resources

# data[].attributes.attachment_link.readable_text
In the third chapter of Node.js at Scale you are about to learn how the Node.js module system & CommonJS works and what does require do under the hood.

With Node.js at Scale we are creating a collection of articles focusing on the needs of companies with bigger Node.js installations, and developers who already learned the basics of Node.

CommonJS to the rescue

The JavaScript language didn't have a native way of organizing code before the ES2015 standard. Node.js filled this gap with the CommonJS module format. In this article we will learn about how the Node.js module system works, how you can organize your modules and what does the new ES standard means for the future of Node.js.

What is the module system?

Modules are the fundamental building blocks of the code structure. The module system allows you to organize your code, hide information and only expose the public interface of a component using module.exports. Every time you use the require call, you are loading another module.

The simplest example can be the following using CommonJS:

// add.js function add (a, b) { return a + b } module.exports = add

To use the add module we have just created, we have to require it.

// index.js const add = require('./add') console.log(add(4, 5)) //9

Under the hood, add.js is wrapped by Node.js this way:

(function (exports, require, module, __filename, __dirname) { function add (a, b) { return a + b } module.exports = add })

This is why you can access the global-like variables like require and module. It also ensures that your variables are scoped to your module rather than the global object.

How does require work?

The module loading mechanism in Node.js is caching the modules on the first require call. It means that every time you use require('awesome-module') you will get the same instance of awesome-module, which ensures that the modules are singleton-like and have the same state across your application.

You can load native modules and path references from your file system or installed modules. If the identifier passed to the require function is not a native module or a file reference (beginning with /, ../, ./ or similar), then Node.js will look for installed modules. It will walk your file system looking for the referenced module in the node_modules folder. It starts from the parent directory of your current module and then moves to the parent directory until it finds the right module or until the root of the file system is reached.

Require under the hood - module.js

The module dealing with module loading in the Node core is called module.js, and can be found in lib/module.js in the Node.js repository.

The most important functions to check here are the _load and _compile functions.

Module._load

This function checks whether the module is in the cache already - if so, it returns the exports object.

If the module is native, it calls the NativeModule.require() with the filename and returns the result.

Otherwise, it creates a new module for the file and saves it to the cache. Then it loads the file contents before returning its exports object.

Module._compile

The compile function runs the file contents in the correct scope or sandbox, as well as exposes helper variables like require, module or exports to the file.

How Require Works - From James N. Snell

How to organize the code?

In our applications, we need to find the right balance of cohesion and coupling when creating modules. The desirable scenario is to achieve high cohesion and loose coupling of the modules.

A module must be focused only on a single part of the functionality to have high cohesion. Loose coupling means that the modules should not have a global or shared state. They should only communicate by passing parameters, and they are easily replaceable without touching your broader codebase.

We usually export named functions or constants in the following way:

'use strict' const CONNECTION_LIMIT = 0 function connect () { /* ... */ } module.exports = { CONNECTION_LIMIT, connect }

What's in your node_modules?

The node_modules folder is the place where Node.js looks for modules. npm v2 and npm v3 install your dependencies differently. You can find out what version of npm you are using by executing:

npm --version

npm v2

npm 2 installs all dependencies in a nested way, where your primary package dependencies are in their node_modules folder.

npm v3

npm3 attempts to flatten these secondary dependencies and install them in the root node_modules folder. This means that you can't tell by looking at your node_modules which packages are your explicit or implicit dependencies. It is also possible that the installation order changes your folder structure because npm 3 is non-deterministic in this manner.

You can make sure that your node_modules directory is always the same by installing packages only from a package.json. In this case, it installs your dependencies in alphabetical order, which also means that you will get the same folder tree. This is important because the modules are cached using their path as the lookup key. Each package can have its own child node_modules folder, which might result in multiple instances of the same package and of the same module.

How to handle your modules?

There are two main ways for wiring modules. One of them is using hard coded dependencies, explicitly loading one module into another using a require call. The other method is to use a dependency injection pattern, where we pass the components as a parameter or we have a global container (known as IoC, or Inversion of Control container), which centralizes the management of the modules.

We can allow Node.js to manage the modules life cycle by using hard coded module loading. It organizes your packages in an intuitive way, which makes understanding and debugging easy.

Dependency Injection is rarely used in a Node.js environment, although it is a useful concept. The DI pattern can result in an improved decoupling of the modules. Instead of explicitly defining dependencies for a module, they are received from the outside. Therefore they can be easily replaced with modules having the same interfaces.

Let's see an example for DI modules using the factory pattern:

class Car { constructor (options) { this.engine = options.engine } start () { this.engine.start() } } function create (options) { return new Car(options) } module.exports = create

The ES2015 module system

As we saw above, the CommonJS module system uses a runtime evaluation of the modules, wrapping them into a function before the execution. The ES2015 modules don't need to be wrapped since the import/ export bindings are created before evaluating the module. This incompatibility is the reason that currently there are no JavaScript runtime supporting the ES modules. There was a lot of discussion about the topic and a proposal is in DRAFT state, so hopefully we will have support for it in future Node versions.

To read an in-depth explanation of the biggest differences between CommonJS and the ESM, read the following article by James M Snell.

Next up

I hope this article contained valuable information about the module system and how require works. If you have any questions or insights on the topic, please share them in the comments. In the next chapter of the Node.js at Scale series, we are going to take a deep dive and learn about the event loop.

# data[].attributes.attachment_link.title
How the module system, CommonJS & require works | @RisingStack

# data[].attributes.attachment_link.description
In the third chapter of Node.js at Scale you are about to learn how the Node.js module system & CommonJS works and what does require do under the hood. With Node.js at Scale we are creating a collection of articles focusing on the needs of companies with bigger Node.js installations, and developers who already learned the basics of Node.

# data[].attributes.attachment_link.readable_text
I've found a very good article explaining the S.O.L.I.D. principles, if you are familiar with PHP, you can read the original article here: S.O.L.I.D: The First 5 Principles of Object Oriented Design. But since i am a JavaScript developer, i've adapted the code examples from the article into JavaScript.

JavaScript is a loosely typed language, some consider it a functional language, others consider it an object oriented language, some think its both, and some think that having classes in JavaScript is just plain wrong. - Dor Tzur

This is just a simple "welcome to S.O.L.I.D." article, it simply sheds light on what S.O.L.I.D. is.

S.O.L.I.D. STANDS FOR:

S - Single responsibility principle

O - Open closed principle

L - Liskov substitution principle

I - Interface segregation principle

D - Dependency Inversion principle

# Single responsibility principle

A class should have one and only one reason to change, meaning that a class should only have one job.

For example, say we have some shapes and we wanted to sum all the areas of the shapes. Well this is pretty simple right ?

First, we create our shapes factory functions and setup the required parameters.

What is a factory function ?

In JavaScript, any function can return a new object. When it's not a constructor function or class, it's called a factory function. why to use factory functions, this article provides a good explanation and this video also explain it very clear

Next, we move on by creating the areaCalculator factory function and then write up our logic to sum up the area of all provided shapes.

To use the areaCalculator factory function, we simply call the function and pass in an array of shapes, and display the output at the bottom of the page.

const areas = areaCalculator(shapes)
console.log(areas.output())

The problem with the output method is that the areaCalculator handles the logic to output the data. Therefore, what if the user wanted to output the data as json or something else ?

All of the logic would be handled by the areaCalculator factory function, this is what 'Single Responsibility principle' frowns against; the areaCalculator factory function should only sum the areas of provided shapes, it should not care whether the user wants JSON or HTML.

So, to fix this you can create an SumCalculatorOutputter factory function and use this to handle whatever logic you need on how the sum areas of all provided shapes are displayed.

The sumCalculatorOutputter factory function would work liked this:

const areas  = areaCalculator(shapes)
const output = sumCalculatorOputter(areas)

Now, whatever logic you need to output the data to the users is now handled by the sumCalculatorOutputter factory function.

# Open-closed Principle

Objects or entities should be open for extension, but closed for modification.

Open for extension means that we should be able to add new features or components to the application without breaking existing code.

Closed for modification means that we should not introduce breaking changes to existing functionality, because that would force you to refactor a lot of existing code - Eric Elliott

In simpler words, means that a class or factory function in our case, should be easily extendable without modifying the class or function itself. Let's look at the areaCalculator factory function, especially it's sum method.

sum () {

 const area = []

 for (shape of this.shapes) {

 if (shape.type === 'Square') {
 area.push(Math.pow(shape.length, 2)
 } else if (shape.type === 'Circle') {
 area.push(Math.PI * Math.pow(shape.length, 2)
 }
 }
 return area.reduce((v, c) => c += v, 0)
}

If we wanted the sum method to be able to sum the areas of more shapes, we would have to add more if/else blocks and that goes against the open-closed principle.

A way we can make this sum method better is to remove the logic to calculate the area of each shape out of the sum method and attach it to the shape's factory functions.

const square = (length) => {
 const proto = {
 type: 'Square',
 area () {
 return Math.pow(this.length, 2)
 }
 }
 return Object.assign(Object.create(proto), {length})
}

The same thing should be done for the circle factory function, an area method should be added. Now, to calculate the sum of any shape provided should be as simple as:

Now we can create another shape class and pass it in when calculating the sum without breaking our code. However, now another problem arises, how do we know that the object passed into the areaCalculator is actually a shape or if the shape has a method named area ?

Coding to an interface is an integral part of S.O.L.I.D., a quick example is we create an interface, that every shape implements.

Since JavaScript doesn't have interfaces, I'm going to show you, how this will be achieved in TypeScript, since TypeScript models the classic OOP for JavaScript, and the difference with pure JavaScript Prototypal OO.

interface ShapeInterface {
 area(): number
}

class Circle implements ShapeInterface {
 let radius: number = 0
 constructor (r: number) {
 this.radius = r
 }

 public area(): number {
 return MATH.PI * MATH.pow(this.radius, 2)
 }
}

In the example above demonstrates how this will be achieved in TypeScript, but under the hood TypeScript compiles the code to pure JavaScript and in the compiled code it lacks of interfaces since JavaScript doesn't have it.

So how can we achieved this, in the lack of interfaces ?

Function Composition to the rescue !

First we create shapeInterface factory function, as we are talking about interfaces, our shapeInterface will be as abstracted as an interface, using function composition, for deep explanation of composition see this great video.

Then we implement it to our square factory function.

const square = (length) => {
 const proto = {
 length,
 type : 'Square',
 area : (args) => Math.pow(args.length, 2)
 }
 const basics = shapeInterface(proto)
 const composite = Object.assign({}, basics)
 return Object.assign(Object.create(composite), {length})
}

And the result of calling the square factory function will be the next one:

// output
OBJ
 { length: 5 }
PROTO
 { type: 'shapeInterface', area: [Function: area] }
25

In our areaCalculator sum method we can check if the shapes provieded are actually types of shapeInterface, otherwise we throw an exception:

sum() {
 const area = []
 for (shape of this.shapes) {
 if (Object.getPrototypeOf(shape).type === 'shapeInterface') {
 area.push(shape.area())
 } else {
 throw new Error('this is not a shapeInterface object')
 }
 }

   return area.reduce((v, c) => c += v, 0)
}

and again, since JavaScript doesn't have support for interfaces like typed languages the example above demonstrates how we can simulate it, but more than simulating interfaces, what we are doing is using closures and function composition if you don't know what are a closure is this article explains it very well and for complementation see this video.

# Liskov substitution principle

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

All this is stating is that every subclass/derived class should be substitutable for their base/parent class.

In other words, as simple as that, a subclass should override the parent class methods in a way that does not break functionality from a client's point of view.

Still making use of our areaCalculator factory function, say we have a volumeCalculator factory function that extends the areaCalculator factory function, and in our case for extending an object without breaking changes in ES6 we do it by using Object.assign() and the Object.getPrototypeOf():

const volumeCalculator = (s) => {
 const proto = {
 type: 'volumeCalculator'
 }
 const areaCalProto = Object.getPrototypeOf(areaCalculator())
 const inherit = Object.assign({}, areaCalProto, proto)
 return Object.assign(Object.create(inherit), {shapes: s})
}

# Interface segregation principle

A client should never be forced to implement an interface that it doesn't use or clients shouldn't be forced to depend on methods they do not use.

Continuing with our shapes example, we know that we also have solid shapes, so since we would also want to calculate the volume of the shape, we can add another contract to the shapeInterface:

const shapeInterface = (state) => ({
 type: 'shapeInterface',
 area: () => state.area(state),
 volume: () => state.volume(state)
})

Any shape we create must implemet the volume method, but we know that squares are flat shapes and that they do not have volumes, so this interface would force the square factory function to implement a method that it has no use of.

Interface segregation principle says no to this, instead you could create another interface called solidShapeInterface that has the volume contract and solid shapes like cubes etc. can implement this interface.

const cubo = (length) => {
 const proto = {
 length,
 type : 'Cubo',
 area : (args) => Math.pow(args.length, 2),
 volume : (args) => Math.pow(args.length, 3)
 }
 const basics = shapeInterface(proto)
 const complex = solidShapeInterface(proto)
 const composite = Object.assign({}, basics, complex)
 return Object.assign(Object.create(composite), {length})
}

This is a much better approach, but a pitfall to watch out for is when to calculate the sum for the shape, instead of using the shapeInterface or a solidShapeInterface.

You can create another interface, maybe manageShapeInterface, and implement it on both the flat and solid shapes, this is way you can easily see that it has a single API for managing the shapes, for example:

const circle = (radius) => {
 const proto = {
 radius,
 type: 'Circle',
 area: (args) => Math.PI * Math.pow(args.radius, 2)
 }

  const basics = shapeInterface(proto)
 const abstraccion = manageShapeInterface(() => basics.area())
 const composite = Object.assign({}, basics, abstraccion)
 return Object.assign(Object.create(composite), {radius})
}

  const basics  = shapeInterface(proto)
 const complex = solidShapeInterface(proto)
 const abstraccion = manageShapeInterface(
 () => basics.area() + complex.volume()
 )
 const composite = Object.assign({}, basics, abstraccion)
 return Object.assign(Object.create(composite), {length})
}

As you can see until now, what we have been doing for interfaces in JavaScript are factory functions for function composition.

And here, with manageShapeInterface what we are doing is abstracting again the calculate function, what we doing here and in the other interfaces (if we can call it interfaces), we are using " high order functions" to achieve the abstractions.

If you don't know what a higher order function is you can go and check this video.

# Dependency inversion principle

Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.

As a dynamic language, JavaScript doesn't require the use of abstractions to facilitate decoupling. Therefore, the stipulation that abstractions shouldn't depend upon details isn't particularly relevant to JavaScript applications. The stipulation that high level modules shouldn't depend upon low level modules is, however, relevant.

From a functional point of view, these containers and injection concepts can be solved with a simple higher order function, or hole-in-the-middle type pattern which are built right into the language.

How is dependency inversion related to higher-order functions? is a question asked in stackExchange if you want a deep explanation.

This might sound bloated, but it is really easy to understand. This principle allows for decoupling.

And we have made it before, lets review our code with the manageShapeInterface and how we accomplish the calculate method.

What the manageShapeInterface factory function receives as the argument is a higher order function, that decouples for every shape the functionality to accomplish the needed logic to get to final calculation, let see how this is done in the shapes objects.

For the square what we need to calculate is just getting the area of the shape, and for a cubo, what we need is summing the area with the volume and that is everything need to avoid the coupling and get the abstraction.
# Complete code examples
# Further reading and references

# data[].attributes.attachment_link.title
S.O.L.I.D The first 5 principles of Object Oriented Design with JavaScript

# data[].attributes.attachment_link.description
I've found a very good article explaining the S.O.L.I.D. principles, if you are familiar with PHP, you can read the original article here: S.O.L.I.D: The First 5 Principles of Object Oriented Design. But since i am a JavaScript developer, i've adapted the code examples from the article into JavaScript.

# data[].attributes.attachment_link.readable_text
Testing is an important practice in software development to improve software quality. There are many forms of testing; manual testing, acceptance testing, unit testing, and a few others. In this post we are going to look at unit testing in Node using the Mocha test framework. Unit tests typically make up the majority of test suites. They test small units of code, typically a method or a function, . The key thing to remember is the in isolation aspect.

In this post, we'll start off writing unit tests for a function that simply takes some input, returns some output, and has no dependencies. Then we will look at two types of test doubles, stubs and spies, using the Sinon library. Lastly, we will look at how to test asynchronous code in Mocha. Let's get started!

Installing Mocha and Chai

To install Mocha, simply run:

npm install mocha -g

Unlike other JavaScript testing frameworks like Jasmine and QUnit, Mocha does not come with an assertion library. Instead, Mocha allows you to choose your own. Popular assertion libraries used with Mocha include should.js, expect.js, Chai, and Node's built in assert module. In this post, we are going to use Chai.

First, let's create a package.json file and install Chai:

touch package.json echo {} > package.json npm install chai --save-dev

Chai comes with three different assertion flavors. It has the should style, the expect style, and the assert style. They all get the job done and choosing one is just a matter of preference in how you want the language of your tests to read. Personally I like the expect style so we will be using that.

Your First Test

For our first example, we will use test driven development (TDD) to create a CartSummary constructor function, which will be used to total up items placed in a shopping cart. In short, TDD is the practice of writing tests before an implementation to drive the design of your code. TDD is practiced in the following steps:

1. Write a test and watch it fail

2. Write the minimal amount of code to make that test pass

3. Repeat

By following this process, you are guaranteed to have tests for your code because you are writing them first. It is not always possible, or it is sometimes very difficult, to write unit tests after the fact. Anyways, enough about TDD, let's see some code!

// tests/part1/cart-summary-test.js var chai = require('chai'); var expect = chai.expect; // we are using the "expect" style of Chai var CartSummary = require('./../../src/part1/cart-summary'); describe('CartSummary', function() { it('getSubtotal() should return 0 if no items are passed in', function() { var cartSummary = new CartSummary([]); expect(cartSummary.getSubtotal()).to.equal(0); }); });

The describe function is used to set up a group of tests with a name. I tend to put the module under test as the name, in this case CartSummary. A test is written using the it function. The it function is given a description as the first argument of what the module under test should do. The second argument of the it function is a function that will contain one or more assertions (also called expectations) using Chai in this example. Our first test simply verifies that the subtotal is 0 if the cart has no items.

To run this test, run mocha tests --recursive --watch from the root of the project. The recursive flag will find all files in subdirectories, and the watch flag will watch all your source and test files and rerun the tests when they change. You should see something like this:

Our test is failing because we have not yet implemented CartSummary. Let's do that.

// src/part1/cart-summary.js function CartSummary() {} CartSummary.prototype.getSubtotal = function() { return 0; }; module.exports = CartSummary;

Here we've written the minimal amount of code to make our test pass.

Let's move on to our next test.

it('getSubtotal() should return the sum of the price * quantity for all items', function() { var cartSummary = new CartSummary([{ id: 1, quantity: 4, price: 50 }, { id: 2, quantity: 2, price: 30 }, { id: 3, quantity: 1, price: 40 }]); expect(cartSummary.getSubtotal()).to.equal(300); });

The failing output shows what value getSubtotal returned in red and what value we expected in green. Let's revise getSubtotal so our test passes.

// src/part1/cart-summary.js function CartSummary(items) { this._items = items; } CartSummary.prototype.getSubtotal = function() { if (this._items.length) { return this._items.reduce(function(subtotal, item) { return subtotal += (item.quantity * item.price); }, 0); } return 0; };

Our test passes! We have successfully used TDD to implement the getSubtotal method.

Stubs with Sinon

Let's say we now want to add tax calculation to CartSummary in a getTax() method. The end usage will look like this:

var cartSummary = new CartSummary([ /* ... */ ]); cartSummary.getTax('NY', function() { // executed when the tax API request has finished });

The getTax method will use another module we will create called tax with a calculate method that will deal with the intricacies of calculating tax by state. Even though we have not implemented tax, we can still finish our getTax method as long as we identify a contract for the tax module. This contact will state that there should be a module called tax with a calculate method that takes three arguments: a subtotal, a state, and a callback function that will execute when the tax API request has completed.

As mentioned before, unit tests test units in isolation. We want to test our getTax method isolated from tax.calculate. As long as tax.calculate abides by its code contract, or interface, getTax should work. What we can do is fake out tax.calculate when testing getTax using a stub, a type of test double that acts as a controllable replacement. Test doubles are often compared to stunt doubles, as they replace one object with another for testing purposes, similar to how actors and actresses are replaced with stunt doubles for dangerous action scenes. We can create this stub using the Sinon library.

To install Sinon, run:

npm install sinon --save-dev

The first thing we have to do before we can stub out the tax.calculate method is define it. We don't have to implement the details of it, but the method calculate must exist on the tax object.

// src/part1/tax.js module.exports = { calculate: function(subtotal, state, done) { // implemented later or in parallel by our coworker } };

Now that tax.calculate has been created, we can stub it out with our pre-programmed replacement using Sinon:

// tests/part1/cart-summary-test.js // ... var sinon = require('sinon'); var tax = require('./../../src/part1/tax'); describe('getTax()', function() { beforeEach(function() { sinon.stub(tax, 'calculate', function(subtotal, state, done) { setTimeout(function() { done({ amount: 30 }); }, 0); }); }); afterEach(function() { tax.calculate.restore(); }); it('get Tax() should execute the callback function with the tax amount', function(done) { var cartSummary = new CartSummary([{ id: 1, quantity: 4, price: 50 }, { id: 2, quantity: 2, price: 30 }, { id: 3, quantity: 1, price: 40 }]); cartSummary.getTax('NY', function(taxAmount) { expect(taxAmount).to.equal(30); done(); }); }); });

We start by requiring Sinon and our tax module into the test. To stub out a method in Sinon, we call the sinon.stub function and pass it the object with the method being stubbed, the name of the method to be stubbed, and a function that will replace the original during our test.

var stub = sinon.stub(object, 'method', func);

In this example, I have simply stubbed out tax.calculate with the following:

function(subtotal, state, done) { setTimeout(function() { done({ amount: 30 }); }, 0); }

This is just a function that calls done with a static tax details object containing a tax amount of 30. setTimeout is used to mimic the asynchronous behavior of this method since in reality it will be making an asynchronous API call to some tax service. This happens in a beforeEach block which executes before every test. After each test, the afterEach block is executed which restores the original tax.calculate.

This test verifies that the callback function passed to getTax is executed with the tax amount, not the entire tax details object that gets passed to the callback function for tax.calculate. As you can see, our test for getTax is passing even though we haven't implemented tax.calculate yet. We've merely defined the interface of it. As long as tax.calculate upholds to this interface, both modules should work correctly together.

This example also exhibits asynchronous testing. Specifying a parameter in the it function (called done in this example), Mocha will pass in a function and wait for it to execute before ending the test. The test will timeout and error if done is not invoked within 2000 milliseconds. If we had not made this an asynchronous test, the test would have finished before our expectation has run, leading us to think all of our tests are passing when in reality they are not.

Now let's write the implementation for getTax to make our test pass:

CartSummary.prototype.getTax = function(state, done) { tax.calculate(this.getSubtotal(), state, function(taxInfo) { done(taxInfo.amount); }); };

Spies with Sinon

One issue that our getTax method has is that our test does not verify that tax.calculate is called with the correct subtotal and state. Our test would still pass if we hardcoded subtotal and state values in the getTax implementation. Go ahead and give it a try in the sample code. That's no good! To verify tax.calculate is called with the correct arguments, we can leverage Sinon spies.

A spy is another type of test double that records how a function is used. This includes information such as what arguments a spy is called with, how many times a spy is called, and if the spy throws an error. The great thing about Sinon stubs is that they are built on top of spies! Here is our updated test:

it('getTax() should execute the callback function with the tax amount', function(done) { var cartSummary = new CartSummary([ { id: 1, quantity: 4, price: 50 }, { id: 2, quantity: 2, price: 30 }, { id: 3, quantity: 1, price: 40 } ]); cartSummary.getTax('NY', function(taxAmount) { expect(taxAmount).to.equal(30); expect(tax.calculate.getCall(0).args[0]).to.equal(300); expect(tax.calculate.getCall(0).args[1]).to.equal('NY'); done(); }); });

Two more expectations were added to this test. getCall is used to get the first call to the stub for tax.calculate. args contains the arguments for that call. We are simply verifying that tax.calculate was called with the correct subtotal and state as opposed to hardcoded values.

Sinon is a very powerful library and offers a lot of test double functionality for both Node and browser JavaScript testing that you will find useful so definitely check out the documentation.

Conclusion

In this post, we looked at a few practical examples of unit testing in Node using the Mocha testing framework, the Chai assertion library, and Sinon for test doubles in the form of stubbing and spying. I hope you enjoyed this post. If you have any questions, ask them below or reach me on Twitter @skaterdav85.
Part 2 will be about Testing HTTP Requests with Nock. Source code

# data[].attributes.attachment_link.title
Unit Testing and TDD in Node.js - Part 1 | Codementor

# data[].attributes.attachment_link.description
Testing is an important practice in software development to improve software quality. There are many forms of testing; manual testing, acceptance testing, unit testing, and a few others. In this post we are going to look at unit testing in Node using the Mocha test framework.

# data[].attributes.attachment_link.keywords[]
runkit repl tonic endpoint playground javascript node npm module prototype prototyping api server

# data[].attributes.attachment_link.description
RunKit notebooks are interactive javascript playgrounds connected to a complete node environment right in your browser. Every npm module pre-installed.