Node server with ES6

Today I was wondering how could I write ES6 code and run it on node so I could write my applications using always the same pattern, no matter if I’m writing Node backend code of React Front-end code.

As a matter of fact, it’s quite simple to convert your node applications to full ES6 using Babel. You just have to add some modules and change some configurations.

First of all, you need to install Babel. We’ll install Babel in the development dependencies since we won’t use it in production. You can do that using the command below:

npm i -D @babel/cli @babel/core @babel/node @babel/preset-env @babel/register

I also needed to install another babel related package in the dependencies, this time in the main dependencies:

npm i @babel/polyfill

You also have to create the Babel configuration file:

$ touch .babelrc

And add this configuration to it:

{
"presets": ["@babel/preset-env"]
}

To keep everything organized, I moved my app into a folder called src. That way we can have all the source code and final compiled code into separated folders. I also added some scripts to my package.json to run the build and run the server in development mode using nodemon.

There’s one more thing to change. I just could not use the bin/www script to run the server, so I just copied the file to the src folder and renamed it to server.js.

"scripts": {
"build": "babel src -d dist",
"start": "nodemon src/server.js --exec babel-node",
"test": "echo \"Error: no test specified\" && exit 1"
}

The build script runs babel and compiles all the files inside of src folder and saves them to dist folder.

The start script runs the server.js file inside src folder passing code thru babel-node to transpile it. This way you can test the code on src folder in real time. Every time you save a file it will recompile and restart the server.

One more thing, if you are using sequelize, it’s best to add another file to the root folder of your application with some sequelize configuration. That’s important because we have moved the source code of the application to the src folder.

Just create a file called .sequelizerc and add the following code to it:

require("@babel/register");
const path = require('path');

module.exports = {
'config': path.resolve('config', 'config.json'),
'models-path': path.resolve('src/models'),
'seeders-path': path.resolve('src/seeders'),
'migrations-path': path.resolve('src/migrations')
}

Now you just have to convert all of your code to ES6. The conversion is the easy part, you can start by changing all the require calls to import and all the module.exports do export.

If you want to take a look at the boilerplate, check out at github:

https://github.com/rcabarreto/nodeServerES6

What is “use strict” and what does it do?

It’s a common place, when you get into a Js interview, one of the first questions they usually ask is: What is ‘use strict’ and what it does to the application?

I know this is kind of old now, but it still comes up in almost every interview, so let’s talk a little bit about it and really see what it does to the application.

First, let’s take a look at the definition.

JavaScript’s strict mode, introduced in ECMAScript 5, is a way to opt in to a restricted variant of JavaScript, thereby implicitly opting-out of “sloppy mode“. Strict mode isn’t just a subset: it intentionally has different semantics from normal code. Browsers not supporting strict mode will run strict mode code with different behavior from browsers that do, so don’t rely on strict mode without feature-testing for support for the relevant aspects of strict mode. Strict mode code and non-strict mode code can coexist, so scripts can opt into strict mode incrementally.

Strict mode makes several changes to normal JavaScript semantics:

  1. Eliminates some JavaScript silent errors by changing them to throw errors.
  2. Fixes mistakes that make it difficult for JavaScript engines to perform optimizations: strict mode code can sometimes be made to run faster than identical code that’s not strict mode.
  3. Prohibits some syntax likely to be defined in future versions of ECMAScript.

Now let’s talk about what happens to your code when you enable strict mode.

First, strict mode makes it impossible to accidentally create global variables. In normal JavaScript mistyping a variable in an assignment creates a new property on the global object and continues to “work”. Assignments, which would accidentally create global variables, instead throw an error in strict mode:

test = 'some string'; // create a global variable
console.log(test); // prints 'some string'

Now in Strict Mode

'use strict'
test = 'some string'; // throw an error
console.log(test);

As you can see, Strict Mode prevents the application from creating global variables and also prevents you from declaring variables without the keywords let and const.

Strict mode will also prevent global fallback when assigning this to functions. When you call a function without a context, the this of the function will be the global object in normal mode. In Strict mode, this will be undefined. Check out the cobe below:

let test = {
checkThis() {
console.log(this)
},
}

// calling checkThis with context
test.checkThis(); // prints out { checkThis: [Function: checkThis] }

// calling checkThis without context
let foo = test.checkThis;

foo() // prints out the Global object

Now the same code in Strict Mode:

'use strict';

let test = {
checkThis() {
console.log(this)
},
}

// calling checkThis with context
test.checkThis(); // prints out { checkThis: [Function: checkThis] }

// calling checkThis without context
let foo = test.checkThis;

foo() // prints out undefined

Another interesting use case showing the behavior above is the following:

(function () {
var a = b = 2
}())

console.log(a); // throws an error saying a in not defined.
console.log(b); // Prints out 2

What happens above is a classic case of a variable been defined in the global scope because it misses the keyword var, let or const. When you write:

(function () {
var a = b = 2
}())

Javascript is actually doing this:

(function () {
var a;
b = 2;
a = b;
}())

If you’re in a clojure like above, the a var will be local and not accessible outside of it, but when you declare b without the keyword var, even inside a clojure, the variable is created as a property of the global object and it is available globally.

Using ‘use strict’ at the top of that code would generate an error saying that you cannot declare a variable without a keyword.


Second, strict mode prohibits with. The code below will throw an error when you run with use strict:

'use strict';
let x = 10;
with (obj) { // error
console.log(x);
}

It also prevent eval from creating variables into the surrounding function or the global scope. In normal mode, variables created inside a eval call leak to the surrounding scope. Check the code below:

eval('var a = 10;');
console.log(a); // prints out 10

Adding ‘use strict’ solves this problem:

'use strict';
eval('var a = 10;');
console.log(a); // variable is undefined

Third, strict mode makes attempts to delete functions, variables or function arguments throw errors where before the attempt would simply have no effect:

var test = '';
delete test;
'use strict';
function foo() {};
delete foo;

Fourth, strict mode prior to Gecko 34 requires that all properties named in an object literal be unique. The normal code may duplicate property names, with the last one determining the property’s value. But since only the last one does anything, the duplication is simply a vector for bugs, if the code is modified to change the property value other than by changing the last instance. Duplicate property names are a syntax error in strict mode:

Fifth, strict mode requires that function parameter names be unique. In normal code the last duplicated argument hides previous identically-named arguments. Those previous arguments remain available through arguments[i], so they’re not completely inaccessible. Still, this hiding makes little sense and is probably undesirable (it might hide a typo, for example), so in strict mode duplicate argument names are a syntax error:

Sixth, a strict mode in ECMAScript 5 forbids octal syntax. The octal syntax isn’t part of ECMAScript 5, but it’s supported in all browsers by prefixing the octal number with a zero: 0644 === 420 and "\045" === "%". In ECMAScript 2015 Octal number is supported by prefixing a number with “0o“. i.e. 

Seventh, strict mode in ECMAScript 2015 forbids setting properties on primitive values. Without strict mode, setting properties is simply ignored (no-op), with strict mode, however, a TypeError is thrown.

Algorithms: Merge Sort

Merge sort is one of the commonly used sorting algorithms in computer science. It’s based on the idea that it’s easier to sort two sorted arrays rather than one unsorted array. Once you have two sorted arrays you can merge them into a single array, comparing their items one by one and adding the smaller item first.

At the end of the sorting any left variables are concatenated at the end of our results list — since the A and B arrays are already sorted this will not cause reordering.

The concept is fairly easy to understand but how do we reach a state in which we have two sorted arrays? Arrays of multiple items can’t be compared until they are sorted! We can achieve this by splitting the array into halves recursively until we reach a point in which we compare multiple pairs of single-item arrays.

             [1,9,3,8,6,5,7,4,2]

[1,9,3,8] [6,5,7,4,2]

[1,9] [3,8] [6,5] [7,4,2]

[1] [9] [3] [8] [6] [5] [7] [4,2]

[1] [9] [3] [8] [6] [5] [7] [4] [2]

This is not the most comprehensive schema ever but you can see how the array is recursively split into smaller and smaller arrays until we reach the state in which we have only arrays containing a single item. At that point we start comparing them one by one and using the above mentioned concatenating method — sort our array.

[1]   [9]   [3]   [8]   [6]   [5]   [7]   [4]   [2]

[1] [9] [3] [8] [6] [5] [7] [2,4]

[1,9] [3,8] [5,6] [2,4,7]

[1,3,8,9] [2,4,5,7,6]

[1,2,3,4,5,6,7,8,9]

In other words, we split our array to it’s smallest pieces and then assemble them again but in the correct order. Here’s an implementation in JavaScript which utilizes the built-in slice function in order to get the parts of the array that we need.

const mergeSort = (arr) => {
if (arr.length <= 1) {
return arr
}
const middle = Math.floor(arr.length / 2)
return mergeArray(
mergeSort(arr.slice(0, middle)),
mergeSort(arr.slice(middle))
)
}


const mergeArray = (left, right) => {
let result = []

while (left.length && right.length) {
if (left[0] < right[0]) {
result.push(left.shift())
} else {
result.push(right.shift())
}
}

return [...results, ...left, ...right]
}

console.log(mergeSort([1,9,3,8,6,5,7,4,2]))

Understanding JavaScript Memoization

I’ll go straight to the point here. Memoization is the programmatic practice of making long recursive/iterative functions run much faster.

But how? Well, the speed is achieved by caching function results after its execution so they can be immediately returned the next time the function is called with the same arguments.

Here’s a basic example.

const add = (a, b) => a + b
console.log(add(2,3)) // => returns 5

Every time we call this function, a calculation is going to be performed and a value returned.

Now lets create a simple memoize function that takes another function and modifies it to memoize calls.

const memoize = (fn) => {
let cache = {}
return (...args) => {
let n = JSON.stringify(args);
if (n in cache) {
console.log('Fetching from cache', n);
return cache[n];
}
else {
console.log('Calculating result', n);
let result = fn(...args);
cache[n] = result;
return result;
}
}
}

Now we can easily memoize any pure function, like our add function. Since memoize is a high order function, we have two ways of doing this. One is creating a new memoized function, like below.

const add = (a, b) => a + b
const memoAdd = memoize(add)
console.log(memoAdd(2,3)) // => Calculating result 5
console.log(memoAdd(2,3)) // => Fetching from cache 5

Or we can change add the function:

const add = memoize((a, b) => a + b)
console.log(add(2,3)) // => Calculating result 5
console.log(add(2,3)) // => Fetching from cache 5

You want to see the performance boost in action? Take a look at this example below.

// recursive fibonacci function
const fibonacci = (n) => {
if (n === 0 || n === 1) {
return n;
}
return fibonacci(n - 1) + fibonacci(n - 2);
}

This fibonacci function takes a number, the position number of the Fibonacci sequence, and calculates the corresponding value. Since it’s recursive, it tends to get slower if the position you set gets higher. Lets go nuts here and test it with the 50th element on the sequence, shall we?

console.log(fibonacci(50)) // Call the function and go for a walk!

It took nearly 4 minutes to run the code. The recursive function must be called over 40 billion times (40,730,022,147 times to be specific)! It’s pretty insane.

Now lets memoize it. Since the fibonacci is a recursive function, we can not achieve this by creating a new memoized function, like the code below.

const memoFibonacci = memoize(fibonacci)
console.log(memoFibonacci(50)) // insane amount of time

This happens because we are only memoizing the first call. All subsequent recursive calls to fibonacci are not memoized. The only way to memoize recursive functions is by wrapping the main function with the memoize.

// recursive and memoized fibonacci function
const fibonacci = memoize((n) => {
if (n === 0 || n === 1) {
return n;
}
return fibonacci(n - 1) + fibonacci(n - 2);
})

console.log(fibonacci(50)) // runs fast!

Now it runs in less than one second and the results are exactly the same. Amazing! As you can see in the console, a lot os the calls are cached, preventing billions of recursive calls.

Is memoization same as caching?

Yes, kind of. Memoization is actually a specific type of caching. While caching can refer in general to any storing technique for future use, memoizing specifically involves caching the return values of a function.

Careful

Keep in mind that memoization does not make sense for all function calls. It does not work well for functions that are not pure, that is functions that have side effects. Memoizing only allows us to cache a result, so any other side effects get lost on successive calls. That said, you can get around this constraint, by returning a function that includes your side effects that you will need to execute after getting the result.

Also, there is a higher memory overhead since we must store our cached results so that we can later recall them as well as an added complexity of using memoization, so it really only makes sense for functions that are computationally expensive.

Immutability in JavaScript

Immutability is a super hot subject in modern JavaScript and the reason for that is, of course, because of the functional programming paradigm.

Immutable data is tightly connected with a functional approach where any mutation is considered as an unwanted side effect. But first, let’s dive into details of mutability and immutability.

Continue reading “Immutability in JavaScript”

What the hell is Serverless architecture?

The Information Technology (IT) market constantly presents new trends, some of them pick up and others do not even go beyond the concept phase. The latest trend is the Wave of Serverless, a cloud computing solution that has caught the eye of developers and industry professionals since last year.

Also presented to the market as FaaS (Function as a Service) or Serving Platform as a Service, Serverless is already being disseminated by a group of Cloud Computing providers.

Continue reading “What the hell is Serverless architecture?”

Creating your own Node module

In this article we are going to talk a little bit about creating NPM modules and sharing them on NPM registry, but first let’s define what’s NPM.

NPM is a package manager for Node.js packages, or modules and the npm website hosts thousands of free packages to download and use freely. NPM program is installed on your computer when you install Node.js.

Continue reading “Creating your own Node module”

What is Node.js?

Node.js (or just Node) is a lean, fast, cross-platform JavaScript runtime environment that is useful for both servers and desktop applications. Node is an asynchronous event driven JavaScript runtime built upon Chrome’s V8 JavaScript engine. It’s designed to build scalable network applications.

That being the raw definition, let me clarify. Node.js enables you to write server side JavaScript. You may now be wondering, how? As you know, JavaScript is a language which runs in a browser. The browser’s engine takes JavaScript code and compiles it into commands. The creator of Node.js took Chrome’s engine and built a runtime for it to work on a server. Don’t get confused with the word runtime. It’s an environment where the language can get interpreted. So what do we have now? A way to write JavaScript on the back end.

Continue reading “What is Node.js?”

Reading and Writing files with Node.js

In this post I’m going to show you how we can read and write files on our local filesystem using Node.js.

Being able to read files from you local filesystem can be very useful and there’s a buntch of stuff you can do with it, for example read local Json files and load Spreadsheets to your program.

To start, just create a js file and name it whatever you want. Then open this file in your editor of choice.

Reading from files is done via the core fs module. The fs module provides an API for interacting with the file system in a manner closely modeled around standard POSIX functions.

Continue reading “Reading and Writing files with Node.js”