Forem: Sam

Introducing the Best 10 Node.js Frameworks for 2019 and 2020

Sam — Tue, 30 Jul 2019 13:00:00 +0000

Originally published at softwareontheroad.com

I’m so tired of reading articles claiming what is the best node.js framework based on biased opinions or sponsorships (yes, that’s a thing)

So here are the top node.js frameworks ranked by daily downloads, the data was taken from npmjs.com itself (sorry yarn).

What is a node.js framework?

How to choose a node.js framework for my application?

You have to consider mainly 2 things:

The scalability and robustness of the framework
If the development process is something you feel comfortable working with.

Regardless of scalability and robustness, every node.js web framework is built on top of the http module.

Some of these frameworks add too much … and that makes a huge impact on the server’s throughput.

In my opinion, working with a barebone framework like Express.js or Fastify.js is the best when the service you are developing is small in business logic but need to be highly scalable.

By the other hand, if you are developing a medium size application, it’s better to go with a framework that helps you have a clear structure like next.js or loopback.

There is no simple answer to the question, you better have a peek on how to declare API routes on every framework on this list and decide for yourself.

10. Adonis

Adonis.js is an MVC (Model-View-Controller) node.js framework capable of building an API Rest with JWT authentication and database access.

What’s is this framework about?

The good thing is that Adonis.js framework comes with a CLI to create the bootstrap for applications.

$ npm i -g @adonisjs/cli
$ adonis new adonis-tasks
$ adonis serve --dev

The typical Adonis app has an MVC structure, that way you don’t waste time figuring out how you should structure your web server.

Some apps built with adonis can be found here.

👉 GET MORE ADVANCED NODE.JS DEVELOPMENT ARTICLES

Join the other 2,000+ savvy node.js developers who get article updates.

9. Feathers

Feather.js is a node.js framework promise to be a REST and realtime API layer for modern applications.

See what’s capable of!!

This is all the code you need to set-up your API REST + realtime WebSockets connection thanks to the socket.io plugin

const feathers = require('@feathersjs/feathers');
const express = require('@feathersjs/express');
const socketio = require('@feathersjs/socketio');

const memory = require('feathers-memory');

// Creates an Express compatible Feathers application
const app = express(feathers());

// Parse HTTP JSON bodies
app.use(express.json());
// Parse URL-encoded params
app.use(express.urlencoded({ extended: true }));
// Add REST API support
app.configure(express.rest());
// Configure Socket.io real-time APIs
app.configure(socketio());
// Register a messages service with pagination
app.use('/messages', memory({
  paginate: {
    default: 10,
    max: 25
  }
}));
// Register a nicer error handler than the default Express one
app.use(express.errorHandler());

// Add any new real-time connection to the `everybody` channel
app.on('connection', connection => app.channel('everybody').join(connection));
// Publish all events to the `everybody` channel
app.publish(data => app.channel('everybody'));

// Start the server
app.listen(3030).on('listening', () =>
  console.log('Feathers server listening on localhost:3030')
);

Pretty sweet right?

Here are some apps built with feathers.js.

8. Sails

Sails.js Ye’ olde node.js framework

With 7 years of maturity, this is a battle-tested node.js web framework that you should definitively check out!

See it in action

Sails.js comes with a CLI tool to help you get started in just 4 steps

$ npm install sails -g
$ sails new test-project
$ cd test-project
$ sails lift

7. Loopback

Backed by IBM, Loopback.io is an enterprise-grade node.js framework, used by companies such as GoDaddy, Symantec, IBM itself.

They even offer Long-Term Support (LTS) for 18 months!

This framework comes with a CLI tool to scaffold your node.js server

$ npm i -g @loopback/cli

Then to create a project

$ lb4 app

Here is what an API route and controller looks like:

import {get} from '@loopback/rest';

export class HelloController {
  @get('/hello')
  hello(): string {
    return 'Hello world!';
  }
}

6. Fastify

Fastify.io is a node.js framework that is designed to be the replacement of express.js with a 65% better performance.

Show me the code

// Require the framework and instantiate it
const fastify = require('fastify')({
  logger: true
})

// Declare a route
fastify.get('/', (request, reply) => {
  reply.send({ hello: 'world' })
})

// Run the server!
fastify.listen(3000, (err, address) => {
  if (err) throw err
  fastify.log.info(`server listening on ${address}`)
})

And that’s it!

I love the simplicity and reminiscence to Express.js of Fastify.js, definitively is the framework to go if performance is an issue in your server.

5. Restify

Restify claims to be the future of Node.js Web Frameworks.

This framework is used in production by NPM, Netflix, Pinterest and Napster.

Code example

Setting up a Restify.js server is just as simple as this

const restify = require('restify');

function respond(req, res, next) {
  res.send('hello ' + req.params.name);
  next();
}

const server = restify.createServer();
server.get('/hello/:name', respond);
server.head('/hello/:name', respond);

server.listen(8080, function() {
  console.log('%s listening at %s', server.name, server.url);
});

👉 GET MORE ADVANCED NODE.JS DEVELOPMENT ARTICLES

Join the other 2,000+ savvy node.js developers who get article updates.

4. Nest.js

A relatively new node.js framework, Nest.js has a similar architecture to Angular.io, so if you are familiar with that frontend framework, you'll find this one pretty easy to develop as well.

Example

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.setViewEngine('hbs');
  await app.listen(3000);
}
bootstrap();

3. Hapi

One of the big 3 node.js frameworks, hapi.js has an ecosystem of libraries and plugins that makes the framework highly customizable.

Although I never used hapi.js on production, I’ve been using its validation library Joi.js for years.

Creating a server

A hapi.js webserver looks like this

const Hapi = require('@hapi/hapi');

const init = async () => {

  const server = Hapi.server({
      port: 3000,
      host: 'localhost'
  });

  await server.start();
  console.log('Server running on %s', server.info.uri);
};

init();

2. Koa

Koa is a web framework designed by the team behind Express.js the most famous and used node.js framework.

Koa aims to be a smaller, more expressive, and more robust foundation for web applications and APIs than express.js.

Through leveraging generators Koa allows you to ditch callbacks and greatly increase error-handling.

Koa does not bundle any middleware within the core and provides an elegant suite of methods that make writing servers fast and enjoyable.

Example

const Koa = require('koa'); 
const app = new Koa(); 
app.use(async ctx => { 
  ctx.body = 'Hello World'; 
}); 
app.listen(3000);

1. Express

Express.js is definitively the king of node.js frameworks, will reach the incredible mark of 2 million daily downloads by the end of 2019.

Despite being such an old framework, Express.js is actively maintained by the community and is used by big companies such as User, Mulesoft, IBM, and so on.

Example

Just add it to your node.js project

$ npm install express

Then declare some API routes

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => res.send('Hello World!'))

app.listen(port, () => console.log(`Example app listening on port ${port}!`))

And that’s all you need to start using it!

Conclusion

There are tons of node.js frameworks out there, the best you can do is go and try them all ‘til you find the ones that suit your needs.

Personally, I prefer Express.js because, through these 6 years of node.js development, I build a strong knowledge of good architectural patterns, all based on trial and error.

But that doesn’t mean you have to do the same, here is all the secrets of a good express.js framework project.

Bulletproof node.js project architecture 🛡️

Sam ・ Apr 18 '19

#node #javascript #webdev #tutorial

Now tell me, what is your favorite node.js framework?

Send me a tweet to @santypk4, come on! I want to know what the people are using, I don’t want to fall behind!

👉 GET MORE ADVANCED NODE.JS DEVELOPMENT ARTICLES

Join the other 2,000+ savvy node.js developers who get article updates.

Top 10 Front-End Frameworks by Downloads [2015-2019]

Sam — Tue, 23 Jul 2019 08:45:00 +0000

Originally posted on softwareontheroad.com

I was so tired of reading biased articles claiming what framework is best based on wrong assumptions or money from sponsorships (Yes, that’s a thing).

So here is my research on the most daily downloads frameworks from March 2015 to July 2019.

TL;DR: React.js is the most daily-downloaded frontend framework of 2019.

And here are my opinions on each framework

jQuery
React
Preact
Angular.js
Angular.io
Vue
Ember
Polymer
Backbone
Svelte
Conclusion

jQuery

Yes, I hear you screaming, jQuery is not a framework but a library.

I decided to include it because it’s one of the most known javascript tools out there. People who develop PHP (and WordPress) know about jQuery. Even my father (long story) knows about its existence.

And I’ve seen so many vanilla implementations of ‘frameworks’ or ways to develop pages with jQuery that I had to consider it.

React.js

When I tried to React.js for the first time back in December 2015, I hated it.

How do you dare to mix CSS and javascript?

Those days are gone, now I love declaring CSS inside my react components, you should try Emotion by the way.

Preact

There was a time two years ago, when people read the source code of React.js and discovered how they can improve it by striping out a lot of code.

That was the born of Preact and similar frameworks that I don’t recall the name at the moment.

They even made the APIs compatible, so you can just replace all the calls to React in your app and use Preact.

I can’t say anything about it, I never had the chance to try it out.

Angular.js (The classic)

Oh my first love, Angular.js, I started using it on version 1.3, it was so buggy.

Well, maybe it wasn’t so buggy, we were bad developers.

You could mess up your app by manipulating the $scope by hand, pretty easily because everything was mutable, the concept of immutability per se wasn’t so popular at the time.

And I will not start talking about renders and calling $digest and $apply.

A couple of friends still develops and maintain legacy apps on Angular.js (and they hate it.)

Angular.js was the framework that changes it all, we should be proud of having the chance to work with it.

👉 GET MORE ADVANCED NODE.JS DEVELOPMENT ARTICLES

Join the other 2,000+ savvy node.js developers who get article updates.

Angular.io (2/4/6/8/etc)

I was an angular fanboy back then (who wasn’t?) but I knew and I acknowledged that angular.js has its flaws.

And oh god they made the waiting for version 2 so longer!!

Luckily when it came out I had the chance to implement a brand new app for the company, and angular2 was the choice.

I love its organized code, the stability of the apps and the SOLID principles that it forces you to follow.

Definitively my second favorite framework.

Vue

I had two encounters with vue.js

One afternoon I decided to open the source code just to peek, and found Chinese (don’t quite sure) characters as comments and drop out scared.
Have to write 3 components because the frontend developer of a client vanished from the earth.

I can’t say that it’s an awesome I just found it regular. Nothing that you can’t do with react or angular.

Ember

I never meet any developer who has been deployed a production Ember application, just my friend Fernando who is a polyglot developer and likes to try every language and framework he can.

So that makes me think this is one of those frameworks that you see in all of these kinds of posts, that it’s mentioned only to fill up the list, which is sad.

Do you use Ember? Let me know in twitter

Polymer

The one ‘backed’ by google, I only try polymer once in 2016 to make a ‘web component’, show it to my coworkers, and never touch it back.

Maybe I’ve been using an app from Google written in Polymer and never notice it.

Backbone

The good old Backbone.

I’m too young to say anything bad about it because when I was introduced to web development in early 2014, I skipped jQuery and PHP and went straight to learn Angular.js.

But my fellow old-time developer friend Gonzalo says it was stable and fun.

I believe a version of openenglish.com was developed with it…

Svelte

Last year, at my former job we were doing a late-night deploy (yeah, I don’t want to talk about it) and the hyper frontend, that always show me new frontend stuff, was developing a new alternative version of our main product (he is very passionate about his work, it was so lovely to work with him).

I think the product manager didn’t like the idea of rewriting the application for the sake of changing the framework, but it was a fast & stable build, I liked it.

Conclusion

There are tons of frontend frameworks out there, but just a few are worth trying, and just a couple worth using.

Try to stick with the one you like better and feel comfortable working with, chances are you are gonna need to become an expert on it, so better choose wisely.

👉 GET MORE ADVANCED NODE.JS DEVELOPMENT ARTICLES

Join the other 2,000+ savvy node.js developers who get article updates.

And don't miss this masterpiece, I believe you will love it :)

Bulletproof node.js project architecture 🛡️

Sam ・ Apr 18 '19 ・ 11 min read

#node #javascript #webdev #tutorial

🛑 You don't need passport.js - Guide to node.js authentication ✌️

Sam — Fri, 31 May 2019 12:24:44 +0000

Originally posted on softwareontheroad.com

Introduction

While third-party authentication services like Google Firebase, AWS Cognito, and Auth0 are gaining popularity, and all-in-one library solutions like passport.js are the industry standard, is common to see that developers never really understand all the parts involved in the authentication flow.

This series of articles about node.js authentication, are aimed to demystify concepts such as JSON Web Token (JWT), social login (OAuth2), user impersonation (an admin can log in as a specific user without password), common security pitfalls and attack vectors.

Also, there is a GitHub repository with a complete node.js authentication flow that you can use as a base for your projects.

Requirements ✍️
How to make the Sign-Up 🥇
How to make the Sign-In 🥈
JWT explained 👩‍🏫
Generating JWTs 🏭
Secured endpoints ⚔️
User impersonation 🕵️
Conclusion 🏗️
Example repository 🔬

Project requirements ✍️

The requirements for this project are:

A database to store the user's email and password, or clientId and clientSecret, or any pair of public and private keys.
A strong and efficient cryptographic algorithm to encrypt the passwords.

At the time of writing, I consider that Argon2 is the best cryptographic algorithm out there, please don't use a simple cryptographic algorithm like SHA256, SHA512 or MD5.

Please refer to this awesome post for more details about choosing a password hashing algorithm

How to create a Sign-Up 🥇

When a user is created, the password has to be hashed and stored in the database alongside the email and other custom details (user profile, timestamp, etc)

Note: Read about the node.js project structure in the previous article Bulletproof node.js project architecture 🛡️

import * as argon2 from 'argon2';

class AuthService {
  public async SignUp(email, password, name): Promise<any> {
    const salt = randomBytes(32);
    const passwordHashed = await argon2.hash(password, { salt });

    const userRecord = await UserModel.create({
      password: passwordHashed,
      email,
      salt: salt.toString('hex'), // notice the .toString('hex')
      name,
    });
    return {
      // MAKE SURE TO NEVER SEND BACK THE PASSWORD OR SALT!!!!
      user: {
        email: userRecord.email,
        name: userRecord.name,
      },
    }
  }
}

Notice that we also create a salt for the password. A salt is random data that is used as an additional input to the hashing function, also the salt is randomly generated for every new user record.

The user record looks like this:

Robo3T for MongoDB

How to create a Sign-In 🥈

When the user performs a sign in, this is what happens:

The client sends a pair of Public Identification and a Private key, usually an email and a password
The server looks for the user in the database using the email.
If the user exists in the database, the server hashes the sent password and compares it to the stored hashed password
If the password is valid, it emits a JSON Web Token (or JWT)

This is the temporary key that the client has to send in every request to an authenticated endpoint

import * as argon2 from 'argon2';

class AuthService {
  public async Login(email, password): Promise<any> {
    const userRecord = await UserModel.findOne({ email });
    if (!userRecord) {
      throw new Error('User not found')
    } else {
      const correctPassword = await argon2.verify(userRecord.password, password);
      if (!correctPassword) {
        throw new Error('Incorrect password')
      }
    }

    return {
      user: {
        email: userRecord.email,
        name: userRecord.name,
      },
      token: this.generateJWT(userRecord),
    }
  }
}

The password verification is performed using the argon2 library to prevent 'timing-based attacks',
which means, when an attacker tries to brute-force a password based in the solid principle of how much time takes the server to respond.

In the next section, we will discuss how to generate a JWT

But, what is a JWT anyway? 👩‍🏫

A JSON Web Token or JWT is an encoded JSON object, in a string or Token.

You can think it as a replacement of a cookie, with several advantages.

The token has 3 parts and looks like this:

The data of the JWT can be decoded in the client side without the Secret or Signature.

This can be useful to transport information or metadata, encoded inside the token, to be used in the frontend application, such as things like the user role, profile, token expiration, and so on.

How to generate JWT in node.js 🏭

Let's implement the generateToken function needed to complete our authentication service

By using the library jsonwebtoken, that you can find in npmjs.com, we are able to generate a JWT.

import * as jwt from 'jsonwebtoken'
class AuthService {
  private generateToken(user) {

    const data =  {
      _id: user._id,
      name: user.name,
      email: user.email
    };
    const signature = 'MySuP3R_z3kr3t';
    const expiration = '6h';

    return jwt.sign({ data, }, signature, { expiresIn: expiration });
  }
}

The important here is the encoded data, you should never send sensitive information about the user.

The signature is the 'secret' that is used to generate the JWT, and is very important to keep this signature safe.

If it gets compromised, an attacker could generate tokens on behalf the users and steal their sessions and.

Securing endpoints and verifying the JWT ⚔️

The frontend code is now required to send the JWT in every request to a secure endpoint.

A good practice is to include the JWT in a header, commonly the Authorization header.

Now in the backend, a middleware for the express routes has to be created.

Middleware "isAuth"

import * as jwt from 'express-jwt';

// We are assuming that the JWT will come in the header Authorization but it could come in the req.body or in a query param, you have to decide what works best for you.
const getTokenFromHeader = (req) => {
  if (req.headers.authorization && req.headers.authorization.split(' ')[0] === 'Bearer') {
    return req.headers.authorization.split(' ')[1];
  }
}

export default jwt({
  secret: 'MySuP3R_z3kr3t', // Has to be the same that we used to sign the JWT

  userProperty: 'token', // this is where the next middleware can find the encoded data generated in services/auth:generateToken -> 'req.token'

  getToken: getTokenFromHeader, // A function to get the auth token from the request
})

Is very useful to have a middleware to get the complete current user record, from the database, and attach it to the request.

export default (req, res, next) => {
 const decodedTokenData = req.tokenData;
 const userRecord = await UserModel.findOne({ _id: decodedTokenData._id })

  req.currentUser = userRecord;

 if(!userRecord) {
   return res.status(401).end('User not found')
 } else {
   return next();
 }
}

Now the routes can access the current user that is performing the request.

  import isAuth from '../middlewares/isAuth';
  import attachCurrentUser from '../middlewares/attachCurrentUser';
  import ItemsModel from '../models/items';

  export default (app) => {
    app.get('/inventory/personal-items', isAuth, attachCurrentUser, (req, res) => {
      const user = req.currentUser;

      const userItems = await ItemsModel.find({ owner: user._id });

      return res.json(userItems).status(200);
    })
  }

The route 'inventory/personal-items' is now secured, you need to have a valid JWT to access it, but also it will use the current user from that JWT to look up in the database for the corresponding items.

Why a JWT is secured ?

A common question that you may have after reading this is:

If the JWT data can be decoded in the client side, can a JWT be manipulated in a way to change the user id or other data ?

While you can decode a JWT easily, you can not encode it with new data without having the 'Secret' that was used when the JWT was signed.

This is the way is so important to never disclose the secret.

Our server is checking the signature on the middleware IsAuth the library express-jwt takes care of that.

Now that we understand how a JWT works, let's move on to a cool advance feature.

How to impersonate a user 🕵️

User impersonation is a technique used to sign in as a specific user, without knowing the user's password.

This a very useful feature for the super admins, developers or support, to be able to solve or debug a user problem that is only visible with his session.

There is no need in having the user password to use the application on his behalf, just generate a JWT with the correct signature and the required user metadata.

Let's create an endpoint that can generate a JWT to log in as a specific user, this endpoint will only be able to be used by a super-admin user

First, we need to establish a higher role for the super admin user, there are many ways to do it, a simple one is just to add a 'role' property on the user record in the database.

Second, let's create a new middleware that checks the user role.

export default (requiredRole) => {
  return (req, res, next) => {
    if(req.currentUser.role === requiredRole) {
      return next();
    } else {
      return res.status(401).send('Action not allowed');
    }
  }
}

That middleware needs to be placed after the isAuth and attachCurrentUser middlewares.

Third, the endpoint that generates a JWT for the user to impersonate.

  import isAuth from '../middlewares/isAuth';
  import attachCurrentUser from '../middlewares/attachCurrentUser';
  import roleRequired from '../middlwares/roleRequired';
  import UserModel from '../models/user';

  export default (app) => {
    app.post('/auth/signin-as-user', isAuth, attachCurrentUser, roleRequired('super-admin'), (req, res) => {
      const userEmail = req.body.email;

      const userRecord = await UserModel.findOne({ email });

      if(!userRecord) {
        return res.status(404).send('User not found');
      }

      return res.json({
        user: {
          email: userRecord.email,
          name: userRecord.name
        },
        jwt: this.generateToken(userRecord)
      })
      .status(200);
    })
  }

So, there is no black magic here, the super-admin knows the email of the user that wants to impersonate, and the logic is pretty similar to the sign-in, but there is no check for correctness of password.

That's because the password is not needed, the security of the endpoint comes from the roleRequired middleware.

Conclusion 🏗️

While is good to rely on third-party authentication services and libraries, to save development time, is also necessary to know the underlayin logic and principles behind authentication.

In this article we explored the JWT capabilities, why is important to choose a good cryptographic algorithm to hash the passwords, and how to impersonate a user, something that is not so simple if you are using a library like passport.js.

In the next part of this series, we are going to explore the different options to provide 'Social Login' authentication for our customers by using the OAuth2 protocal and an easier alternative, a third-party authentication provider like Firebase.

See the example repository here 🔬

Resources

✋ Hey ! Before you go 🏃‍

If you enjoy this article, I recommend you to subscribe to my email list so you never miss another one like this. ⬇️ ⬇️

I will not try to sell you anything, I promise

And don't miss my previous post, I believe you will love it :)

Bulletproof node.js project architecture 🛡️

Sam ・ Apr 18 '19

#node #javascript #webdev #tutorial

Read my research on the most downloaded frontend framework, the result will surprise you!

Top 10 Front-End Frameworks by Downloads [2015-2019]

Sam ・ Jul 28 '19

#javascript #angular #react #vue

Timelapse: Creating a Landing Page

Sam — Mon, 27 May 2019 15:48:14 +0000

This is how you can make a Landing Page with a good placed Call-To-Action.

I didn't have a design in mind, I just start moving things around, and using other websites as inspiration

My blog is open source, you can check it here:

https://github.com/santiq/softwareontheroad

Pull Requests related to the video can be found here:

As always, thanks for passing by.

Bulletproof node.js project architecture 🛡️

Sam — Thu, 18 Apr 2019 21:54:40 +0000

Originally posted on softwareontheroad.com

Update 04/21/2019: Implementation example in a GitHub repository

Introduction

Express.js is great frameworks for making a node.js REST APIs however it doesn't give you any clue on how to organizing your node.js project.

While it may sound silly, this is a real problem.

The correct organization of your node.js project structure will avoid duplication of code, will improve stability, and potentially, will help you scale your services if is done correctly.

This post is extense research, from my years of experience dealing with a poor structured node.js project, bad patterns, and countless hours of refactoring code and moving things around.

If you need help to align your node.js project architecture, just drop me a letter at santiago@softwareontheroad.com

The folder structure 🏢
3 Layer architecture 🥪
Service Layer 💼
Pub/Sub Layer ️️️️🎙️️
Dependency Injection 💉
Unit Testing 🕵🏻
Cron Jobs and recurring task ⚡
Configurations and secrets 🤫
Loaders 🏗️
Example Repository

The folder structure 🏢

Here is the node.js project structure that I'm talking about.

I use this in every node.js REST API service that I build, let's see in details what every component do.



  src
  │   app.js          # App entry point
  └───api             # Express route controllers for all the endpoints of the app
  └───config          # Environment variables and configuration related stuff
  └───jobs            # Jobs definitions for agenda.js
  └───loaders         # Split the startup process into modules
  └───models          # Database models
  └───services        # All the business logic is here
  └───subscribers     # Event handlers for async task
  └───types           # Type declaration files (d.ts) for Typescript

It is more than just a way of ordering javascript files...

3 Layer architecture 🥪

The idea is to use the principle of separation of concerns to move the business logic away from the node.js API Routes.

Because someday, you will want to use your business logic on a CLI tool, or not going far, in a recurring task.

And make an API call from the node.js server to itself it's not a good idea...

☠️ Don't put your business logic inside the controllers!! ☠️

You may be tempted to just use the express.js controllers to store the business logic of your application, but this quickly becomes spaghetti code, as soon as you need to write unit tests, you will end up dealing with complex mocks for req or res express.js objects.

It's complicated to distingue when a response should be sent, and when to continue processing in 'background', let's say after the response is sent to the client.

Here is an example of what not to do.



  route.post('/', async (req, res, next) => {

    // This should be a middleware or should be handled by a library like Joi.
    const userDTO = req.body;
    const isUserValid = validators.user(userDTO)
    if(!isUserValid) {
      return res.status(400).end();
    }

    // Lot of business logic here...
    const userRecord = await UserModel.create(userDTO);
    delete userRecord.password;
    delete userRecord.salt;
    const companyRecord = await CompanyModel.create(userRecord);
    const companyDashboard = await CompanyDashboard.create(userRecord, companyRecord);

    ...whatever...


    // And here is the 'optimization' that mess up everything.
    // The response is sent to client...
    res.json({ user: userRecord, company: companyRecord });

    // But code execution continues :(
    const salaryRecord = await SalaryModel.create(userRecord, companyRecord);
    eventTracker.track('user_signup',userRecord,companyRecord,salaryRecord);
    intercom.createUser(userRecord);
    gaAnalytics.event('user_signup',userRecord);
    await EmailService.startSignupSequence(userRecord)
  });

# Use a service layer for your business logic 💼

This layer is where your business logic should live.

It's just a collection of classes with clear porpuses, following the SOLID principles applied to node.js.

In this layer there should not exists any form of 'SQL query', use the data access layer for that.

Move your code away from the express.js router
Don't pass the req or res object to the service layer
Don't return anything related to the HTTP transport layer like a status code or headers from the service layer.

Example



  route.post('/', 
    validators.userSignup, // this middleware take care of validation
    async (req, res, next) => {
      // The actual responsability of the route layer.
      const userDTO = req.body;

      // Call to service layer.
      // Abstraction on how to access the data layer and the business logic.
      const { user, company } = await UserService.Signup(userDTO);

      // Return a response to client.
      return res.json({ user, company });
    });

Here is how your service will be working behind the scenes.



  import UserModel from '../models/user';
  import CompanyModel from '../models/company';

  export default class UserService {

    async Signup(user) {
      const userRecord = await UserModel.create(user);
      const companyRecord = await CompanyModel.create(userRecord); // needs userRecord to have the database id 
      const salaryRecord = await SalaryModel.create(userRecord, companyRecord); // depends on user and company to be created

      ...whatever

      await EmailService.startSignupSequence(userRecord)

      ...do more stuff

      return { user: userRecord, company: companyRecord };
    }
  }

Visit the example repository

Use a Pub/Sub layer too 🎙️

The pub/sub pattern goes beyond the classic 3 layer architecture proposed here but it's extremely useful.

The simple node.js API endpoint that creates a user right now, may want to call third-party services, maybe to an analytics service, or maybe start an email sequence.

Sooner than later, that simple "create" operation will be doing several things, and you will end up with 1000 lines of code, all in a single function.

That violates the principle of single responsibility.

So, it's better to separate responsibilities from the start, so your code remains maintainable.



  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  import SalaryModel from '../models/salary';

  export default class UserService() {

    async Signup(user) {
      const userRecord = await UserModel.create(user);
      const companyRecord = await CompanyModel.create(user);
      const salaryRecord = await SalaryModel.create(user, salary);

      eventTracker.track(
        'user_signup',
        userRecord,
        companyRecord,
        salaryRecord
      );

      intercom.createUser(
        userRecord
      );

      gaAnalytics.event(
        'user_signup',
        userRecord
      );

      await EmailService.startSignupSequence(userRecord)

      ...more stuff

      return { user: userRecord, company: companyRecord };
    }

  }

An imperative call to a dependent service is not the best way of doing it.

A better approach is by emitting an event i.e. 'a user signed up with this email'.

And you are done, now it's the responsibility of the listeners to do their job.



  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  import SalaryModel from '../models/salary';

  export default class UserService() {

    async Signup(user) {
      const userRecord = await this.userModel.create(user);
      const companyRecord = await this.companyModel.create(user);
      this.eventEmitter.emit('user_signup', { user: userRecord, company: companyRecord })
      return userRecord
    }

  }

Now you can split the event handlers/listeners into multiple files.



  eventEmitter.on('user_signup', ({ user, company }) => {

    eventTracker.track(
      'user_signup',
      user,
      company,
    );

    intercom.createUser(
      user
    );

    gaAnalytics.event(
      'user_signup',
      user
    );
  })



  eventEmitter.on('user_signup', async ({ user, company }) => {
    const salaryRecord = await SalaryModel.create(user, company);
  })



  eventEmitter.on('user_signup', async ({ user, company }) => {
    await EmailService.startSignupSequence(user)
  })

You can wrap the await statements into a try-catch block or you can just let it fail and handle the 'unhandledPromise' process.on('unhandledRejection',cb)

Dependency Injection 💉

D.I. or inversion of control (IoC) is a common pattern that will help the organization of your code, by 'injecting' or passing through the constructor the dependencies of your class or function.

By doing this way you will gain the flexibility to inject a 'compatible dependency' when, for example, you write the unit tests for the service, or when the service is used in another context.

Code with no D.I



  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  import SalaryModel from '../models/salary';  
  class UserService {
    constructor(){}
    Sigup(){
      // Caling UserMode, CompanyModel, etc
      ...
    }
  }

Code with manual dependency injection



  export default class UserService {
    constructor(userModel, companyModel, salaryModel){
      this.userModel = userModel;
      this.companyModel = companyModel;
      this.salaryModel = salaryModel;
    }
    getMyUser(userId){
      // models available throug 'this'
      const user = this.userModel.findById(userId);
      return user;
    }
  }

Now you can inject custom dependencies.



  import UserService from '../services/user';
  import UserModel from '../models/user';
  import CompanyModel from '../models/company';
  const salaryModelMock = {
    calculateNetSalary(){
      return 42;
    }
  }
  const userServiceInstance = new UserService(userModel, companyModel, salaryModelMock);
  const user = await userServiceInstance.getMyUser('12346');

The amount of dependencies a service can have is infinite, and refactor every instantiation of it when you add a new one is a boring and error-prone task.

That's why dependency injection frameworks were created.

The idea is you declare your dependencies in the class, and when you need an instance of that class, you just call the 'Service Locator'.

Let's see an example using typedi an npm library that brings D.I to node.js

WARNING typescript example



  import { Service } from 'typedi';
  @Service()
  export default class UserService {
    constructor(
      private userModel,
      private companyModel, 
      private salaryModel
    ){}

    getMyUser(userId){
      const user = this.userModel.findById(userId);
      return user;
    }
  }

services/user.ts

Now typedi will take care of resolving any dependency the UserService require.



  import { Container } from 'typedi';
  import UserService from '../services/user';
  const userServiceInstance = Container.get(UserService);
  const user = await userServiceInstance.getMyUser('12346');

Abusing service locator calls is an anti-pattern

Using Dependency Injection with Express.js in Node.js

Using D.I. in express.js is the final piece of the puzzle for this node.js project architecture.

Routing layer



  route.post('/', 
    async (req, res, next) => {
      const userDTO = req.body;

      const userServiceInstance = Container.get(UserService) // Service locator

      const { user, company } = userServiceInstance.Signup(userDTO);

      return res.json({ user, company });
    });

Awesome, project is looking great!
It's so organized that makes me want to be coding something right now.

Visit the example repository

An unit test example 🕵🏻

By using dependency injection and these organization patterns, unit testing becomes really simple.

You don't have to mock req/res objects or require(...) calls.

Example: Unit test for signup user method

tests/unit/services/user.js



  import UserService from '../../../src/services/user';

  describe('User service unit tests', () => {
    describe('Signup', () => {
      test('Should create user record and emit user_signup event', async () => {
        const eventEmitterService = {
          emit: jest.fn(),
        };

        const userModel = {
          create: (user) => {
            return {
              ...user,
              _id: 'mock-user-id'
            }
          },
        };

        const companyModel = {
          create: (user) => {
            return {
              owner: user._id,
              companyTaxId: '12345',
            }
          },
        };

        const userInput= {
          fullname: 'User Unit Test',
          email: 'test@example.com',
        };

        const userService = new UserService(userModel, companyModel, eventEmitterService);
        const userRecord = await userService.SignUp(teamId.toHexString(), userInput);

        expect(userRecord).toBeDefined();
        expect(userRecord._id).toBeDefined();
        expect(eventEmitterService.emit).toBeCalled();
      });
    })
  })

Cron Jobs and recurring task ⚡

So, now that the business logic encapsulated into the service layer, it's easier to use it from a Cron job.

You should never rely on node.js setTimeout or another primitive way of delay the execution of code, but on a framework that persist your jobs, and the execution of them, in a database.

This way you will have control over the failed jobs, and feedback of those who succeed.
I already wrote on good practice for this so, check my guide on using agenda.js the best task manager for node.js.

Configurations and secrets 🤫

Following the battle-tested concepts of Twelve-Factor App for node.js the best approach to store API Keys and database string connections, it's by using dotenv.

Put a .env file, that must never be committed (but it has to exist with default values in your repository) then, the npm package dotenv loads the .env file and insert the vars into the process.env object of node.js.

That could be enough but, I like to add an extra step.
Have a config/index.ts file where the dotenv npm package and loads the .env file and then I use an object to store the variables, so we have a structure and code autocompletion.

config/index.js



  const dotenv = require('dotenv');
  // config() will read your .env file, parse the contents, assign it to process.env.
  dotenv.config();

  export default {
    port: process.env.PORT,
    databaseURL: process.env.DATABASE_URI,
    paypal: {
      publicKey: process.env.PAYPAL_PUBLIC_KEY,
      secretKey: process.env.PAYPAL_SECRET_KEY,
    },
    paypal: {
      publicKey: process.env.PAYPAL_PUBLIC_KEY,
      secretKey: process.env.PAYPAL_SECRET_KEY,
    },
    mailchimp: {
      apiKey: process.env.MAILCHIMP_API_KEY,
      sender: process.env.MAILCHIMP_SENDER,
    }
  }

This way you avoid flooding your code with process.env.MY_RANDOM_VAR instructions, and by having the autocompletion you don't have to know how to name the env var.

Visit the example repository

Loaders 🏗️

I took this pattern from W3Tech microframework but without depending upon their package.

The idea is that you split the startup process of your node.js service into testable modules.

Let's see a classic express.js app initialization



  const mongoose = require('mongoose');
  const express = require('express');
  const bodyParser = require('body-parser');
  const session = require('express-session');
  const cors = require('cors');
  const errorhandler = require('errorhandler');
  const app = express();

  app.get('/status', (req, res) => { res.status(200).end(); });
  app.head('/status', (req, res) => { res.status(200).end(); });
  app.use(cors());
  app.use(require('morgan')('dev'));
  app.use(bodyParser.urlencoded({ extended: false }));
  app.use(bodyParser.json(setupForStripeWebhooks));
  app.use(require('method-override')());
  app.use(express.static(__dirname + '/public'));
  app.use(session({ secret: process.env.SECRET, cookie: { maxAge: 60000 }, resave: false, saveUninitialized: false }));
  mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true });

  require('./config/passport');
  require('./models/user');
  require('./models/company');
  app.use(require('./routes'));
  app.use((req, res, next) => {
    var err = new Error('Not Found');
    err.status = 404;
    next(err);
  });
  app.use((err, req, res) => {
    res.status(err.status || 500);
    res.json({'errors': {
      message: err.message,
      error: {}
    }});
  });


  ... more stuff 

  ... maybe start up Redis

  ... maybe add more middlewares

  async function startServer() {    
    app.listen(process.env.PORT, err => {
      if (err) {
        console.log(err);
        return;
      }
      console.log(`Your server is ready !`);
    });
  }

  // Run the async function to start our server
  startServer();

As you see, this part of your application can be a real mess.

Here is an effective way to deal with it.



  const loaders = require('./loaders');
  const express = require('express');

  async function startServer() {

    const app = express();

    await loaders.init({ expressApp: app });

    app.listen(process.env.PORT, err => {
      if (err) {
        console.log(err);
        return;
      }
      console.log(`Your server is ready !`);
    });
  }

  startServer();

Now the loaders are just tiny files with a concise purpose

loaders/index.js



  import expressLoader from './express';
  import mongooseLoader from './mongoose';

  export default async ({ expressApp }) => {
    const mongoConnection = await mongooseLoader();
    console.log('MongoDB Intialized');
    await expressLoader({ app: expressApp });
    console.log('Express Intialized');

    // ... more loaders can be here

    // ... Initialize agenda
    // ... or Redis, or whatever you want
  }

The express loader

loaders/express.js




  import * as express from 'express';
  import * as bodyParser from 'body-parser';
  import * as cors from 'cors';

  export default async ({ app }: { app: express.Application }) => {

    app.get('/status', (req, res) => { res.status(200).end(); });
    app.head('/status', (req, res) => { res.status(200).end(); });
    app.enable('trust proxy');

    app.use(cors());
    app.use(require('morgan')('dev'));
    app.use(bodyParser.urlencoded({ extended: false }));

    // ...More middlewares

    // Return the express app
    return app;
  })

The mongo loader

loaders/mongoose.js



  import * as mongoose from 'mongoose'
  export default async (): Promise<any> => {
    const connection = await mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true });
    return connection.connection.db;
  }

See a complete example of loaders here

Conclusion

We deep dive into a production tested node.js project structure, here are some summarized tips:

Use a 3 layer architecture.
Don't put your business logic into the express.js controllers.
Use PubSub pattern and emit events for background tasks.
Have dependency injection for your peace of mind.
Never leak your passwords, secrets and API keys, use a configuration manager.
Split your node.js server configurations into small modules that can be loaded independently.

See the example repository here

✋ Hey ! Before you go 🏃‍

If you enjoy this article, I recommend you to subscribe to my email list so you never miss another one like this. ⬇️ ⬇️

I will not try to sell you anything, I promise

And don't miss my latest post, I believe you will love it :)

🛑 You don't need passport.js - Guide to node.js authentication ✌️

Sam ・ May 31 '19

#node #javascript #tutorial #webdev

Read my research on the most downloaded frontend framework, the result will surprise you!

Top 10 Front-End Frameworks by Downloads [2015-2019]

Sam ・ Jul 28 '19

#javascript #angular #react #vue

Forem: Sam

Introducing the Best 10 Node.js Frameworks for 2019 and 2020

What is a node.js framework?

How to choose a node.js framework for my application?

10. Adonis

What’s is this framework about?

👉 GET MORE ADVANCED NODE.JS DEVELOPMENT ARTICLES

9. Feathers

See what’s capable of!!

8. Sails

See it in action

7. Loopback

6. Fastify

Show me the code

5. Restify

Code example

👉 GET MORE ADVANCED NODE.JS DEVELOPMENT ARTICLES

4. Nest.js

Example

3. Hapi

Creating a server

2. Koa

Example

1. Express

Example

Conclusion

Bulletproof node.js project architecture 🛡️

Sam ・ Apr 18 '19

Now tell me, what is your favorite node.js framework?

👉 GET MORE ADVANCED NODE.JS DEVELOPMENT ARTICLES

Top 10 Front-End Frameworks by Downloads [2015-2019]

And here are my opinions on each framework

jQuery

React.js

Preact

Angular.js (The classic)

👉 GET MORE ADVANCED NODE.JS DEVELOPMENT ARTICLES

Angular.io (2/4/6/8/etc)

Vue

Ember

Polymer

Backbone

Svelte

Conclusion

👉 GET MORE ADVANCED NODE.JS DEVELOPMENT ARTICLES

Bulletproof node.js project architecture 🛡️

Sam ・ Apr 18 '19 ・ 11 min read

🛑 You don't need passport.js - Guide to node.js authentication ✌️

Introduction

Table of contents

Project requirements ✍️

How to create a Sign-Up 🥇

How to create a Sign-In 🥈

But, what is a JWT anyway? 👩‍🏫

How to generate JWT in node.js 🏭

Securing endpoints and verifying the JWT ⚔️

Why a JWT is secured ?

How to impersonate a user 🕵️

Conclusion 🏗️

See the example repository here 🔬

Resources

✋ Hey ! Before you go 🏃‍

Bulletproof node.js project architecture 🛡️

Sam ・ Apr 18 '19

Top 10 Front-End Frameworks by Downloads [2015-2019]

Sam ・ Jul 28 '19

Timelapse: Creating a Landing Page

Bulletproof node.js project architecture 🛡️

Introduction

Table of contents

The folder structure 🏢

3 Layer architecture 🥪

☠️ Don't put your business logic inside the controllers!! ☠️

Use a Pub/Sub layer too 🎙️

Dependency Injection 💉

Using Dependency Injection with Express.js in Node.js

An unit test example 🕵🏻

Cron Jobs and recurring task ⚡

Configurations and secrets 🤫

Loaders 🏗️