ReadsNGeeks : Get latest articles on Software Development and Coding Best Practices

NodeJS Application with Docker

2020-08-21T11:01:00.005+05:30

In the last article, we went through the basics of Docker. Like what is a Docker Image, what are containers and how we run a docker image on our system. In this article, we will create a NodeJS application, wrap it inside a Docker container, and run that application on our local machine. We won't be creating any complex application, we are just focused on getting NodeJS work inside a Docker Container.

To begin with, let's set up a NodeJS project first. For that, we need to create a folder. Then inside that folder, we need to create a package.json file that will contain all the dependencies of our project. Inside package.json we will put the following:

{
    "dependencies":{
        "express":"*"
    },
    "scripts":{
        "start":"node index.js"
    }
}

Now create an index.js file which will contain our main server startup and API code. Inside index.js we put the following lines of code:

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

app.get('/cube',(req,res)=>{
    var number = req.query.number
    return res.json({
        value: Math.pow(number,3)
    })
})
app.listen(8080,()=>{
    console.log('Listening on port 8080')
})

Here we are using the express framework, we stated that as dependency is our package.json . In index.js we are importing the express library and creating an app instance of it. Then we create an api /cube which will take a number as input and return the cube root of that number. Finally, we specify the server to run on port 8080.

Next step is to create a Dockerfile. A Dockerfile is basically a text file that contains some settings and commands that are needed to be executed in order to create a docker image of our project. We just need to create a file named Dockerfile and put the following content inside it.

#Specifiy a base image
FROM node:alpine

#Copy all project files inside container
COPY ./ ./
#Install dependencies
RUN npm install

#Start Up command
CMD ["npm","start"]

Let's understand each of these commands one by one. First, we need to specify a base image. The container inside which the image will is in total isolation and doesn't have node or npm installed. So we use a node:alpine which is a lightweight node environment already available in docker hub. This will give us the node environment to run our project. Next using the COPY ./ ./ command we copy our project files and folders into the container. Then npm install will install all the dependencies inside package.json inside the container. And in the end, we specify the command which will start our server.

Now we need to build our image. For this, we open up the terminal inside our project folder and run the command docker build . , it will start up the build process and on successful build, we will get an image id.

Now to run the image we have to run the command docker run <build_id> . The node server will start up on the specified port.

There is one more thing to be taken care of. We can see the server running on port 8080 on our local machine, but if we try to access localhost:8080 we won't be able to do so. The reason for this is the server is running on the container's port number 8080, not on our machine's port 8080. To access this via our machine's port 8080 we need to set up a port mapping. The way we do this is specifying some extra parameters in the docker run command. We run the following command:

So, after executing this command we will be able to access the NodeJS application from localhost:8080.

So, using docker we have containerized a NodeJS application. By this method, we can even develop NodeJS application without NodeJS being installed on the system.
Hope this article has helped you to get an understanding of how NodeJS and Docker work together. If you have any feedback and doubts do mention them in the comments. Stay Safe and Happy Coding!

All about Docker - Beginner's Insight

2020-08-09T22:20:00.002+05:30

Before diving into what Docker is and the details of it, let us first try to understand why to use Docker and what problem does it solve.

Suppose, you are installing a software on your machine. So the steps we follow are downloading a software and installing it. During installation, we often get errors due to some other setup and dependencies. We then try to troubleshoot it and continue our installation. Like this, we might get many errors and keep on troubleshooting the issues. This is where Docker can help.

Docker makes it easy to install a software without getting into any kind of setup or dependency issue.

Using Docker we can install any software using just one command and then start using that software. At the end of this article, there is a basic video tutorial of how to install docker and how to install and run an application using Docker.

So, what is Docker?

Going by definition:

Docker is a platform, that uses OS-level virtualization to enable developers to install and run any application as a lightweight, portable package known as container.

Now, to understand this definition in depth we first need to know about different components in the Docker Ecosystem and then about Containers.

Docker Ecosystem is basically a collection of different projects and tools that helps in installing and running any application via Docker.

So, here we can say six different tools in the docker ecosystem. Let's get a brief idea on each of them.

Docker Client: When we install docker on our system, we generally use the CLI to interact with other docker tools from our system. So, the CLI in our system becomes a Docker Client.
Docker Server: A docker server is the one that handles all the requests from the client like when a client requests to install an application, it requests the docker server, the docker server then fetches the image of that application from the docker hub.
Docker Hub: It is a place where the images of each application is stored. It is like an online repository of applications from where docker fetches and installs any application on our system.
Docker Image: In some of the points above, we mentioned about images of an application. What are we referring to as image is basically a docker image. A Docker Image of an application is a single file with all the dependencies and configuration required to run that application.
Docker Compose: In the next section we will see what are containers. Docker Compose is a tool that allows us to run multiple containers and provides a way to interact between them.
Docker Machine:Docker Machine is a tool that allows us to run Docker in a variety of environments, like on a virtual environment or on a cloud system

What is a Container?

In the previous section learned what a Docker Image is. So the image of an application is a single file containing all configurations and dependencies needed to run that application. Now when we install any application using Docker, the image of the application gets downloaded. To run this image we need hardware resources like memory, network drivers and hard disk space. Now, we don't run these images directly on our system, instead these images are run using Containers. A container is a sort of virtual environment which is totally independent and has its own set of hardware resources. Inside a container, we have an instance of the image of an application and the application runs inside the container using its hardware resources. We can create as many containers on our system and use them to run the same image, but each of these containers will run in complete isolation, i.e an application running in one container won't affect the application in another container.

Let's dig a bit deep and see how containers work.
To have a better understanding of how containers work, one should have a brief idea of an OS kernel. The OS kernel is a software process that governs access between all the application programs running on a system and all the physical hardware like CPU, Memory, etc. Any application process like Chrome or NodeJS cannot access the hardware directly, instead they make system calls to the kernel and kernel assigns the hardware resources to them.
Now, when we install docker on our system a Linux virtual environment is created with its own kernel. Now to when we try to run a docker image, this kernel separates a portion of hardware resources like CPU, Hard Disk, Memory, etc. These portion of hardware resources are totally isolated and only available to the running application. This basically becomes a container. Now, the instance of docker image is loaded into the container's memory and it is started using the docker image's startup command. Have a look at this diagram to get a better understanding.

Here is a video demonstration of installing docker and running an application using docker.

Hope after reading this you get a basic understanding of what docker is and how it works. Although there is no hands-on example on how to use docker, but these concepts are necessary before you get started. In the next article, we will build a NodeJS application using Docker, so don't forget to subscribe. Stay Safe and Happy Coding!

Creating and Publishing an NPM package

2020-08-01T10:22:00.001+05:30

What is NPM?

If you are a JavaScript developer, you most probably know what NPM is. NPM (Node Package Manager) is an open-source online repository where JavaScript developers create and publish different JS packages to be used by other JS developers. It consists of public as well as paid-for private packages.

In this article, we will see how to create a node package and publish it to npm.

What will we build?
Here, we are mainly focused on the steps to create and publish an npm package, so we won't be building anything that does some complex stuff. We will try to build a Counter, which will take an array or a string as input and will return how many times each unique element occurs in the array or string. It will return a JSON object where each element will be a key and the value for each key will be the number of occurrences of that element.

For example:

Input: ['a','b','a','c','d','b','c','a']

Output:{'a':3, 'b':2, 'c':2, 'd':1}

Before we get started we need to make sure that node and npm are installed on our system. To check, open the terminal and type npm -v and node -v. For each of them, the system will show the version that is installed and if it is not installed it will throw an error stating command not found. If not installed we can install using this guide.

- Create and Initialize the repository: First of all, make a folder and initialize it as an npm project by running npm init. After running npm init, you will be prompted to input certain configuration values like this:

We can either input these values as per our requirement or keep on pressing enter for default values. Then a prompt will come up asking whether the above-entered details are correct. Type yes and press enter.

- Write the project code: After this open up the project folder in a code editor. Inside it there will be a file called package.json which contains the configurations which we mentioned during npm init. Something like this:

{
  "name": "js-counter",
  "version": "1.0.0",
  "description": "A module which will take an array or a string as input and will return how many times each unique element occurs in the array or string",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Saptarshi Dey",
  "license": "MIT"
}

Now create a file named index.js. This will be our main file and here we will write the function which will perform our required task. Below is the code as per our requirement:


function Counter(input){
    var result = {}
    len = input.length
    
    for(i=0;i<len;i++){
        if(result[input[i]]){
            result[input[i]]+=1
        }else{
            result[input[i]]=1
        }
    }
   
    return result
}
module.exports={Counter}

- Publishing the package: To publish the package we first need to authenticate. For that go to the terminal and type npm login. Then enter your username and password when prompted. If you do not have an npm account, you can create it here.

Now after logging in we can publish the package. One thing to watch out for is the name of the package. The name of the package is mentioned in package.json and if any package with the same name already exists in the npm registry we cannot publish our package. Here are the package name guidelines. If the name is unique we can publish the package just by running npm publish.

After publishing is successful, you can visit your account in the NPM registry to see the package.

- Testing: To test the package we have to install the package. First, create a repository and install the package.

#create a test repository and navigate inside it
mkdir test-package
cd test-package

#install the package
npm install js-counter

#create a index.js file
touch index.js

Then inside the index.js you can write the following code to test out your package:

const counter = require('js-element-counter')
console.log(counter.Counter([1,2,1,2,2,3,4,1,2]))

You will get the output as:

{ '1': 3, '2': 4, '3': 1, '4': 1 }

This was a basic step to create an npm package. To this, you can add a proper README file stating the usage of the package with some examples.

Here is a detailed video of the steps mentioned above:

Now as you know to create and publish your own npm package, dive in to create some cool packages and publish them, who knows your package might become helpful for some other developer out there!

API Security - Securing API with Tokens and JWT

2020-07-24T10:22:00.006+05:30

API security is one of the most important aspects of designing and implementing REST APIs. Without adequate security, it does not really matter what other design principles have been taken care of. In this article, we will see about the different types of functional attacks possible on the API path length and how to authenticate REST APIs using Tokens. We will also implement this by creating a NodeJs API and integrating JsonWebToken (JWT) in it.

Before we get started, let us see the basic difference between Authentication and Authorization.

Authentication: It is the process to verify that you are really who you claim to be. With authentication, APIs verify that the request is coming from its trusted list of sources.
Authorization: It is the process of checking whether you have access to a certain resource. Like a client can be a trusted source for an API but that particular client might not be authorized to view some confidential data.

At what points attacks might happen?

Attacks can happen at multiple points on the API path length. Like a hacker can attack directly the client and intercept the data, also the hacker can exploit any vulnerability on the API gateway and he can also breach the firewall to attack the application server directly or the database.

Types of functional Attacks:

Data Theft: Here the attacker breaks into the system to steal confidential data like bank details of a person, credit card details, etc.
Data Manipulation: Here the attacker tries to change/alter the data that is being transferred.
Identity Theft: In identity theft the attacker gains personal information of a victim by deception and misuse that information in the victim's name
DOS Attack: Denial Of Service(DoS) is an attack where the attacker tries to stop genuine clients from accessing the server by flooding the application server with traffic or sending requests that causes the server to crash

API Authentication is one of the ways to prevent these types of attacks. Next, we will look into Token Based Authentication which is being widely used now-a-days.

Token Based Authentication

Token based authentication requires the client to request a token from the server. The server after receiving the request verifies the client and sends back a token to the client. The client on each subsequent request to the server should send the token else the request will be rejected.

JSON Web Tokens:

A JSON Web Token is an open standard for securely transmitting data between two parties as a JSON object. It is self-contained, means all the information required to verify a client is contained in the token itself.

This is how a JSON Web Token looks like:

As we see a JSON Web Token contains three parts:

Header: This contains metadata which is hashed using any algorithm like HMAC and is base64 encoded
Payload: This contains the claims, which is some set of data like who is the issuer, expiry timestamp of the token, etc. This is also hashed and base64 encoded
Signature: This is the combined hashed value of header and payload and is also encrypted using a secret key

Here is a basic example of integrating JWT authentication in NodeJS. For this, we have used the npm package jsonwebtoken.

NodeJS code for JWT integration

Here we have created a /token endpoint which takes id and password and validates it with a static user credential. If the id and password matches then we create a token using a private key. Here we have hard-coded the private key but generally it should be read from a separate file or environment variable. Then we return the created token to the client. If the credentials do not match we send an unauthorized response.
Then we have an authentication middleware, which extracts the value from each subsequent request header and verifies it. If success then we send back a message stating the client is verified else if it fails in the auth middleware then we send an unauthorized response.

Here is a working demo of the above code. We have used Postman here for trying out the APIs.

Hope this article has given a clear concept on API security and about JWT authentication. You can get the above code in this link. Do mention your thoughts and views in the comments. Stay Safe and Happy Coding!

API Caching - Reducing Network Calls

2020-07-14T11:12:00.000+05:30

What is Caching?

Caching is the ability to store copies of frequently accessed data in several places along the request-response path.
In terms of REST APIs, caching is storing the response of APIs having relatively high response time in an in-memory or distributed system, so that the response can be fetched from the stored system within a short amount of time.

Why implement caching?

There are generally two basic reasons for which REST API developers implement caching:

Reduce Network Calls: Most API operations are read operations, so when data doesn't change then there is no need to fetch data again and again from a database. For this, we can have an in-memory cache where we can save the data as key-value pair and fetch the data from the cache. As a result of this network calls will be reduced significantly.
Reduce Load on Database: When we are using a cache, then for most of the time we will be fetching data from the cache and won't be querying the database much. So, as a result, database query/computational costs are decreased and so the concurrency of the database increases.

Types of Caching

API Caching can be sub-divided into in-memory caching and distributed caching based on where data is being stored.

In-Memory Caching: In memory caching stores data inside the application server itself. A certain portion of the memory in the application server is allotted for caching. It is not distributed and neither scalable.
Distributed Caching: A distributed cache is a cache maintained by multiple servers, typically maintained as an external service which the application server can access. Distributive Caching is useful when we have to store lots of data in the cache. It can improve performance by scaling horizontally.

How much improvement is possible?

Let us take an example here. Suppose we have an API that fetches the transaction data for any user in an online shopping site. Let's assume the Database Access Time = 30ms, Cache Access Time = 8ms and Computational Buffer = 5ms.

Now if a user makes the API call 10 times, then without using cache the total time taken will be = (30+5)*10 = 350ms
If caching is there, then 1st request won't get any data from cache, so the API will query the database for the first time, after that the result will be stored in the cache and from the subsequent requests data will be fetched and returned from the cache.
So, using cache total time taken will be = (30+8+5)*1 + (8+5)*9 = 160ms

Here we see that for 10 API calls, the total response time has reduced by almost 54%.

The problem - Cache Invalidation

There are only two hard things in Computer Science: Cache Invalidation and naming things
- Phil Karlton

Caching is a great solution for reducing network and calls and improving the performance of our APIs. For a low response time, we want to cache our content for a longer period of time. But at the same time, we should be able to return fresh data whenever there is an update in our main database. Cache Invalidation is the process in which the content stored inside a cache replaced or removed as the data it contained is now no longer useful.
For example, there is a cache which contains the basic information of an user. An API fetches user info from this cache and returns it to the client. Now suppose the user changes his phone number and the update happens in our main database. So for this, either the cache has to be updated with the new data or the cache has to be removed so that the API directly goes and fetches from the main database.
Now, when and how to invalidate a cache depends mostly on the business requirements, like whether the updated data has to be instantly visible to the client or it will be available after a certain interval of time, whether comprising on response time is possible or not, etc. For this there are these 3 techniques:

Write-through cache: Here, data is updated in the database and cache at the same time. This won't compromise with the response time and updated data will be available instantly but the write operations will take much more time.
Write-around cache: Here, data is directly written to database bypassing the cache. This reduces the write operation costs but the response time for read requests will be high.
Write-back cache: In this case, data is directly written to cache only and success message is sent to client. Then at specified intervals the data update is done on main database by automated scripts. Here also updated data will be available instantly but there is risk of data loss if cache fails.

Well, that is pretty much about the basics of API caching. In this article, we covered what is caching and the different ways it can be implemented, also how it can drastically improve API performance. In the end we discussed about cache invalidation and it's techniques. If you have any doubts or suggestions to improve this article do mention them in the comments. Stay Safe and Happy Coding!

5 Topics For a NodeJS Interview

2020-07-07T19:34:00.000+05:30

Before starting let us look at some statistics on NodeJs. According to StackOverflow's developers survey, 51.9% of Professional Developers use NodeJs, and according to a survey by nodejs.org about 26% companies in the US and 21% in India use NodeJs for their Backend.
NodeJS has been the most widely used technology for API development in the past few years. I have been a NodeJS developer for 3+ years and have given over 20+ interviews for NodeJS developer roles in many companies. I have also interviewed over 30+ candidates for NodeJs developer roles. In this article, I will list down and briefly explain 5 topics on NodeJs. The most frequent questions that I have faced in an interview or asked a candidate as an interviewer is based on these topics.

Now, let's begin

1) NodeJS is single-threaded

So, what is NodeJs? A google search of this will give you some results, and the answer we get is mostly like this:

Node Js is a single-threaded, asynchronous non-blocking I/O model that executes JavaScript on the server-side

NodeJS is single-threaded. What is means is the code we write is executed on a single thread, which is also known as the main thread. Being single-threaded means it has a single call stack and it can do only one thing at a time. But now a question arises - If NodeJS is single-threaded then how does it perform asynchronous non-blocking I/O operations simultaneously. The answer to the question is the Event Loop.

2) NodeJS Event Loop

NodeJS event loop is the heart of the asynchronous nature of NodeJS. The V8 engine runtime, on which NodeJS is built, consists of a heap memory and a call stack, and the NodeJS environment consists of a callback queue, some other APIs, and the Event Loop. All these work together to achieve the asynchronous non-blocking nature of NodeJS. The event loop's main function is to dispatch all the callbacks of various asynchronous functions that have been accumulated in the callback queue. The code execution happens on the main thread while executing when an asynchronous functional call is encountered it is shifted from the main thread and executed separately and when the function completes execution the callback of that function is added to the callback queue and the event loop dispatches it accordingly. To know in detail about how NodeJS works, refer to this article, which we posted on medium.

3) NodeJS Event Emmiter

There are many objects in NodeJS which emit events like fs.readStream emits an event when the specified file is opened. There is a NodeJS module events and all objects which emit events are instances of events.EventEmitter. These objects contain a .on() function by which we can attach an event to it along with the callback for that event. Then using .emit() function,the particular event can be triggered. Have a look at the following code snippet to understand how EventEmitter is used in NodeJS.

4) NodeJS Middlewares

Middlewares in NodeJS are functions that get executed in the middle of the request and response cycle. A middleware has access to the request object, the response object, and to the next middleware function (if any). The code inside a middleware function gets executed before the callback for a particular request is executed. Generally, middlewares are used to change request and response objects, perform authentication, request data verification, etc. To know more about middlewares checkout this link.

5) NodeJS Promises vs Callbacks

This concept is not particularly of NodeJS, it is related to native JavaScript. But still while developing APIs using NodeJS, it is required that one should have a clear knowledge about this. So this topic is common NodeJS interviews also. Now as we all know callbacks are functions that we pass as an argument to another function which is asynchronous in nature. This callback function gets executed when after the parent functions completes its execution. Promises are enhancements to callbacks. For this, we generally write a function that returns a promise object. Promises notify whether the request is fulfilled or rejected. Callbacks can be registered with the .then() to handle fulfillment and .catch() to handle rejection. One problem of callbacks is that nesting of multiple callback functions can lead to something known as callback hell, which decreased code readability, and code management becomes harder. Using Promises, this issue can be solved using promise chaining.

Here we have briefly explained these 5 important topics which are important for a NodeJS interview. Also, it is better if one can get a detailed understanding of these topics. Before we end, a request to anyone who has attended NodeJS interviews in the recent past and has come across important questions, then feel free to comment here, it will be beneficial for others. Also, if you have liked this article do subscribe to get this kind of interview tips directly delivered to your inbox.

System Design - Load Balancing

2020-07-01T20:00:00.001+05:30

What is Load Balancing?

Load Balancing is a technique to efficiently and uniformly distribute network traffic across multiple servers. When we are horizontally scaling our application then we add multiple servers to handle a large amount of network traffic. Here load balancing ensures that no single server receives too many requests and the network traffic is evenly distributed. This improves the whole application responsiveness.

Load Balancing By Normal Hashing:

A Hash map is a data structure that is used to map a given value with a particular key for faster access of elements, and hashing is the technique to map a value to a particular key using a special function. This special function is called a hash function. To know more about hashing and collision resolution techniques, check this article. Now how this hashing is used for Load Balancing?

Each request that a client makes contains a unique request id. Also, each of the multiple servers in the application is numbered. So the technique is to use a hash function which will take in the request ID of the server and generates a key that represents the server number to which this request will be redirected. Let's understand this with the help of an example.

Suppose we have four servers numbered 0-3. Our hash function is defined as h(x) = x % m, where x is the request ID and m is the no. of servers. The below table represents how three requests with request IDs 1000, 1010 and 1027 are mapped.

Request ID	Hash Function	Key/Server No.
1000	h(1000) = 1000%4	0
1010	h(1010) = 1010%4	2
1027	h(1027) = 1027%4	3

So, like this each request will be processed by the server to which it gets mapped after hashing its request ID value.

Drawbacks of using normal hashing:

The above-mentioned method works fine if the number of servers is fixed. But suppose now the total incoming traffic to the application increases over time and we have to scale up our application more. For that reason suppose one more server gets added in our above example. Now we have 5 servers. So now 1000,1010 both will be mapped to server 0 and 1027 to server 2. So now all the requests are being completely being mapped to different servers. So, what is the issue here?

First of all the request Id are not random, they usually contain some client/user information within it. Like here if we assume requests having 100 in the beginning is from a user having user id as U0, then requests having request starting with 101 is from user U1 and requests staring with 102 is from user U2. Now each server has a local cache in which it can store the response of a request for a particular user. All the time the server doesn't fetch from the database, if the request is from the same user within a specific interval of time it returns data from the cache, this improves the response time. Now initially when there were four servers the data of user U1 and U2 were being stored in local cache of server 2 and server 3 respectively. Now after adding another server, the requests from these users are going to different servers which does not have the cached data for these users. So all the cached data stored for all the users at different servers are lost. This operation can reduce the overall speed of the application when there are large no. of requests coming in and also the number of servers are much more.

This can be solved by a concept known as Consistent Hashing.

Load Balancing By Consistent Hashing:

The main difference between normal hashing and consistent hashing is the data structure that is being used. In normal hashing, the data structure is generally a linear array or an object with key-value pair. In the case of consistent hashing, we use a circular array data structure which is also known as consistent hash ring.
Also for consistent hashing we have a pre-defined search space. Let us denote it by N. Here the servers are also hashed into the hash ring. Each server has a unique id too. We can use those server IDs to hash the servers. Let us take our previous example with 4 servers and hash function as h(x) = x % N, here X will be ID of server and N = 100

Server ID	Hash Function	Position
1024(S1)	h(1024) = 1024%100	24
1049(S2)	h(1049) = 1049%100	49
1074(S3)	h(1074) = 1027%100	74
1099(S4)	h(1099) = 1099%100	99

Now lets assume there are these 4 requests with IDs 1023(R1), 1145(R2), 1270(R3) and 1375(R4). These 4 request will also be hashed and mapped on the circular hash ring.

The diagram shows how each server and request is mapped to the hash ring. The idea here is that each request here will be served by the nearest server to the right of it. Like R1 will be served by S1, R2 by S2, like this. Now as the requests and servers are hashed uniformly over the hash ring so the distribution of traffic will also be uniform.

Now if we add a new server here with a server ID 1080, it will hash to the position 1080%100 = 80 in the hash ring. The hash ring after adding this server will look like this:

Here unlike normal hashing, all the requests are not being re-mapped to different servers. The requests R1,R2 and R3 will be still be processed by the same server. Only R4 will now be served by S5 instead of S4. In the case of normal hashing, whenever a new server was added then each request was re-mapped to different servers and as a result, every useful information stored on local cache of servers was lost. Here that is reduced as only one server is being re-mapped. So, consistent hashing is more efficient.

One drawback of consistent hashing is that choosing an improper hash function might result in a skewed distribution of the servers over the hash map and that results in a particular server handling more load as compared to other servers. But still, with large no. of servers and a relatively large search space, consistent hashing is way more efficient than normal hashing.

Hope this article has given enough idea on Load Balancing and how normal hashing and consistent hashing works. Do mention in the comments your views on this article or any suggestions for improvement. Stay Safe and Happy coding!

Version Control - Basics

2020-06-24T22:18:00.000+05:30

What is Version Control?

Version Control can be described as a system that helps us to manage the changes that are made to files over time, including code, binary or digital files. It helps by recording and keeping a track of the modifications done to a file or to a set of files so that at a later point of time we can recall a specific version of the files(s) if required.

Another benefit of using a version control system is that it makes collaboration among software engineers working on a particular project easy and also provides some insights on what everyone is doing on the project. In this article, we will understand version control in detail and for that we will be talking about Git and GitHub.

Git is a distributed version-control system that tracks the changes of file(s), whereas GitHub is a cloud-based hosting service that is built around the Git tool.

Remote Repository vs Local Repository:

Suppose you are part of a team whose task is to build a chat app. Now your responsibility is to set up the working repository. So for that, you create a folder in your local system. After creating the folder, it has to be initialized as a git repository using the command git init . After this, the project folder residing in your system becomes a local git repository. Then you add your initial project files and commit those changes locally. Now for the whole team to contribute, your local repository has to be available somewhere on the cloud. This is where GitHub comes into the picture. A repository, ideally with the same name as your local folder, needs to be created on GitHub. Now using the URL of this repository you can push the contents of your local repository to the one on GitHub. So this becomes the remote repository. Now other members can clone this repository on GitHub and all the initial project setup will be available to them.

Create a folder for the project in your system. Then initialize it using git init. It becomes the local repository

Now go to github.com and create a repository with the same name. This becomes the remote repository

Now using the url of the remote repository, connect your local repository to the remote one

Now after adding your code files, when you push your code it gets pushed all the way back to the remote repo

3 Areas of a Git Repository:

Inside a Git repository we have three logical areas in which we work with our files - The Working Tree, The Staging Area and The Git History.

The working tree is what we see in our local system, where we add, edit or delete files
When we make changes to our files, Git gives us the full freedom to choose which files to add/include in the next commit. After adding a file using the git add command it goes into the staging area
The Git History may be defined as a hierarchical structure, which contains a list of all the commits done on that repository over time.

Git Branching:

Branches allow us to work on the same file in parallel. When we initialize a repository there is a basic branch by default which is the master branch. Now when we create a branch, a different copy of the whole working tree is created. Like suppose we create a branch named chat-room from the branch master, then in the newly created branch we will have the exact copy of all the files that were in master. We can add, edit or delete files in this branch independently. This will not affect the master branch. The branching feature is used by developers who are working on the same project but on different features. From the main branch, different feature branches can be created where different developers can work independently. When a branch is stable and tested then that branch can be merged with the main branch.

The command git branch <branch-name> is used to create a branch. Then we can go to that branch using git checkout <branch-name> . For merging, generally a pull request is required to be raised in the remote repository, i.e on Github and a reviewer will review your changes and merge the branch with the main branch, or for a local merge we can just go back to the main branch and use git merge <branch_name>

Create and checkout to a new branch. After adding /editing files commit and push the contents of this branch

When we push the code, in the remote repository the new branch gets created

To merge with the master, checkout to master and merge the branch using git merge command.

Git Logs:

All the commits made in a repository can be viewed using the git log command. Each of the commits has a unique hash value. Using that unique value we can restore back our files at that particular commit. We can move to a particular commit using the command git checkout <commit_hash> .

The git log command gives list of all commits and the unique hash value, using which we can checkout to that commit.

Hope after reading this article you get a basic idea of what version controlling is and also some understanding of git. There are more advanced stuffs related to version controlling and Git which I will be posting in my upcoming articles. Do comment out your views on version controlling. Stay Safe and Happy Coding!

Backend Engineering

2020-06-17T13:06:00.001+05:30

What is Backend Engineering?

Suppose you open Facebook and enter your username and password then click login. You get back a page showing data that is personalized for you. Or suppose you open your Amazon app and typed a particular product name and then you get all the products listed with an image and description. So all the stuff that happens behind the scenes after you click the login or search button till you get back the requested data is what we call as the backend. So, backend engineering deals with creating the most effective and efficient solution to fetch data and return formatted data to the frontend, which can be a web page or a mobile application.

In this article, we are going to talk in-depth about Backend Engineering, like what is it exactly, what things a backend engineer is specifically required to do and in the end, we will see some statistics on backend engineering like percentage of developers choosing backend engineering, the average salary of a backend engineer, etc.

Backend Engineering is about developing API endpoints along with that handling databases, designing database schema and also handling integration of third-party services

The tasks involved in backend engineering are:

API Design/Development
Database Design
Third-party Service Integration
DevOps Tasks

API Design/Development:

API design/development is the main task of a backend engineer. What is an API and how does it work? All these I explained in one of my previous blogs.

API Design is what needs to be done before the development begins. API design is very much related to the overall user-experience of the application. It involves the type of endpoints that are being exposed, the parameters the APIs will accept from the frontend and the structure of the data that the APIs will return in response. All these things impact the overall application that is being developed.

API Development is basically writing the code to implement the business logic in accordance with the API designs that were primarily finalized. API development deals with querying database for the data, manipulating the data, integrating security features like authentication and authorization, etc.

Database Design:

Another essential task involved in backend engineering is database designing. It includes picking the type of Database, i.e RDMS/NoSQL/Graph DB for the application, defining the schema of the entities that are going to be stored in the database and other tasks like how much normalized the relations will be and what constraints will be there. Proper database design is essential because without it data fetching and insertion operations become more complex.

Third-party Service Integration:

While developing the backend for an application, most of the time it is required to integrate many third-party services like caching, queuing, authentication services, etc. So all of these require reading a lot of documentation, understanding the code and the guidelines. For example, integrating a Caching service to reduce the network traffic or integrating an OAuth service like Google/Facebook for user authentication are some third-party services that are commonly used.

DevOps Tasks:

DevOps tasks involve deploying code to cloud instances, creating pipelines for Continuous Integration and Continuous Deployment and many more things related to handling server configurations and environment be it test or production. Well, this is not the entire responsibility of a backend engineer. Some organizations have a separate DevOps team to handle these tasks while in some organizations these tasks are handled by backend engineers.

According to Stack-overflow Developer Survey, most of the developers (around 55.2%) are pursuing a career in backend engineering. As per indeed.com the average salary of a backend engineer is $128k in the US and in India, it is around ₹ 400k. Coming to backend technologies, NodeJs is mostly being used now-a-days. Python and Ruby on Rails are also in demand. Coming to databases, MySQL and PostgreSQL are widely used as RDBMS and MongoDB as NoSQL.

If you are someone who doesn't like anything related to UX or UI development and instead like orchestrating behind the scenes of an application then backend engineering might be suitable for you.

If you are thinking of getting into backend engineering, hope this article has given you enough insights about it. If you are already into backend engineering, do comment out your views on it. Stay Safe and Happy Coding!

Monolithic Vs Microservices Architecture

2020-06-11T15:00:00.002+05:30

A topic that is profoundly discussed in software engineering or system design domain is whether to choose a Monolithic or a Microservice architecture while developing and deploying a server-side application.

In this article, we are going to discuss in detail about Monolithic and Microservice architecture, advantages and disadvantages of each and in the end will see which architecture to choose based on the system's requirements.

Monolithic Architecture:

Generally, when we develop a server-side application we do it as a layered architecture which contains the following layers:

The presentation layer in which HTTP requests are handled and responds with data as JSON/XML
The business layer where the application's business logic is written
The third-party layer, which contains the code to handle third-party services like caching, queuing
The Database Access layer, which is responsible for performing read/write/delete operations on the database

Despite having a layered architecture, while deploying all the code is packed together and deployed as a single-tier application. This is what a Monolithic Architecture is.

Advantages of using Monolithic Architecture:

It is simple to develop. Time and Resource required for a monolithic architecture is comparatively less
Deployments are easy when we are using monolithic architecture, we just have to pack our codebase together and copy it to the server
As all the services are on the same server so problems of network latency and security are less

Disadvantages of using Monolithic Architecture:

For any new developer, it is difficult because he/she has to understand the functionality of the whole application, even if his/her work is related to a particular functionality
The whole application has to be redeployed on each update
Reliability is an issue here. A bug in a certain feature of the application can bring down the whole application
If a single part/feature of the application is getting high traffic, then we need to scale up the whole application. This is inefficient and might lead to unnecessary allocation of resources
Adapting to a new technology is difficult as because the whole application might get affected due to it

Microservice Architecture:

In a microservice architecture, the idea is to split the whole application into a number of smaller services instead of building a single monolith application. These smaller services are called microservices. Each microservice is a small-application on its own having all the layers, i.e presentation layer, business layer, third-party layer and data-access layer and is deployed separately. These microservices communicate with each other via RPC or any message-based API.

In a Microservice architecture, instead of having a single database each service can have its own database. Although it might result in duplication of data but having a database per schema is needed if we want to benefit from microservice architecture. Another advantage of this is that a microservice can use the type of database that best suits its needs.

Have a look at the diagram below:

Here, an application is divided into four microservices - User Profile, Chat Service, Payment Service and Analytics. The Analytics and Payment services have a database of their own and the Chat and User Profile services are using a shared database. Each of the microservices communicates with each other as per requirement. The clients access the microservices via an intermediary known as the API Gateway which is responsible for handling tasks like load balancing, caching, monitoring, etc.

Advantages of using Microservice Architecture:

If we update any particular service, only that service needs to be redeployed instead of the whole application
For a new developer, it is easy because here he/she has to focus only on the particular service in which he/she will work. The working knowledge of the whole application is not necessary
Microservices are fault-tolerant. If any particular service is down then also the other services continue to function
Every microservice can be developed using technologies that best suits its needs. Like Analytics service can be built using Python and the Payment service can be built using Java
In a microservice architecture, the services can be scaled independently. If any particular service is receiving high traffic, only that particular service needs to be scaled up

Disadvantages of using Monolithic Architecture:

As the no. of microservices increases the system becomes more complex. So, it becomes difficult to handle than a simple monolith application
In terms of network usage, it is costly as because each service continuously communicates with each other over the network via RPC
As there are inter-service communications, microservices are comparatively less secure than monolith applications
Debugging in microservice applications is kind of challenging as because the flow of control may be over multiple services and it is difficult to find where the error actually occurred

When to choose what?

A Monolithic Application is best suited for applications that are simple and lightweight. If it has only a few functionalities and there is not much prospect of the application evolving then using microservices might be overhead. Also when the development team is small and cohesive it is better to go with monolithic architecture. On the other hand, if the application is an evolving application with lots of features and functionalities then Microservice architecture will help. When the team is large and diverse, then also adopting to microservice architecture is a good option.

So, I hope after reading this article you can now understand the difference between monolithic and microservice architecture. We saw with detailed examples of how these two work and the advantages and disadvantages of each. Also, in the end, we discussed the scenarios about where to choose monolith and where to choose microservices. Do mention your thoughts and views in the comments. Stay safe and Happy Coding!

A Beginner's Guide to Competitive Coding

2020-06-05T13:01:00.001+05:30

Want to start competitive coding? But not exactly sure where to start and how to progress?
In this article, I will share some information and tips to help you get started with competitive coding. I have been into competitive coding for around 5 years now, have participated and ranked in many competitive coding contents like TCS Codevita, ACM ICPC, etc. The things I am going to share are mostly from my experience, which also includes some valuable tips which I have gained from other professional coders.

Why to engage in competitive coding?

Competitive Coding is basically a mind sport where one needs to quickly implement solutions for some math puzzles or some task problems. You get a problem statement, you read that and then logically think of a way to solve the problem and then implement that logic by writing some lines of code. This helps you to develop your problem-solving skills and also increases your thinking capability. If you are into Competitive Coding it will surely help you in your career whether you are a Software Developer, Data Scientist or, a Network Security Engineer. Most companies hiring freshers from campus placements have a round where they test the student's coding skills, also for top product-based companies one has to go through an initial round of competitive coding.

Data-structure and Algorithms, why they are important?

Well, if you want to excel in Competitive Coding then a proper understanding of Data-structure and Algorithms are must. Time constraint is an important factor while solving coding problems. By using a proper data-structure and implementing the best algorithm you can bring down the time complexity value of your solution(if you are not aware about time complexity, you can read about it here). Lets see an example of this.

Suppose we have a problem statement like this:

We are given an array and a target number. We need to find two numbers in the array that sum up to the target number provided.

Example:
Array: [1, 2, 3, 4, 5, 6, 7, 8, 9, 15] , target-number: 18

Output: [3,15]

Solution 1:

def getTwoValue(arr,targetSum):
    length = len(arr)
    for i in range(0,length-1):
        for j in range(i+1,length):
            if(arr[i]+arr[j]==targetSum):
                return [arr[i], arr[j]]
##driver main
if __name__ == '__main__':
    arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 15]
    targetSum = 18
    result = getTwoValue(arr, targetSum)
    print(result)

Here we can see in the getTwoValue() function one for-loop is running inside another for-loop. This will result in a time-complexity of O(n^{^}2).

Solution 2:

from collections import defaultdict 
def getTwoValue(array, targetSum):
    length = len(array)
    tempDict = defaultdict(lambda: False)
    for i in range(0,length):
	tempDict[array[i]]=True
    for i in range(0,length):
	remain = targetSum - array[i]
	if(tempDict[remain]==True and remain != array[i]):
		if(array[i]<remain):
		  return [array[i],remain]
		else:
		  return [remain,array[i]]
     return []
##driver main
if __name__ == '__main__':
    arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 15]
    targetSum = 18
    result = getTwoValue(arr, targetSum)
    print(result)

Here we can see in the getTwoValue() function we are using a hash-map. the variable tempDict is the hash-map being used here. Here, we can see there are two for-loops but they are independent of each other, i.e not nested inside one another, so as a result time-complexity here is O(n).

So, here we saw how using a proper Data Structure and implementing a different algorithm we reduced the time complexity of the problem from O(n^2) to O(n). So before just diving into competitive coding gain some knowledge on Data-Structures and Algorithm, it will surely help.

Which programming language should be used?

Generally, if your concepts are clear, language doesn't matter for competitive coding. Most of the competitive coding platforms allows you to write code in any programming language you want. So, language is not a bottleneck.

Still many developers prefer languages which has a simple syntax and concepts like OOP can be implemented easily. Based on survey results from top coding platforms the top 3 languages used for competitive coding were C++, Java and Python.

Platforms where one can practice competitive coding:

I will mention top 5 platforms which are mostly used my competitive coders:

The information shared here in this article, I feel is enough to get you started with competitive coding. If you still haven't started it, do ASAP. It is fun and you will surely enjoy it. Stay safe and happy coding!!

SOAP vs REST vs GraphQL : A Detailed Comparison

2020-06-03T18:32:00.000+05:30

SOAP vs REST has been quite an issue for some time now. And now with Graphql gaining popularity, people have started to converse about REST vs GraphQL. In this article, we will do a comparison of SOAP vs REST and REST vs GraphQL. We will see the advantages and disadvantages of all three and when to choose what.

SOAP vs REST

About SOAP:

SOAP stands for Simple Object Access Protocol. It is basically a messaging protocol that was developed by Microsoft. It relies on XML heavily and defines a very strongly typed messaging framework. It is used for data exchange in a distributed environment. SOAP works with any of the application-level protocols like HTTP, TCP, SMTP, etc. The data which is returned is always in XML format. The structure of the XML of the request and response are explicitly defined. All of the SOAP specifications and definitions are developed and maintained by W3C (World Wide Web Consortium). SOAP has strict rules and built-in comprehensive features in the form of security, transactions, and ACID (Atomicity, Consistency, Isolation ad Durability). For all these the complexity is higher and it requires more bandwidth and resources for processing.

This is the XML structure of a SOAP response message from w3.org.

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
 <env:Header>
  <n:alertcontrol xmlns:n="http://example.org/alertcontrol">
   <n:priority>1</n:priority>
   <n:expires>2001-06-22T14:00:00-05:00</n:expires>
  </n:alertcontrol>
 </env:Header>
 <env:Body>
  <m:alert xmlns:m="http://example.org/alert">
   <m:msg>Pick up Mary at school at 2pm</m:msg>
  </m:alert>
 </env:Body>
</env:Envelope>

Envelop: It is the starting and ending tag of the whole message
Header: It contains optional attributes, like meta-data, expiration date,etc.
Body: It contains the actual response data that is to be sent

Advantages:

SOAP has built-in security and error handling
Successful/Retry logic for message functionality
SOAP is transport-independent (can work with HTTP or TCP or UDP or SMTP)
SOAP has built-in ACID compliance

Disadvantages:

SOAP relies mainly on XML. XML parsing is a heavy operation
It consumes more bandwidth and requires more computing power.

About REST:

REST stands for Representational State Transfer. Unlike SOAP, REST is an architectural style to design APIs. We discussed the details of REST Architectural Constraints on our previous article. We can say REST is a light-weight alternative to SOAP. Developers found SOAP to be inconvenient in some scenarios. Like, suppose someone writing code in JavaScript has to write lots of extra code to do a simple task because it is always required to create the standard XML structure. REST APIs are based on URI (Uniform Resource Identifier) and can use any data format like JSON, XML, TXT, etc., although JSON is most commonly used. REST APIs are simple and easy to scale. REST does not provide any built-in security or error handling. All these things have to be implemented additionally as per requirement by the developer. The objective of REST is to make data available as a resource by making API calls that use the well-known HTTP verbs like GET, POST, PUT, DELETE, etc.

Below is a sample REST API response. This is one of Github's public API

Advantages:

REST is light-weight, flexible and scalable
REST supports all data types be it XML, JSON or TXT
REST APIs use a single uniform interface
In terms of design, REST is much closer to other web technologies

Disadvantages:

REST does not have any in-built features for security and error handling
REST is not suitable for distributed environments

	SOAP	REST
Design	It is a standardized protocol with well-defined rules	It is an architectural style with certain constraints
Functionality	Function-driven (Data available through functional services)	Data-Driven (Data available as a resource)
Data Format	XML	XML, JSON, TXT, etc.
Caching	Cannot be cached	Caching available
Security	It has WS-Security with SSL support	SSL support and HTTPS
Performance	Requires more bandwidth and resources	It is lightweight and requires fewer resources
Transfer Protocol(s)	HTTP, TCP, UDP or SMTP	HTTP
ACID Compliance	Has in-built ACID Compliance	Does not have ACID compliance

REST Vs GraphQL

In the previous section we discussed about REST in detail, so now lets focus on GraphQL.

About GraphQL:

GraphQL is a relatively new technology that has made a lot of buzz. It is a modern way of developing and querying APIs. GraphQL is developed and maintained by Facebook which made its stable release in 2018. GraphQL was developed to overcome some of the shortcomings of REST.

One thing about REST is that we end up creating multiple endpoints to fetch data that are structurally different but are relatable. Sometimes we end up over-fetching or under-fetching the data. Let us understand this by an example.

Here, we will have a look at GitHub's public API V3.

One end-point is GET /search/users?q=John. This end-point returns us a list of users with a unique username attribute for each user with the name 'John'. Now suppose we want to get the repositories of that user. For that, there is another end-point

 GET /users/:username/repos. So, here we have two different end-points. Also, like for the first end-point we will get all the attributes of that user like name, email, location along with the username. But we were interested in getting only username. So this is kind of over-fetch.

With GraphQL the client is able to fetch all the required information with a single call, rather to make multiple REST requests to fetch the same. While requesting the client can specify the data he wants and GraphQL will return only that data. Also, there is only one end-point. The GraphQL server will first check the data the client has specifically requested for and then query it out accordingly. 
See this example:

{
 query getUserAndRepo{
   getUser(name: "John"){
   username
    repos(){
     id
     title
    }
   }
 }
}

In GraphQL, with such similar query we can get the id and title of repositories of the user named "John". This can be achieved with a single call, also there will be no data over-fetch or under-fetch.

Now, all these doesn't mean that REST will become obsolete and GraphQL will be used everywhere. We should keep in mind that whenever any new technology comes up it too has its own pros and cons.

Advantages:

GraphQL allows us Declarative Data fetching, i.e client can specify the data it needs along with specific entities and attributes
No data over-fetching or under-fetching in GraphQL
GraphQL is a strongly typed query language. Being strongly typed, it is less error prone
GraphQL is version free, the structure of the response data is determined entirely by the clients query. Any change/modification on server code does not affect the structure of the response data

Disadvantages:

A GraphQL query can face performance issues if a client asks for too many fields at once
GraphQL cannot cache response data. To implement caching certain libraries like Apollo-Client are required

	REST	GraphQL
Type	It is an architectural style with certain constraints	It is a specification, which can be implemented by a language
Endpoint	Multiple endpoints for multiple resources	Only a single endpoint
HTTP Methods	GET, POST, PUT and DELETE all can be used	Only POST is used here
Caching	Caching available	Normally not available. Can be made available via libraries on top
Data Fetching	Specific Data on a single API call	Fixed Data with multiple API calls

Where to use what?

The answer to this question is based on what use-case do you have. All SOAP , REST and GraphQL have its pros and cons.

SOAP is mostly used for enterprise level application which require high security and complex transactions are involved. API for payment gateways, financial applications, CRM applications, etc. mostly use SOAP.

REST on the other hand provides point to point communication. Most public APIs provided by organizations are REST APIs. When flexibility and scalability is desired then REST API is a good choice.

GraphQL as we mentioned makes querying simpler and helps the client to get the data as per its needs. But GraphQL does not give any significant advantage over REST performance wise, unless the application is executing like a millions of queries per second.

Hope after reading this article you get a clear picture on the difference between SOAP, REST and GraphQL and also get a understanding about the pros and cons of each of them. Do mention your thoughts in the comments. If you like it do subscribe for more articles on software development stuffs. Also, I'd like to grow my readership, if you enjoyed this article, share it with a friend! Stay safe and Happy Coding!

Elon Musk : A biography by Ashlee Vance

2020-05-28T19:33:00.000+05:30

The book 'Elon Musk' is an authorized biography of one of the most interesting and innovative entrepreneurs of our generation.

This book gives the interesting and inspiring story of Musk's life, from his childhood to the part where he spent significant time in Zip2 and Paypal and then onto Tesla, SpaceX, and Solar City. The author, Ashlee Vance, an American business columnist and author had to put up quite an effort and time to gather all the content that is presented in this book. He interviewed mostly employees of SpaceX and Tesla, also Elon's mother, and at the end Elon himself. The first edition of the book was published in May 2015.

The book takes us back to his days in South Africa. Born in 1971, he grew up in Pretoria. From childhood itself, young Elon had a keen interest in technology and used to fantasize about Space and battles between Evil and Good. He was into it so much that at the age of 12 he developed a game called Blaster on his own. The game's objective was to fight and destroy an alien space freighter with bombs and beam machines. In 1984, the public first met Elon Musk, courtesy of this video game, when a South African Trade publication published the source code of the game. The book tells us in detail about Maye Musk, his mother and his father Errol Musk, and gives a brief family history of both of them. It takes us through Elon's childhood in Africa about his High School experiences and growing up with his brother Kimbal Musk. After this at the age of seventeen, Elon left South Africa for Canada.

While reading you will get to know why this escape to Canada was not a well-thought plan for Elon. He had a long Canadian ancestry from his mother's side. His mother had family all across Canada. As the book progresses we get to know how Elon ended up with one of his cousins and how he took up different kinds of jobs for survival. Elon then ended up rolling at Queen's University in Kingston. During this time his brother Kimbal also went to Canada. Elon after two years Queen's University went to the University of Pennsylvania. He went in the pursuit of a dual degree, an economics degree from Wharton School, and then a bachelor's degree in Physics from the University of Pennsylvania. As the book progress, you will see how always had a desire to do something that would have an effect on the world. At each and every step and action mentioned in the book, you will get to know the vision that Elon Musk always had. At a point in time, Elon considered getting into video game business but later backed off because he thought by getting into video games would not help him to create a big effect on the world.

The book then guides us to Elon's first startup, Zip2, which was founded by him and Kimbal. Zip2 was basically a searchable directory of businesses plotted on a digital map. The story behind Zip2 coming into existence is a pretty interesting one that the books present to us in a pleasant format. For the initial phase, they borrowed $28k from their father. They worked day and night to make Zip2 a success. Musk did the original coding behind the service and Kimbal managed the sales operation. Over the years Zip2 achieved remarkable success. In 1999, the PC maker company acquired Zip2 for an amount of $307 million. Musk made $22m from the sale of Zip2. With that Musk founded X.com in March 1999, which was an online financial services and e-mail payment company. After a year X.com merged with Confinity and the merger was renamed to PayPal in 2001. Elon had an interesting journey while being the CEO of PayPal. But due to disagreements with other company executives Musk was removed from the CEO position, but he remained on board. Later PayPal was acquired by eBay for $1.5b and Musk made $165m from the deal.

After this, the book presents to us Elon's journey in building SpaceX. In 2001 Elon took up a project called Mars Oasis, whose purpose was growing food crops on Martian regolith. For that, he contacted Russian Companies to buy rockets. After many dealings, a Russian Company offered one rocket for $8m. Elon thought it was too much and called off the deal. Then an idea stuck, he could start a company that could build the affordable rockets he needed. With $100m from his early ventures, Elon founded SpaceX in May 2002. Elon believed the key to making space travel affordable was to make rockets reusable. As you read you will get to know the dedication and hard work he put in order to make his vision a reality. After many failed attempts to launch their first rocket, Falcon 1, SpaceX made its successful launch at its fifth try. After that SpaceX launched its Falcon 9 rocket and Dragon, its first spacecraft

After this, the book leads us to Elon's next big venture Tesla. Unlike SpaceX, Elon was not the founder of Tesla. Originally Tesla Motors was started in July 2003 by Martin Eberhard and Marc Tarpenning. Elon lead Series A round of investment in Tesla and joined Tesla's board of directors. After a few issues and a financial crisis, Eberhard, the then CEO had to leave the company after that Elon assumed the role of CEO in 2008. Elon's plan was to make money by first building and selling an electric sports car and then use that money to build affordable cars. The book takes you through the whole development journey of Tesla's first sports car, the Tesla Roadster in 2008. After that Tesla bought its four-door Model S sedan into the Market in 2012. In a few years, the sale of Tesla increased so much that they decided to open up a network of supercharger stations all across the US. While reading through this part of the book, you get to see how Elon managed his time being CEO of two giant companies. Tesla's innovation was on a different level. They kept on adding/upgrading features to its cars be it a functional feature or a more advanced technical feature, and one of the main things that kept Tesla going was Elon's vision and determination.

We have seen many global entrepreneurs and industrialists, but none like Elon Musk have touched upon multiple domains and have achieved success in all. Personally, what I like most about Elon Musk is his never give up attitude, if he figures out something is possible he doesn't let go until that is achieved. The author did a great job in bringing out this inspirational story of Elon Musk and also has touched upon his personal life too. This book is a must-read for those who are into the early stages of entrepreneurship. Also, if anyone wants to know the man behind Tesla, SpaceX and SolarCity this book is the best resource for you. My main take away from the book can be expressed by the following quote by Elon himself.

Failure is an option here. If things are not failing, then you are not innovating enough.
- Elon Musk

Do give this book a read and mention how was your experience. Anyone who has already read this, comment out your views as well. Till then, Happy Reading!!

RESTful API - Architectural Constraints

2020-05-24T10:51:00.001+05:30

In my last article, I wrote about the basics of REST API. Like what is a RESTful API and reasons behind naming it so. If you have missed that, check it out here. I mentioned the following line in my last post:

REST is not any standard or technology rather it is an architectural style for developing API based on a standard set of principles.

So in this article, let's see what are those architectural constraints and principles that make an API RESTful.

There are 6 design principles, also known as REST Architectural constraints. These principles were described by Roy Fielding in his dissertation paper, which was published in 2000.

These following 6 architectural constraints makes any API service RESTful:

Uniform Interface
Client-Server
Statelessness
Caching
Layered System
Code on Demand

Uniform Interface

Here interface refers to a contract for communication between the API provider and the consumer. The API provider and consumer here share a common technical interface, which is well-defined using HTTP methods and media types.
This interface states that inside the system there are resources and to get the state of a resource or to manipulate it there has to be an URL that the consumer can use.
On the server-side data is stored in the database and there is some sort of database representation. Whereas on the consumer/client-side data may be required in formats like JSON, XML, TXT, etc., which may be different from the way data is stored in the database. So, the idea here is that there must be specific guidelines for resource representation.
Also, there have to be some self-descriptive messages, known as metadata. This metadata helps both the producer and consumer to process the information in the request or response object. This metadata is transferred via HTTP headers. Like Content-Type which tells about the data format(JSON/XML,etc.), HTTP status code which tells the status of the request like 200 for Success, 404 for Not Found, also Host which indicates the IP of the server.
The last thing about this is the Hypermedia, which states that the server not only sends response data but also sends the possible actions, which the client can take on the data, whenever required. This is also referred to as HATEOAS (Hypermedia as the Engine of Application State)

Client-Server

The Client-Server architecture states that we have a client and a server working independently. The client connects to the server via a uniform interface. The client and server must not reside in the same process. All communication between them must happen via RPC over HTTP. This the architecture ensures that client application and the server must be able to evolve separately without any dependency on one another, as long as the uniform interface is not altered.

Statelessness
Statelessness means that the server will not store any information regarding the latest request made by the client. There will be no sessions and no histories. Every client request will be treated as a new request.
If the end-user wants a stateful application, then the client application needs to manage the state of the application. Like, if the user wants an application where the user logs in and performs actions which are authorized to that user only, then in each request made by the client should contain all the necessary the information which is needed by the server to process the request, like authentication tokens, authorization details, etc.

Caching

Caching is the ability to store copies of frequently accessed data in several places along with the request-response path.
In terms of REST APIs, caching is storing the response of APIs in an in-memory or distributed system, so that response can be fetched from the stored system within a short amount of time. Caching can improve performance and achieve higher scalability on the server-side.
The architectural constraint for caching states that the server should mark the responses as cacheable or non-cacheable. It can be achieved by the server using HTTP headers.
- Cache-Control: With this header, the server defines the policy for the cache. Like who can cache the data, for how long data can be cached, etc.
- Expires: This tells the client when the cached resource will get expired
- Last-Modified: With this header, the server tells the client when a resource in the cache was last modified
- ETag: This is a unique identifier associated with a resource. It can be any unique id or name
Layered System

This architectural constraint states that the client-server architecture should consist of multiple layers. No one layer should be able to see past its immediate next layer. One thing not allowed is that the client is directly connected to the app server. One thing that is required here is that the client must not connect directly to an App server because if this happens then the client has to carry out request/load distribution, which is not desirable.
The benefits of layering are that it simplifies the architecture and hides the complexity of the various layers and also, the architecture can easily change as per needs by adding or removing any layer.
Code on Demand (Optional)
This is an optional constraint. This constraint states that the server can extend the client's functionality by sending executable code along with the data in response. Some examples of code on demand are Java Applets, JavaScript snippets, etc.

All the above constraints (except point 6) must be followed to build a truly RESTful API.
These are the basic concepts that a developer should have knowledge of before indulging in advanced REST API development. Next up I will be sharing an article on hands-on development of a REST API and also deploying it to a cloud server.
So do subscribe. Also, I’d like to grow my readership, If you enjoyed this blog post, share it with a friend! Stay safe and Happy Coding!

RESTful API Services - The Basics

2020-05-13T19:01:00.000+05:30

Most of you, especially those who have a keen interest in web development, have come across the term "REST API".
Overall it serves the purpose of fetching data from a source on the internet and we use that data in building our own applications. But there is certainly more to that.

In this article, I will try to cover some of the basics of REST APIS, like what is a REST API and why it is called so, formats in which data transfer happens, and in the end, we will do an anatomy of a full REST API Request.

So, let's get started

First and foremost, "What is an API?"

Well, to put it in simple terms an API (Application Programming Interface) is like a user-interface to raw data and it is for the use of applications rather than for the use of humans. Also, there exists a well-defined agreement between the API producer and consumer, like in which format data will be exchanged between the parties, some authorization tokens/cookies in the request header, etc.

Now REST stands for Representational State Transfer. To understand what do we mean by a representational state, let's touch upon the concepts of entity and attributes of DBMS. An entity, as we know, is a real-world object, and attributes are the properties that define the entity. Like a car is an entity having attributes like manufacturer, color, model no., etc as it's attributes. In other words this model no., manufacturer, color, etc. uniquely represents a car, so we say all these attributes together form the representational state of the car.

Have a look at this image below:

Here, we have an entity Book. Its attributes are ISBN, title, edition, category, and author. So together these attributes form the representational state of each book. Now suppose we have an API in which we request with an ISBN and get back the details of the book, i.e. the current representational state of the book. What the API does here it takes the ISBN, queries the database with that ISBN and returns the representational state of the book that matches the ISBN. So, the API is a REST API as it transfers the representational state of the book from the database to the client.

Another aspect here is about the format of the data being transferred through a REST API. Well, REST API doesn't have any standard data format. A REST API is supposed to accept data in any format and send back the response in any format. Generally, a REST API has two parts to it, one it queries the database and gets the data row(s), and then there is a logical part that forms the response data in a specific format like JSON, XML or Text format.

Now let's look at an actual REST API

GET https://maps.googleapis.com/maps/api/place/textsearch/json?query=restaurants+in+Sydney&key=AB123z

This is an API provided by Google Maps Platform. Here 'GET' represents the HTTP Method. There are no. of HTTP Request Methods to indicate the desired action. We can learn more about HTTP Request Methods here.
The anatomy of the API is as follows:

Root Endpoint: Here https://maps.googleapis.com/ is the root endpoint. For a particular API provider, the root endpoint is the same.
Path: After the root endpoint, maps/api/place/textsearch/json part is the API path. The path will be different for different APIs by a particular provider. One thing to note here is the /json is a path variable. In this API, this particular variable denotes the data format in which the response will be returned. We can put /xml here to get the response back in XML format.
Parameters: The part query=restaurants+in+Sydney&key=AB123z are the query parameters. These are in key-value pairs. Apart from query parameters, there can be body parameters that are sent in the request body.

One thing to remember about REST API is:

REST is not any standard or technology rather it is an architectural style for developing API based on a standard set of principles.

These things will help us to get a basic understanding of REST APIs. Although, there are many other things related to it, like architectural constraints, API security, and API Management. In the next article, I will be sharing REST API principles and architectural constraints, so do subscribe. Till then, Stay Safe and Happy Coding!

3 books which can help you develop your personality during this lockdown period!

2020-05-02T00:31:00.000+05:30

Are you an avid reader?
If yes, then I am sure in this quarantine period you are making most of your book reading habit.

Well, I also have been reading lots of books recently. Mostly books on personality development and along with that biographies and autobiographies of some famous and successful people.
Many people ask me why do I prefer reading mostly all these non-fiction books and not novels and fiction books. Well, to be honest, I also read novels too, but less. Reading any kind of book always adds values and is a good form of recreation too.

I prefer books related to personal development because it helps me grow. It creates a different mindset. Different books contain articles that will touch different areas of life and add values in that area. And reading biographies/autobiographies of successful people helps us to relate to situations in our life. We all have heard the saying "Learn from your mistakes", but what I feel is we can learn from the mistakes many of these successful people did and how did they overcome it.

Recently I have completed the following three books. I found all these books of great value. I will briefly share details about each of them:

THE MAGIC OF THINKING BIG

This book is written by David Schwartz is the best out there which helps us to understand our true potential. The author is a Ph.D. from Georgia State University and is a renowned life strategist. Once you have read the book you will be filled with positivity. There are many chapters in this book, each chapter touches upon a point where negativity can bring us down and how positive thinking can help us to come out of it. There are case studies and real-life examples by which the author helps us to defeat disbelief and the negative power it creates. It helps in effective decision making and will help build leadership qualities too. One must give this book a read if he/she wants to capitalize on the power of positivity.

THINK AND GROW RICH

Think and Grow Rich, written by Napolean Hill is probably the most famous success book of all time. Napoleon Hill was an American self-help author who wrote about essentials to improve one's life. The inferred conclusion from the book is riches begin with a state of mind. If we want to get rich, we must first change our minds so that we become, as Napoleon Hill calls it, money-conscious. Quoting a line from the book

Success comes to those who become success conscious. Failure comes to those who indifferently allow themselves to become failure conscious.
This line is self-explanatory and itself speaks so much. The book deals with various aspects like having a burning desire to achieve a goal, having faith in yourself, and how to achieve the goal by organized planning. Give it a read if you have a goal set and working to achieve it, this book can surely help.
HIT REFRESH

Hit Refresh is an auto-biography by Microsoft's current CEO Satya Nadella. In this book, he shares his life's journey from Hyderabad to Redmond to join Microsoft and become its third CEO. This book is quite different from the previous two books. It states how Mr. Satya Nadella dealt with certain situations in his life while leading such a tech giant like Microsoft. Apart from these, the book throws light on how technologies like quantum computing, mixed reality, and artificial intelligence and shape our future. Also, in the book Mr. Nadella about trust values in the digital age like what norms and policies should be there regarding data security and privacy. If anyone wants a view on how technological impact will be in the near future along with that want to gain some leadership values then this book will be a good choice.

If you have read any one of these books, do mention your thoughts and understandings in the comments, and also if you have any suggestions for some good read mention that as well. Stay safe and happy reading!

ReadsNGeeks : Get latest articles on Software Development and Coding Best Practices

NodeJS Application with Docker

All about Docker - Beginner's Insight

Creating and Publishing an NPM package

API Security - Securing API with Tokens and JWT

API Caching - Reducing Network Calls

5 Topics For a NodeJS Interview

System Design - Load Balancing

Version Control - Basics

Backend Engineering

Monolithic Vs Microservices Architecture

A Beginner's Guide to Competitive Coding

SOAP vs REST vs GraphQL : A Detailed Comparison

SOAP vs REST

About REST:

REST Vs GraphQL

Where to use what?

Elon Musk : A biography by Ashlee Vance

RESTful API - Architectural Constraints

Uniform Interface

Client-Server

Statelessness

Caching

Layered System

Code on Demand (Optional)

RESTful API Services - The Basics

First and foremost, "What is an API?"

GET https://maps.googleapis.com/maps/api/place/textsearch/json?query=restaurants+in+Sydney&key=AB123z

3 books which can help you develop your personality during this lockdown period!

THE MAGIC OF THINKING BIG

THINK AND GROW RICH

HIT REFRESH