How to scale a Nodejs app based on number of users


Massive success is the best that could happen to any application. But, it could be a blessing and a curse for developers. Dealing with downtime, high availability and trying to scale. The following is a guideline on how to scale the web applications as the number of users grows.

One of the most dreaded questions is: ‘Would that scale?’. The following is a guideline on how to grow the web applications as the number of users grows. Scaling an application too early is more painful than beneficial. This guide provides a way how to start simple and scale as the number of users grows.

Common Server Setups For Scaling Your Web Application

The examples and solutions will be as practical as possible. We might use references to Amazon Web Services (AWS), Digital Ocean or other cloud solutions. Also, there are some NodeJS/Nginx references, but they could easily be translated to other technologies.

You may notice, that the measurement we are using is “concurrent user”, which means all users are hitting the web app at the same time. It’s different from the number of users supported (which might be higher) since it’s unlikely that all users are hitting the app at the same time. However, we are going to use “concurrent user” since it’s easier to explain.

Local host (1 concurrent users)

You are the only one using your app on your localhost.

There is no need to worry about scale.

Single Server (2 – 9 concurrent users)

You deployed your app to the wild! You and your colleges (and maybe close friends) are the only users so far.

Everything is great on a single server as long as you are using a web server that uses an event model like Nginx. NodeJS by nature uses an event-driven and non-blocking I/O model. It means that it won’t block with a single request, rather it will handle all the request and reply as data from database or services comes available in a callback/promise. Your Node app will spend most of the time waiting for the database or file system to respond. In the meantime, it can take multiple requests.

Your app should be a monolith (single app) right now, and it’s fine. No need to complicate your life for just a few users yet.If people are reporting bugs, unfortunately, as you make changes, you will need to take it down the app while updating the server. Using AWS t2.micro/t2.nano or equivalent (1 CPU/ 1 GB RAM) will do.

How to build scalable apps?


Scaling application is not an easy topic to cover in one post. So in this first post, you can find “the mindset” to build scalable apps using the 12-factor principles. In the next post, you will find more down to earth examples one how to scale based on the number of users.

The Twelve steps are a compilation of guidelines to ensure apps can scale up without significant changes and tooling. These are very suitable for cloud platforms and continuous deployment. Furthermore, these principles are language agnostic, so it will work with any framework.

The Twelve Factor Principles

One codebase per app, multiple deployments


  • One codebase to rule all deployment environments: production, staging, local and so on and differentiate them from config files (see #3).


  • Multiple apps sharing the same code. INSTEAD the common code should be extracted from a library and included through a dependency manager.

Declare and isolate dependencies


  • Have a dependency declaration manifest (e.g. packages.json, Gemfile)
  • Execute dependencies in isolation per app (e.g. bundle exec).


  • Rely on implicit existence of system-wide packages (e.g. curl, ImageMagik). INSTEAD vendor them into the app.

Store the config in the environment


  • Separate app’s config (AWS S3, passwords, Google/Fb/Tw/APIs credentials, deployment hostname) from the code.
  • Keep the code ready in a way that if were open source, it wouldn’t compromise any credentials.
  • Use/commit ‘config’ files with sensitive information into repository. INSTEAD use environmental variables (env, env vars) which are easily changed between deployments and without changing code.


  • Group config variables by environment (e.g. AWS_S3_PRODUCTION, AWS_S3_TEST, AWS_S3_QA, AWS_S3_STAGING, AWS_S3_JOE…). INSTEAD use clean environment variables (e.g. AWS_S3) that are managed individually per deploy.

Swappable local and third party services


  • Services like databases (e.g. MongoDB, PostgreSQL), message queues (e.g. RabbitMQ, Beanstalkd) should be accessed via URL or locator/credential stored in config.
  • Swapping local to production services should be done without any code changes.

An Introduction to Cordova


In this article, I’ll introduce you to Cordova, a framework used for developing mobile applications. If you’re new to Cordova or you want to know whether it’s the right tool for your next project, then you’re in the right place. In this article, I’ll be aiming to answer the following questions:

  • What is Cordova?
  • How does it work under the hood?
  • What can I build with Cordova?
  • How do I get started with Cordova and what do I need?

Let’s go ahead and dive in.

Cordova is a mobile application development framework that is primarily intended for web developers. It allows web developers to use web technologies, such as HTML, CSS, and JavaScript, to create mobile applications. Like any other technology, Cordova has its pros and cons.

  • Easy to Learn If you’re a web developer, then Cordova has a gentle learning curve. You can easily apply your skills as a web developer to build an app with Cordova. All you really need is to familiarize yourself with the command line in order to get up and running with Cordova.
  • Access to Native Functionality With Cordova, you have access to native device capabilities, such as the camera, contacts, geolocation, media, SMS, and many others.
  • Free You don’t have to pay anything to use Cordova.
  • Open Source Anyone can contribute to Cordova’s source code to make it better. Plugins are also open source and anyone can build custom plugins. This means that developers like yourself can easily install and use these plugins. Or you can build your own plugin and share it with the community.
  • Big Community Lots of developers are using Cordova. On Stack Overflow, for example, there are close to 50,000 questions tagged with cordova. This means that you’ll never be left alone solving weird bugs (if you ever encounter them). People in the community are always willing to help, all you have to do is ask.
  • Write Once, Deploy Everywhere Cordova compiles your app into a package file, which is required by most app stores. This means that apps created with Cordova can easily be deployed to the app store of your choosing. If you’re deploying to Android, Cordova creates an APK (Android Application Package) file. If you’re deploying to iOS, Cordova compiles to IPA. For Windows, it’s APPX.
  • Poor Documentation It’s hard to find information about really specific things, such as what packages you need to install with the Android SDK Manager. And when you look something up, the results point to information specific to different versions of Cordova. This is sometimes confusing for beginners as they might have a different version of Cordova installed and they’re looking at documentation for another version of Cordova.
  • Slower Than Native Since apps built with Cordova are basically web apps that are contained in a web view, they don’t perform as well as their native counterparts. This means that there is a limit to what kind of apps you can build. For example, a video editing application is better built natively since it will heavily rely on the CPU and GPU to do its work.
  • Frameworks Because Cordova is just a wrapper for a web application, it doesn’t come with the user interface components, animations, and other goodies that you find in most native applications. This means that you have to implement all of these on your own. That’s why many developer rely on frameworks like Ionic or Onsen UI for building the user interface of their applications.
  • Bugs in Plugins Not every plugin is created equal. There are those that have bugs or don’t work as expected.
  • Not Every Device Is the Same Native device functionality is accessed through the use of plugins. Cordova exposes an API so that these plugins can be used in the web view, but not every device is the same. There are quirks on every device. To put it simply, not every option that you can set on a plugin will work on every device. For example, on Android, the cameraDirection value always results in a photo taken with the rear-facing camera.

Hybrid vs Native Mobile App Development


If you’re confused and wondering whether to build a hybrid mobile app or a native mobile app, this article will help you decide the mobile app strategy in less than 5 minutes! I’ve stumble upon a lot of curious and confused entrepreneurs who go crazy trying to decide on how to approach their Mobile App piece.

Quick one-liners on Hybrid Apps and Native Apps before we get started:

Hybrid App: Developer augments web code with native SDK. Can be easily deployed across multiple platform and is usually the cheaper and faster solution.

Native App: This is platform (iOS, Android etc.) specific and requires unique expertise. However the full potential of the platform can be leveraged which will drive great user experience and larger app capabilities (especially around phone hardware). Can be pricey based on requirement and may take longer to develop.

5 Questions to ask before you decide

The answers to most of the questions that I have pointed here might be interrelated. But, you’ll get the drift.

  1. Do you want to use native features in the Mobile App?

If your app is heavy on native phone capability and this is your primary USP, then native app development will work best. While building a Hybrid Mobile App, depending on the framework that you adopt (there are several in the market), you may or may not have access to native features. Some of these native features can be the Camera, Contacts, SMS, Hardware Device Buttons, Map, Push Notification,. However, it doesn’t mean that these features can be accessed only in a native app. Some of these features can be used in a hybrid app by pulling the native components separately.

PHP 7 New Features


An overview of the features, changes, and backward compatibility breakages in PHP 7

Difference between Sharding And Replication on MongoDB


A Replica-Set means that you have multiple instances of MongoDB which each mirror all the data of each other. A replica-set consists of one Master (also called “Primary”) and one or more Slaves (aka Secondary). Read-operations can be served by any slave, so you can increase read-performance by adding more slaves to the replica-set (provided that your client application is capable to actually use different set-members). But write-operations always take place on the master of the replica-set and are then propagated to the slaves, so writes won’t get faster when you add more slaves.

Replica-sets also offer fault-tolerance. When one of the members of the replica-set goes down, the others take over. When the master goes down, the slaves will elect a new master. For that reason it is suggested for productive deployment to always use MongoDB as a replica-set of at least three servers, two of them holding data (the third one is a data-less “arbiter” which is required for determining a new master when one of the slaves goes down).

A Sharded Cluster means that each shard of the cluster (which can also be a replica-set) takes care of a part of the data. Each request, both reads and writes, is served by the cluster where the data resides. This means that both read- and write performance can be increased by adding more shards to a cluster. Which document resides on which shard is determined by the shard key of each collection. It should be chosen in a way that the data can be evenly distributed on all clusters and so that it is clear for the most common queries where the shard-key resides (example: when you frequently query by user_name, your shard-key should include the field user_name so each query can be delegated to only the one shard which has that document).

The drawback is that the fault-tolerance suffers. When one shard of the cluster goes down, any data on it is inaccessible. For that reason each member of the cluster should also be a replica-set. This is not required. When you don’t care about high-availability, a shard can also be a single mongod instance without replication. But for production-use you should always use replication.

So what does that mean for example?

When you want to split your data of 75GB into 3 shards of 25GB each, you need at least 6 database servers organized in three replica-sets. Each replica-set consists of two servers who have the same 25GB of data.

You also need servers for the arbiters of the three replica-sets as well as the mongos router and the config server for the cluster. The arbiters are very lightweight and are only needed when a replica-set member goes down, so they can usually share the same hardware with something else. But Mongos router and config-server should be redundant and on their own servers.

Ionic Framework: Features and Benefits


Ionic (mobile app framework) was created in the year 2013 by Drifty Co and provides tools for developing hybrid mobile apps using web technologies such as HTML5, CSS and Sass. After taking feedback from clients & customers who tried to create mobile apps, the team of Drifty Company decided to build their own framework that would mainly focus on performance and be developed with the latest web standards. A 1.0 beta was released in March 2014 and a 1.0 final in May 2015.

Where Does Ionic Fit?

Ionic, a complete open-source SDK for HTML5 mobile app development frameworks is targeted at building hybrid mobile apps (a web app, mainly built using HTML5 and JavaScript), which are basically small websites running in a browser shell in an app that have access to the native platform layer. Additionally, hybrid apps have lots of advantages in comparison to pure native apps (an application program that has been developed for use on a particular device or platform), generally in terms of platform support, access to 3rd party code and of course speed of development.

Different from a responsive framework, this comes with very native-styled mobile user interface (UI) elements or layouts that you’d get with a native SDK for Android or iOS, but didn’t exist before on the web. Also, Ionic provides some opinionated but very powerful ways to develop mobile apps that eclipse existing HTML5 development frameworks. As it is an HTML5 framework, so it required a native wrapper, such as PhoneGap or Cordova so as to run as a native app.

Features Of Ionic Framework

Since it is a completely free and open-source framework, Ionic helps to build hybrid apps using HTML5, and makes use of Angularjs for creating a powerful SDK perfectly-suited to develop highly interactive apps. It provides a great range of tools and services that make using the framework, and once you’ve got node installed, then Ionic is as easy as running.

Difference between Angular 1 VS Angular 2


Angular 2 is still in beta version, but it has already created a buzz in AngularJs community. Angular 2 is using Hierarchical Dependency Injection system which is major performance booster. Angular 2 implements unidirectional tree based change detection which again increases performance. As per ng-conf meetup,
Angular 2 is 5 times faster as compared to Angular 1. Angular 2 will be a huge learning curve for developers. It is written entirely in Typescript and meets the ES6 specification. And it’s not an update for Angular 1.x. As it’s rewritten and includes breaking changes. So the best way to learn is to compare with Angular 1.x and find out what’s new in Angular 2. In this post, I am going to show differences between Angular 1.x and Angular 2. Let’s begin….

Difference between Angular 1.x Vs Angular 2

1). Angular 2 is mobile oriented & better in performance. 

Angular 1.x was not built with mobile support in mind, where Angular 2 is mobile oriented. Angular 2 is using Hierarchical Dependency Injection system which is major performance booster. Angular 2 implements unidirectional tree based change detection which again increases performance . As per ng-conf meetup, angular 2 is 5 times faster as compared to angular 1.

2). Angular 2 provides more choice for languages.

Angular 2 provides more choice for languages. You can use any of the languages from ES5, ES6, TypeScript or Dart to write Angular 2 code. Where, Angular 1.x has ES5, ES6, and Dart. Using of TypeScript is a great step as TypeScript is awesome way to write JavaScript.

3). Angular 2 implements web standards like components.

Angular 2 implements web standards like components, and it provides better performance than Angular 1.

4). AngularJS 2.0 is  not easy to setup as AngularJS 1.x.

AngularJS 1.x is easy to setup. All you need to do is to add reference of the library and you are good to go. Where AngularJS 2 is dependent of other libraries and it requires some efforts to set up it.

ECMAScript 6: New Features


ECMAScript 6, also known as ECMAScript 2015, is the latest version of the ECMAScript standard. ES6 is a significant update to the language, and the first update to the language since ES5 was standardized in 2009.

This is a brief JavaScript timeline:

  1. 1995: JavaScript is born as LiveScript
  2. 1997: ECMAScript standard is established
  3. 1999: ES3 comes out and IE5 is all the rage
  4. 2000–2005: XMLHttpRequest, a.k.a. AJAX, gains popularity in app such as Outlook Web Access (2000) and Oddpost (2002), Gmail (2004) and Google Maps (2005).
  5. 2009: ES5 comes out (this is what most of us use now) with forEach,Object.keys, Object.create (specially for Douglas Crockford), and standard JSON
  6. 2015: ES6/ECMAScript2015 comes out; it has mostly syntactic sugar, because people weren’t able to agree on anything more ground breaking (ES7?)

See the below references for full specification of the ECMAScript 6 language.

How to turn your app Idea into Mobile Application


Today mobile app markets are flooding with plenty of apps. Therefore, if you search an app for a particular purpose, you will end up with numerous apps simultaneously on your list, and you need to do a comparative study to select the most appropriate one for you.

It is indirectly indicating for an app entrepreneur and developer that market is fiercely competitive and achieving success is daunting indeed.

In such scenario, great app ideas and right development process with right mobile app development team are vital needs for sure success. Therefore, today I would like to discuss how to gain a great idea and turn it into concrete reality.

Developing a Great Idea

Thinking a great idea is half of the work, so if you avoid following mistakes while creating a good app idea for you or your business, you have done great at the first step.

  • Don’t mull over so many ideas, but conclude the best and the most relevant idea or a few idea and select one for implementation.
  • If you want to validate your chosen idea, it is your actual customers can do it for you. Take survey or go directly to your target audience and validate your idea.
  • Think of its potential market and validate your idea with marketing professionals too.
  • Focus on your great idea with zeal and devote your all resources including precious time on it to convert into solid reality on the mobile devices of your target audience as soon as possible.
  • Define the monetization strategy for your app among the several current options such as free app with ads, subscription model, in-app purchase, sponsorship model, and so many others.