What is tfsec?

Tfsec is an open-source static analysis tool developed specifically for Terraform. Its main objective is to scan your Terraform code and identify potential security risks and misconfigurations in your codebase. By running tfsec against your Terraform files, you can proactively detect vulnerabilities, ensuring that your infrastructure is built on a solid foundation of security best practices.

Example Scenario: Creating an AWS S3 Bucket

Let's consider a simple example of creating an AWS S3 bucket using Terraform. Below is the Terraform configuration for our S3 bucket:

provider "aws" {
  region = "us-west-2"
}

resource "aws_s3_bucket" "example_bucket" {
  bucket = "example-bucket"
  acl    = "private"

  tags = {
    Name        = "Example Bucket"
    Environment = "Production"
  }
}

In this example, we are creating an S3 bucket named example-bucket in the us-west-2 AWS region. The bucket is set to private access, additionally, we've added some tags to the bucket.

Running tfsec

Before running tfsec, ensure you have Terraform and tfsec installed on your machine. Once everything is set up, open your terminal and navigate to the directory containing the Terraform configuration.

Now, run the following command to analyze the Terraform file with tfsec:

tfsec example_bucket.tf

Tfsec will analyze the configuration and provide a report on potential security issues. In our example, tfsec would give us an output similar to the following:

WARNING: S3 bucket has an ACL defined which allows public read access.
  File: example_bucket.tf:6

WARNING: S3 bucket has no server-side encryption defined.
  File: example_bucket.tf:6

Interpreting the tfsec Results

From the tfsec output, we can see that it has identified two security issues in our Terraform configuration:

1. Public Read Access: The S3 bucket is configured with an "acl" attribute set to "private," but tfsec is warning us that the configuration still allows public read access.

2. Lack of Server-Side Encryption: The S3 bucket does not have server-side encryption (SSE) enabled, which poses a potential security risk for sensitive data stored in the bucket.

Addressing the findings

Now that we have identified the issues, let's take steps to address them:

1. Resolving Public Read Access:

To restrict public access, we need to update the S3 bucket's configuration to deny public read access explicitly. We can achieve this by adding a "block_public_acls" attribute to the resource block.

Please note that the AWS Terraform Provider version used for the examples below is not the latest. Syntax varies in the latest version, especially, for the S3 resources.

The updated Terraform configuration will look like this:

resource "aws_s3_bucket" "example_bucket" {
  bucket = "example-bucket"
  acl    = "private"

  block_public_acls = true

  tags = {
    Name        = "Example Bucket"
    Environment = "Production"
  }
}

1. Implementing Server-Side Encryption:

To enable server-side encryption, we can set the "server_side_encryption_configuration" attribute within the "aws_s3_bucket" resource block. The updated Terraform configuration will look like this:

resource "aws_s3_bucket" "example_bucket" {
  bucket = "example-bucket"
  acl    = "private"

  block_public_acls = true

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }

  tags = {
    Name        = "Example Bucket"
    Environment = "Production"
  }
}

Just a reminder again that the AWS Terraform Provider version used for the example above is not the latest. Please refer to the provider documentation for the latest updates.

With these changes, we have addressed the security issues identified by tfsec in our Terraform configuration.

Tfsec with Pre-commit Hooks and CI

Integrating tfsec into pre-commit hooks and Continuous Integration (CI) pipelines ensures that security checks are performed automatically at different stages of the development process. Let's go through the steps to integrate tfsec in both scenarios.

Integrating tfsec in Pre-Commit Hooks:

Pre-commit hooks are scripts that run before each commit is made in your version control system. By adding tfsec as a pre-commit hook, you can prevent developers from committing Terraform code that violates security best practices.

Step 1: Install tfsec and Pre-commit

Ensure that tfsec and pre-commit are installed on your local machine. You can install pre-commit using a package manager like pip (for Python projects) or your OS's package manager.

Step 2: Create the Pre-commit Configuration File

In your Terraform project's root directory, create a file named .pre-commit-config.yaml. This file will define the pre-commit hooks and the tools to use for validation.

repos:
  - repo: https://github.com/liamg/tfsec
    rev: <tfsec_version>  # Replace <tfsec_version> with the desired version or use "master" for the latest.

hooks:
  - id: tfsec
    name: tfsec
    stages: [commit]
    types: [terraform]

Step 3: Install Pre-commit Hooks

After creating the .pre-commit-config.yaml file, run the following command to install the pre-commit hooks:

pre-commit install

Now, every time you attempt to make a commit, pre-commit will automatically execute tfsec on your Terraform files, preventing commits with security issues.

1. Integrating tfsec in Continuous Integration (CI) Pipelines:

Incorporating tfsec into your CI pipeline allows you to perform security checks on your Terraform code whenever changes are pushed to the repository. We'll use an example with GitLab CI, but the steps can be adapted for other CI/CD systems.

Step 1: Create .gitlab-ci.yml

In your project's root directory, create a .gitlab-ci.yml file if it doesn't already exist. This file defines the pipeline stages and jobs to be executed in CI.

stages:
  - test

tfsec_scan:
  stage: test
  image: liamg/tfsec:latest  # Use the tfsec Docker image
  script:
    - tfsec  # Run tfsec against Terraform files

Step 2: Push and Trigger CI Pipeline

Commit and push the .gitlab-ci.yml file to your GitLab repository. This will trigger the CI pipeline, and tfsec will be executed to scan your Terraform code for security issues.

You can adapt this example to other CI/CD systems like Jenkins, Travis CI, CircleCI, or GitHub Actions by configuring the CI pipeline to run tfsec using their specific syntax.

Now, every time you attempt to make a commit, pre-commit will automatically execute tfsec on your Terraform files, preventing commits with security issues.

Wrapping Up

Tfsec is an invaluable tool for enhancing the security of your Terraform infrastructure. In our example, we saw how using a simple tool we were able to successfully to detect public read access and the absence of server-side encryption in our S3 bucket configuration before they became significant risks, allowing us to take appropriate corrective measures.

By integrating tfsec in both pre-commit hooks and CI pipelines, you ensure that Terraform code is continuously checked for security issues throughout the development process. Pre-commit hooks prevent insecure code from being committed, while CI pipelines catch security problems early, before changes are merged into the main branch.

By adopting these practices, you can enhance the security of your Terraform infrastructure and prevent security vulnerabilities from slipping into your production environments. Happy Terraforming!

If you liked what you read, do consider sharing the article with a friend and connect with me on Twitter - @afraz_momin. Also, subscribe to my newsletter and stay up-to-date with my latest blog posts.

1. count:

count is a simple yet powerful inbuilt feature in Terraform that allows you to duplicate resources based on a numeric value. It is ideal for scenarios where you know the exact number of resource instances you need to create. For instance, deploying multiple identical EC2 instances for load balancing or autoscaling purposes.

resource "aws_instance" "example" {
  count         = 3
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

In this example, Terraform will create three EC2 instances with the specified AMI and instance type. We can update the count value to any other number to change the number of instances accordingly.

2. for_each:

While count is great for a fixed number of resources, but it falls short when dealing with dynamic or variable-driven infrastructure. Here is when for_each comes into the picture, as it is more flexible and suited for use cases where you need to create resources based on data structures such as maps or sets.

variable "ec2_instances" {
  type = map(object({
    ami           = string
    instance_type = string
  }))
  default = {
    instance1 = {
      ami           = "ami-0c55b159cbfafe1f0"
      instance_type = "t2.micro"
    }
    instance2 = {
      ami           = "ami-0c55b159cbfafe1f0"
      instance_type = "t2.small"
    }
  }
}

resource "aws_instance" "example" {
  for_each = var.ec2_instances

  ami           = each.value.ami
  instance_type = each.value.instance_type
}

In this example, we define a variable ec2_instances as a map of objects containing AMI and instance type details. By using for_each, Terraform creates two EC2 instances based on the data provided in the variable. This way, we can easily add or remove instances by updating the map.

3. When to use what - count or for_each ?

The decision to use count or for_each depends on your infrastructure requirements. If you know the exact number of resources you need, count is a straightforward choice. However, if you want greater flexibility and intend to create resources based on dynamic input, for_each is the way to go.

4. A few points to note:

Keep in mind that while count and for_each are powerful tools, they can have implications on your Terraform state and resource management. Changing the value of count or the keys within a for_each map can lead to resource destruction or recreation. Therefore, it's important to be cautious when modifying these configurations in production environments.

In conclusion, Terraform's for_each and count are essential features for managing repetitive infrastructure effectively. With count, you can easily duplicate resources a fixed number of times, while for_each provides the flexibility to create resources based on dynamic input. With these looping techniques, infrastructure automation becomes a cakewalk, allowing you to focus on building complex but robust infrastructure.

If you liked what you read, do consider sharing the article with a friend and connect with me on Twitter - @afraz_momin. Also, subscribe to my newsletter and stay up-to-date with my latest blog posts.

Traditional Terraform code often involves specifying resource blocks with fixed, static configurations. For example, creating multiple security group rules or IAM policies for different instances can lead to repetitive and lengthy code. Dynamic Blocks help in addressing this challenge as they offer a more clean approach to managing such scenarios.

Dynamic Blocks enable Terraform to create multiple instances of a particular configuration block within a single resource or data block which is dynamically generated based on variables or a collection of elements. This means that instead of repeating the same configuration multiple times, we can loop through a list or map to generate the required blocks automatically.

Syntax :

The syntax for Dynamic Blocks consists of the keyword dynamic, followed by one or more nested for_each or for expressions, and inside it, we define the block type along with its arguments.

Assuming you have already set up your AWS provider configuration, let's start by defining the variables and the listener configuration map in a Terraform file called variables.tf :

variable "elb_name" {
  description = "Name of the Elastic Load Balancer"
  type        = string
}

variable "listener_rules" {
  description = "Map of listener rules for the Elastic Load Balancer"
  type        = map(object({
    protocol           = string
    load_balancer_port = number
    instance_protocol  = string
    instance_port      = number
  }))
}

In this example, listener_rules is a map that can hold multiple listener configurations. Each configuration contains the following attributes:

• protocol: The protocol for the incoming traffic (e.g., HTTP, HTTPS, TCP).

• load_balancer_port: The port on the Elastic Load Balancer that listens for incoming traffic.

• instance_protocol: The protocol to use when forwarding traffic from the load balancer to the backend instances (e.g., HTTP, HTTPS, TCP).

• instance_port: The port on the backend instances that the load balancer forwards traffic to.

Now, let's create the main Terraform configuration file (e.g., main.tf) to provision the ELB using Dynamic Blocks:

provider "aws" {
  region = "us-west-2"  # Replace with your desired AWS region
}

resource "aws_elb" "example" {
  name      = var.elb_name
  subnets   = ["subnet-12345678", "subnet-87654321"]  # Replace with your subnet IDs
  listener {
    instance_port     = 80
    instance_protocol = "HTTP"
    lb_port           = 80
    lb_protocol       = "HTTP"
  }

  dynamic "listener" {
    for_each = var.listener_rules

    content {
      instance_port     = listener.value.instance_port
      instance_protocol = listener.value.instance_protocol
      lb_port           = listener.value.load_balancer_port
      lb_protocol       = listener.value.protocol
    }
  }
}

In this configuration, we create an Elastic Load Balancer resource (aws_elb) with a default listener configured on port 80 for HTTP traffic. Other than that, we use the Dynamic Block to create additional listeners based on the configurations provided in the listener_rules map.

For example, you can define the listener_rules in a separate .tfvars file (e.g., variables.tfvars):

listener_rules = {
  "https_listener" = {
    protocol           = "HTTPS"
    load_balancer_port = 443
    instance_protocol  = "HTTP"
    instance_port      = 80
  }
  "custom_tcp_listener" = {
    protocol           = "TCP"
    load_balancer_port = 8080
    instance_protocol  = "TCP"
    instance_port      = 8080
  }
}

With this configuration, the Terraform code will dynamically create two additional listeners in the Elastic Load Balancer, as defined in the listener_rules map. If you need to add more listeners, simply include them in the map with their respective configurations.

By leveraging Dynamic Blocks, you can easily manage and scale your infrastructure configurations with minimal code repetition, making your Terraform codebase more clean, maintainable, and readable.

If you liked what you read, do consider sharing the article with a friend and connect with me on Twitter - @afraz_momin. Also, subscribe to my newsletter and stay up-to-date with my latest blog posts.

If you have a number of apps to run, as you likely do if you have migrated to the cloud, containers come in handy. They make it easy to turn apps on and off to meet changing demands. They also let you move apps seamlessly between different servers. But at the same time, containers come with their own set of complexities which can get out of hand without proper management.

To do all of this you need a management platform which can spin containers up, suspend them or shut them down when needed. Ideally, they should also control how the containers access resources like network and data storage. This is where orchestration platforms provide us with a solution to this piece of the puzzle. Orchestration provides us with a number of features like provisioning hosts, instantiating a set of containers, rescheduling failed containers, linking them together through agreed interfaces, exposing services to the outside world and of course, scaling up or down by adding or removing the containers.

In this article, you will learn in-depth about

• What is Container Orchestration? And why is it needed?
• History of Container Orchestration
• How does it work?
• Benefits and Drawbacks
• What are the top container orchestration tools available today?

What is Container Orchestration?

Container orchestration is an automated and simplified process of managing every aspect of individual containers and their dynamic environments. It is nothing but an automated approach to the deployment, scaling and networking of the containers.

Why do you need container orchestration?

Let's assume you have a web application and a database running on two different containers. With time, the traffic to your web app increases, and it is not able to manage this load. As a response to this, you decide to scale the web-app server by adding a few more container instances of the web app across multiple hosts. Similarly, the database container will also be needed to scale accordingly. Adding new containers seems reasonable if the amount is small, but what happens when you have to deal with the addition of a much higher container count, like in hundreds or more?

Also, how do you decide which container goes on which host? Or how do you determine the number of containers you need to run per host? What happens if a container is using too much memory? How do you identify the health of each container? In case some container turns out to be unhealthy, how do you replace the failed container? Do you want a mechanism to replace this container automatically? Last but not the least, how do you ensure security and access for these containers?

This is where Container Orchestration platforms come into the picture.

History of Container Orchestration - how did we get here and why?

There has been a huge shift in trend from using monolithic architecture to microservices in recent years. This rise of microservices-based architecture caused increased usage of container technologies. Containers act as the perfect host for small independent applications like microservices. This led to applications having hundreds or sometimes even thousands of containers running at the same time. Managing these loads of containers across multiple environments using scripts and self-made tools can be complex and time-consuming. This demand for a proper way of managing these hundreds of containers caused the need for container orchestration technologies.

How Does Container Orchestration Work?

Depending on the orchestration platform being used, there can be different techniques to implement container orchestration. Generally, these platforms work based upon the user-created JSON or YAML files which describe the configuration of the application. Most orchestration platforms support declarative configurations.

These configuration files prompt the orchestration platform on how to pull the container images, how to link containers through a network, how to mount storage volumes and where to store log data.

Container orchestration tools also help with the deployment scheduling of containers into clusters and can detect the most appropriate host for the deployment. This host is selected on the basis of guidelines, labels or metadata provided in the configuration files. Once selected, the container orchestration platforms use predefined guidelines to look after the container throughout its lifecycle.

Benefits

Container orchestration aid in managing the container lifecycles in large environments. They simplify container management. Container Orchestration can provide software teams with the following capabilities -

• Improved application deployment - Container orchestration tools can scale applications up and down with minimal manual intervention. This results in high performing applications. Container orchestration tools can also help in spreading application load evenly across the containers.

• Improved Productivity - With container orchestration in place, software teams can rapidly test, deploy, patch and scale as and when needed.

• Better Security - As applications in containers run in an isolated environment, it ensures better security. Besides with container orchestration tools, communication between different services can be set restrictively, allowing only certain services to communicate to and fro as well as, only specific types of services to be exposed to the outside world.

• Reduced costs and resource needs - Multiple containers can be provisioned inside the same host. Containers are lightweight and do take up much space as an OS image normally would. Besides, container orchestration tools can be used to manage these resources more efficiently, ultimately reducing the overall cost to be incurred by the organization.

• Microservices - Each microservice can be provisioned on different containers and with the help of container orchestration tools they can be scaled or modified independently, as and when needed. With the help of orchestration platforms, microservices can communicate more fluidly with each other within the cluster.

These are some of the benefits that container orchestration platforms offer.

Drawbacks

Container Orchestration tools have turned out to be a boon for many organizations but they come with their set of cons as well. Here are some of them -

• Overkill for simple applications - Container orchestration can be an overkill for simple applications. If you do not intend to build anything complex which will be accessed by thousands of users at the same time or deploy an app with high computing resource needs, container orchestration would be highly unideal.
• Complexity - Container orchestration platforms come with their own level of complexities. Developers, who do not come from an infrastructure background, can have a tough time figuring out stuff with the orchestration platforms.
• Transition to orchestration platforms can be challenging - Adoption of orchestration platforms can require some effort. It can be difficult to gauge this effort as use-cases for every organization would be different. It also depends on various other factors like - which programming language is being used and what is the desired environment for that application to run? Or is the application already containerized?
• Expensive compared to other methods - Container orchestration can be quite cheaper if used correctly but it can turn out to be quite expensive as well if the above-mentioned drawbacks are not taken care of. As discussed, migrating or deploying small applications to these orchestration platforms may not be wise and will take up a lot of your engineering time. So besides the infrastructure cost, you will also incur this indirect cost.

Top Orchestrators present in the Market

The top 3 widely used options for Container Orchestration vary in implementation and how you interact with them. Here are some brief descriptions of the platforms and a list of top companies that have adopted them -

Kubernetes

Kubernetes or also known as K8S is an open-source container orchestration tool, which was originally developed by Google. It is by far one of the most popular open-source projects to take the IT world by storm. It seems like almost everywhere you go, every news article you read, or blog you encounter, tells a story of how Kubernetes has revolutionized the way DevOps and IT infrastructure work, like no other platform before it.

Started as an internal project by Google at first, Kubernetes has the capability of deploying, managing, configuring, and orchestrating at both small and large scales. Kubernetes, one can easily run containerized applications across multiple clustered nodes, automatically maintaining the desired number of replicas, service endpoints, and load-balancing across the cluster.

Some top companies using Kubernetes -

• Google
• Spotify
• Pinterest

Docker Swarm

Docker Swarm is Docker's very own container orchestration tool. It gives you the easiest route for orchestrating a cluster of Docker hosts. Docker Swarm comes packaged with Docker which makes it simplest to configure. Docker Swarm has a low learning curve and is very simple to use, making it the best choice for the deployment of smaller applications.

Those wanting to leverage extensive features of Kubernetes while using Docker Swarm can opt for the Docker Enterprise Edition which offers a bundle of both the tools. Docker Swarm supports Windows and Mac OS X but uses VMs to run on non-Linux systems. So if an application is deployed on a Windows container, it won't be able to run on a Linux system. Kubernetes has an upper hand in this as it is not operating system specific.

Some top companies using Docker Swarm -

• Apple
• Mozilla
• Wells Fargo

Apache Mesos

Developed at UC Berkeley, Mesos has gained huge popularity among large organizations like Twitter, eBay, Airbnb and Paypal. It has a very lightweight interface and can provide support for multiple programming languages. Mesos is known for providing flexible architectures and high scalability, owing to the ability to scale to a large number of nodes within the infrastructure.

Ironically, Mesos is not a container orchestration tool. It is in fact a cluster management tool. Mesos, when combined with a framework called Marathon, can work as a proper container orchestrator. Although Mesos promises a lot of scale, it comes with a lot of complexity. It has a steep learning curve and requires high technical expertise. This is the reason why Mesos is only widely adopted by large-scale organizations and may be unideal for small companies that have a limited number of resources.

Some top companies using Apache Mesos -

• Airbnb
• Twitter
• eBay

In the end, which container orchestration tool you use will depend on the scalability that you want to achieve and in which ecosystem you and your organization feel the most comfortable.

Conclusion

To sum up, container orchestration helps us automate the process of deploying and managing containers in bulk. It simplifies container lifecycle management in large environments, offering developers improved agility with their systems and helping them deploy applications to the cloud much faster and with more efficiency. For organizations which reply on the deployment of their applications on containers and require them to scale, container orchestration is very valuable and of the utmost importance.

If you liked what you read, do consider sharing the article with a friend and connect with me on Twitter - @afraz_momin. Also, subscribe to my newsletter and stay up-to-date with my latest blog posts.

Debouncing and Throttling are widely-used techniques that help us in limiting the rate at which a function fires off. These two techniques give us a layer of control between the event and the execution of the functions attached to them. API servers often implement either of these two techniques to prevent the application from being overloaded.

These function calls could be anything from a simple scroll event to an API call to the server. Both these techniques are almost identical and help us reduce the number of function calls being made but they have one small, but significant difference among them.

Before we get into the difference, let's understand how they work individually -

What is Debouncing?

Debouncing is a technique in which no matter how many times a user fires an event, the call will be made only after a specific amount of time has passed after the user stops firing the event.

For example, let's say a user is typing something in a search box. This search box makes API calls and has a debounce function attached to it with a specified time duration of 400ms. So now, unless 400ms have passed after the user stopped typing, the API call wouldn't be made.

I wrote a detailed article on Debouncing in Javascript, a couple of months ago. If the concept of debouncing is completely new to you, I strongly suggest you go to the link below and read the post before moving ahead with this one.

What is Throttling?

Throttling is a technique that makes the next function call strictly after a certain period of time. No matter how many times the user fires an event, the function attached will be executed only once in the given time period.

Let's understand this by coding a simple throttle function ourselves -

We will start by taking a simple Button. Let's say this button calls some API. The onclick attribute on this button will call two functions - normalFunc() and apiWithThrottle()

In our Javascript file, we'll define the functions -

The normalFunc() keeps track of the number of clicks made on the button, and apiCallFunc() keeps track of the number of API calls being made. The function apiWithThrottle() when triggered by the button, will call the throttle() function in which the function to be throttled and the time limit are given as parameters.

After running this code, we see something like this -

Here, we have set the time limit to 1 second (1000ms). Notice how the user clicks the button multiple times but the call to the API is only made 3 times, each after an interval of 1 second. To sum it up in simple words - even if the user clicks the button 15 times in 3 seconds, the number of times the API call will be made is 3 only.

Here's the link to the CodePen, if you want to try this out yourself.

Debouncing vs Throttling

The difference between the two can be understood by taking a simple real-life example -

• Debouncing

Imagine you're a 7-year toddler who loves chocolates. You persistently keep asking your mom for some chocolates. She gives you some but then you start asking for some more. You ask her so many times that she gets annoyed and tells you that you can have it only if you don't bother her and remain silent for the next one hour. This means if you keep asking her, you will only get it one hour after the last time you asked her.

This is debouncing.

• Throttling

Consider the same example - You ask your mom for chocolates despite having them a few minutes ago. You persistently keep asking her, she gets annoyed and finally decides to give you some. But she, being your mom, knows that you will ask for some more in a few minutes. So she gives you the chocolates with a condition that you won't get any more for the next one hour. You still keep bothering her for more but now she ignores you. Finally, after an hour has passed, she gives you the chocolates. If you ask for more, you will get it only after an hour, no matter how many times you ask her.

This is what throttling is!

Use-cases

Both these techniques have their own set of use-cases.

Debouncing can be used when the result of the most recent event occurrence is what is important. For example, a search query on an e-commerce website.

Throttling can be used when the input provided to the function call doesn't matter or is the same each time. For example, infinite scrolling on a webpage. Here, we need to check how far the user is from the bottom of the page. If they're too close, we request more data and append it to the page. Here debouncing wouldn't work as it would only trigger the event when the user has stopped scrolling but we need to start fetching the content before the user reaches the bottom.

Another example would be a multiplayer fighting game where your character has to punch to defeat its opponent. Throttling can be applied to this punching ability of the character such that it can punch only once per second. Now even if the player gives the command to punch 10 times in 5 seconds, the number of punches thrown would be 5 only.

Wrapping Up

Techniques like debouncing and throttling give us control over the execution of events in our websites, helping us reduce the number of high computational tasks that may hamper the performance of our website. They might have different use-cases but the end goal remains the same i.e better performance. So if you're a developer looking to optimize your website, you know what to do!

If you liked what you read, share the article with a friend and connect with me on Twitter - @afraz_momin. Also, subscribe to my newsletter and stay up-to-date with my latest blog posts. I plan to write similar articles on Javascript in the coming days!

In this article, we will take a look at what currying is and how it helps us make our code clean and much simpler.

What is Currying?

Before diving into currying, we first need to understand the arity of a function. The arity of a function is basically the number of arguments it requires.

Consider these two examples -

function addTwo(a, b) {
  return a+b;
}

function addThree(a, b, c) {
  return a + b + c; 
}

In this case, the arity of the function addTwo is 2 and the arity of the function addThree is 3.

Currying a function means to convert a function of N arity into N different functions of arity 1.

In much simpler words, currying is the process of restructuring the function so that it takes only one argument and then returns another function that takes the next argument, and so on.

To give you a sense of how this could work, let's create a couple of functions -

// Un-curried function
function add(x, y) {
  return x + y;
}

// Curried function
function addCurried(x) {
  return function(y) {
    return x + y;
  }
}

add(1, 2);  // Returns 3
addCurried(1)(2);  // Returns 3

Notice the difference between the two. The first function is a simple function that takes two parameters - a and b, and adds them. On the other hand, the second function addCurried takes only one argument i.e a, and returns another function which takes b as the argument. Both give us the same result.

Currying can be helpful when we can't provide all arguments to a function at one time.

Each function call can be saved into a variable, which will hold the returned function reference that takes the next argument when it's available. Let's take another example to understand this better -

// Curried function
function greet(msg) {
  return function (name) {
    console.log(msg, name);
  };
}

let english = greet("Hello,");
let spanish = greet("Hola,");
let german = greet("Geuten Tag,");

german("Dwight"); // Prints "Geuten Tag, Dwight"

spanish("Oscar"); // Prints "Hola, Oscar"

english("Michael"); // Prints "Hello, Michael"
english("Jim"); // Prints "Hello, Jim"

Notice how currying helps us avoid passing the same variable again and again. In this case, the variable msg, which will print "Hello" when called using english. This is a great strategy to avoid frequently calling a function with the same argument.

ES6 Pattern

Currying is part of functional programming and such curried functions can also be easily written using the arrow function syntax in ES6 for more cleaner and elegant code in the following way :

const addCurried = x => y => x + y;

addCurried(1)(2);   // Returns 3

Partial Application Function

When we talk about currying, the concept of Partial Application Function is bound to come up. Currying and Partial application function are almost identical concepts with one significant difference.

Partial application function is a function that returns another function but each returned function can take multiple arguments. In currying, the returning function can only take one argument.

Let's take a simple example to demonstrate this difference-

// Curried function
function addCurried(x) {
  return function (y) {
    return function (z) {
      return x + y + z;
    };
  };
}

// Partial Application function
function addPartial(x) {
  return function (y, z) {
    return x + y + z;
  };
}

addCurried(1)(2)(3); // Returns 6
addPartial(1)(2, 3); // Returns 6

The implementation of both these concepts totally depends upon the use-case and the availability of the arguments at that point in time. But they definitely help us write more cleaner and elegant code.

Wrapping Up

Currying is an incredibly useful concept when it comes to functional programming with Javascript. As seen, using currying we can have functions that are more definite in what they do, avoiding potential repetition in our code, which ultimately leads to simplification of our code.

If you liked what you read, connect with me on Twitter - @afraz_momin. I plan to write similar articles on JavaScript in the coming days!

How well these events are handled decide how user-friendly the web page is.

Event Bubbling and Event Capturing are two phases of event propagation/flow in Javascript. Event flow is basically the order in which the events are received on a web page. In Javascript, event flow takes place in three phases -

1. Capture Phase
2. Target Phase
3. Bubble Phase

This propagation is bidirectional, from the window to the target and back. What differentiates these phases is the type of listeners that are called.

Let's start by understanding Bubbling first.

Event Bubbling:

Bubbling is the flow of events where, when an event takes place on an element, it first runs the handler on itself, then on its parent and then on all of its ancestors.

It basically moves up the hierarchy from the innermost element to the outermost element.

This can be better understood by taking an example -

<body>
    <div id="grandparent">
      <p>Grandparent</p>
      <div id="parent">
        <p>Parent</p>
        <div id="child">
          <p>Child</p>
        </div>
      </div>
    </div>
    <button onClick="history.go(0)">
      Reset Elements
    </button>
  </body>

In our HTML file, we take 3 divs nested one inside the other and give them ids of child, parent, and grandparent starting from the innermost div.

Add a bit of styling

div {
  min-width: 75px;
  min-height: 75px;
  padding: 25px;
  border: 1px solid black;
}

button {
  margin-top: 20px;
  width: 200px;
  font-size: 14px;
  padding: 10px;
}

We will set a click event on each of the 3 divs in our JS file

document.querySelector("#grandparent").addEventListener("click", () => {
  document.querySelector("#grandparent > p").textContent =
    "Grandparent Clicked!";
  console.log("Grandparent Clicked");
});

document.querySelector("#parent").addEventListener("click", () => {
  document.querySelector("#parent > p").textContent = "Parent Clicked!";
  console.log("Parent Clicked");
});

document.querySelector("#child").addEventListener("click", () => {
  document.querySelector("#child > p").textContent = "Child Clicked!";
  console.log("Child Clicked");
});

The code above will perform in the following way -

Notice how, even when the child div is clicked, the handlers on all its ancestors get triggered as well. Similarly, when the parent div is clicked, the handler on the grandparent div will get fired as well. But, keep in mind, in this example, the handler on the child div won't be triggered.

Although, what's more important here is the way the event flow happened. It started from the innermost element, i.e. is the child div and then propagated up the hierarchy eventually reaching the parent and grandparent divs (in that order strictly).

This type of flow of events is called Event Bubbling.

Event Capturing:

The capturing principle is the exact opposite of bubbling. In Event Capturing, the event propagation takes place from the outermost element to the innermost element. Event capturing is sometimes also referred to as event trickling.

We often use the addEventListener() when working with Javascript, in which we usually pass two parameters -

• the event

• the callback function

The addEventListener() function also takes a 3rd hidden parameter - useCapture which takes a boolean value. This useCapture parameter is set to default by false. Setting it to false, makes our events propagate using the principle of Bubbling. Setting it to true will make them propagate in a top-down approach, that is, Capturing.

To implement event capturing we will make a few small changes to our JS code -

document.querySelector("#grandparent").addEventListener("click", () => {
  document.querySelector("#grandparent > p").textContent =
    "Grandparent Clicked!";
  console.log("Grandparent Clicked");
},true); // useCapture parameter is now set to true

document.querySelector("#parent").addEventListener("click", () => {
  document.querySelector("#parent > p").textContent = "Parent Clicked!";
  console.log("Parent Clicked");
},true); // useCapture parameter is now set to true

document.querySelector("#child").addEventListener("click", () => {
  document.querySelector("#child > p").textContent = "Child Clicked!";
  console.log("Child Clicked");
},true); // useCapture parameter is now set to true

Now our code will run in the following way -

Notice how the flow of events now propagates from the outermost element to the innermost element.

i.e grandparent -> parent -> child

This flow of events is called Event Capturing.

Wrapping Up

The reason I spoke about bubbling first is because event capturing is rarely used. It is set to false by default. For most of the browsers, Event bubbling is the default way of event flow.

Javascript helps us make interactive web applications. It makes use of a lot of user-generated events in doing so. The user experience of a website depends on how well these events are handled. Hence it is important to know how events work and the flow behind them.

Here's the link to the Codepen, if you want to demonstrate this yourself.

If you liked what you read, follow me on Twitter - @afraz_momin to stay updated. I plan on writing similar articles about JavaScript in the coming days!

Now imagine making an API call every time a key is pressed on your keyboard. Doesn't sound viable right? Firing an event continuously (in this case, the call to the API) would hamper the performance of the website.

This can be avoided by using the concept of debouncing. Debouncing limits the rate at which a function fires off. In the example above, it drastically reduces the number of API calls that are made to the server.

The setTimeout function of Javascript plays a vital role in implementing debouncing. For those who don't know what setTimeout does, it is a scheduling function provided by Javascript which allows us to run a task after a certain interval of time.

Let's see how we can implement debouncing with a simple example,

The very first thing we'll do here is - create a simple input in our HTML file. On this input box, we will call a method searchData() for the onkeyup event. So that every time the user releases the key after pressing it, searchData() is called.

<body>
    <label for="search">Search</label><br /><br />
    <input type="text" onkeyup="searchData()" />

    <script src="script.js"></script>
  </body>

In our Javascript file, we'll define the searchData() function and create a counter to track the number of times it gets called.

let counter = 1; // To track number of calls

const searchData = () => {
  // Let's say this function calls some API and gets us some data
  console.log("Looking for data..", counter++);
};

After running this program, we see something like this -

Notice how for every letter of the word "Michael", the function gets called. Imagine firing off API calls for a bigger query on a much bigger site. That would be very browser intensive and may hinder the performance. To reduce these continuous function calls, we'll make use of the debounce function :

let counter = 1; // To track number of calls

const searchData = () => {
  // Let's say this function calls some API and gets us some data
  console.log("Looking for data..", counter++);
};

// Debounce function
const debounce = function (fn, delay) {
  let timer = 0;  
  return function () {
    clearTimeout(timer); 
    timer = setTimeout(() => {
      fn();
    }, delay);
  };
};

const callDebounce = debounce(searchData, 300);

Note that we make a change in our HTML file and will be calling callDebounce() now instead of searchData()

 <input type="text" onkeyup="callDebounce()" />

The code above will do the following -

Notice how no call is made until a delay of 300ms is encountered. Instead of making more than a dozen calls for each letter in "Michael Scott", our input bar will only make calls whenever the delay between two keypresses is more than 300 milliseconds. In this case, 2 times.

When the user enters the first character "M", debounce() is triggered which waits for 300ms to fire off the searchData() function. But before 300ms have passed, the user enters another character which will wait another 300ms to fire off searchData() and so on. This will create multiple copies of the timer running in the background. So to clear out the timers in cases where consecutive keypresses are being made without a pause 300ms, we make use of the inbuilt clearTimeout() function. This sets the timer to 0.

This goes on until the user takes a pause after completing the word "Michael", this pause is noticed by the function which in turn fires off our searchData() function.

In simple words, what happens here is that the function waits 300 milliseconds after the last keypress. Only when 300ms have passed and no keypress has been made, it fires off the searchData() function.

Wrapping Up

This was a simple demonstration of debouncing. Using this we can reduce the number of calls made several times in succession by a function, which will ultimately lead to an improvement in the performance of our website.

If you liked what you read, consider following me on Twitter - @afraz_momin to stay updated. I plan on writing similar articles about JavaScript in the coming days!

In this article, I'll walk you through the main differences between a JS library like React and plain Javascript - when to choose which and why?

Let's start by answering two simple questions.

What is Vanilla JS?

Vanilla JS is nothing but plain JS without any external libraries or frameworks. Using this we can build powerful and cross-platform applications.

What is React?

React is a Javascript library used for building user interfaces. It allows us to make complex UIs from isolated pieces of code called "components".

React has quickly become one of the most popular Javascript libraries. This is entirely because of its flexibility and the improvement it brings in the performance. React breaks down the UI into smaller and reusable components that can move around data amongst each other. This breaking down of the UI is what gives React an edge over Vanilla JS.

In Vanilla JS, the code becomes very difficult to maintain if the application is large because in such cases the UI needs to be updated regularly. Here, to change a UI element you need to first find the element in the DOM and then update it. This is fine when you have to update only a single element but imagine doing this on long-form which a user needs to fill. This could be very memory and browser intensive.

This is where React comes in with a great feature i.e its own virtual DOM. The virtual DOM is a shortcut to bypass the manual work. It is a lightweight copy of the actual DOM. It has the same properties as the real DOM but lacks the power to make changes on the screen.

The most important and fundamental reason why modern frameworks are used is that, with Vanilla JS, keeping the UI in sync with the state is hard.

Let's understand this by taking an example

Consider Facebook. Say at a given time, your friends comment on a picture of yours and you want to see it immediately. You'd want to shift from liking posts to commenting or sharing without being slowed down.

Now, this can be done in Vanilla JS too, but the number of changes you'd have to do in the code would be very tedious. All this tiresome work can be avoided by using something like React.

Basically, with React, we can manage to keep the UI and the state synchronized with each other. In Vanilla JS, if you have to change the state, you would need to update the UI. One small mistake and your UI could be out of sync with your data.

Code organization and re-use is another important aspect of React. A component created only once can be used multiple times with different data.

Conclusion

Whether you should use Vanilla JS or React depends very much on your use case.

Vanilla JS is awesome but it's not a great alternative when it comes to building huge applications with complex dynamic functionalities. Besides, it cannot create complex and efficient UIs. So if you have an app that changes frequently and drastically with thousands of pages, it is better to use a modern Javascript framework.

On the other hand, React which allows us to use reusable components and is capable of keeping the UI in sync with the state, can definitely solve this problem.

If you liked this post, consider subscribing to my newsletter.

Thanks for reading!

If you're a beginner in web development OR someone who's looking to get into web development, well, the search is over. You found me!

In this article, I'll be writing and listing out the technologies, frameworks, and libraries which you will be needing, to call yourself a web developer in 2020. Most of these are the industry trends at the moment and learning them will only help you find a good job. Along with the different technologies, I'll also be listing out the links to the resources from where you can learn about them. Most of these would be freely available on the internet so I don't know what's stopping you!

Let's get started.

This will be a two-part article (Frontend and Backend). The one you're viewing right now is Part 1.

Before we get started with the technologies, you need to keep in mind that you don't need to learn all of the libraries, technologies, or tools which I'm going to write about below. Pick the ones which attract you. Research a bit about them and get going!

The Basics

HTML/CSS are the building blocks of web development. It's the first you want to learn. No matter which framework you use, you're gonna need HTML and CSS. So as your first step get started with these two. Once well versed, newer CSS tools like Flexbox and Grid are something you'd want to learn next.

Resources :

• W3Schools - This is the best site to learn HTML/CSS from. Beginner Friendly Content. Covers everything.
• HTML CSS Crash Course - If you're too lazy to go through above the link, this crash course by Dev Ed will solve your problems with HTML and CSS, for once and for all.

Responsive Web Design

Every project that one creates should look good and completely usable on all devices. Most people use their mobile phones to access a website so it's very important the layout is responsive.

CSS frameworks like Bootstrap and Materialize help in creating excellent responsive webpages. Bootstrap is definitely something I'd recommend to a beginner to style their websites and make it look sharp and clean.

Sass - Sass is a CSS pre-processor. CSS pre-processor? What does that even mean? Well, let's just say it helps you create custom reusable CSS components that you can keep using throughout your project. It's like creating your own mini-framework.

Resources :

• Bootstrap - This YouTube series by NetNinja will be more than sufficient for you to learn about Bootstrap 4.
• Sass - A quick crash course on Sass from Brad Traversy

JavaScript

Once you're done learning the HTML and CSS, next up is JavaScript or Vanilla Javascript, as some people like to call it. And NO, it's not related to Java in any way.

Javascript is, hands down, the most important thing to learn in web development. It is the language of the browser. It gives your webpage dynamic functionality. For example, altering your web-page after some button is clicked or popping up alert boxes, etc.

Apart from the fundamentals of JS, you must learn things like the DOM (Document Object Model), JSON (JavaScript Object Notation) and FETCH API.

Modern JS (ES6) knowledge is a must before you move on to frameworks like React, Angular or Vue, as they all are basically derivatives of JavaScript itself.

Resources :

• Modern Javascript from the Beginning - A Udemy course by Brad Traversy. Good course with multiple projects. Highly Recommended.

Essential Development Tools

Git (Version Control) / Github - Git is something every developer, no matter which domain, should know. Knowing how to create different branches, making pull requests and pushing your code is definitely something you should learn. Github is the most popular platform to do all of this. You can get familiar with Git/Github here.

VSCode Extensions - I use VSCode to code my applications and I cannot tell how much these VSCode extensions have made coding easy for me. So if you use VSCode too, I'd recommend extensions like Live Server, Prettier, Bracket colorizer and others ( Maybe another article on this? )

Emmet - Having Emmet will help you write HTML/CSS a lot faster. A MUST HAVE.

NPM/YARN - NPM (Node Package Manager) and YARN are package managers. There isn't too much to learn here but having some knowledge of these two will help you install packages quickly and speed up the development process.

Apart from all this, Axios is another tool you should take a look at. It is an HTTP library that will make your life easier while working with APIs.

Deployment

Deployment these days has been overcomplicated by people. It's not that difficult. We don't really need DevOps or AWS or any other complex platform when we start out.

For personal sites or sites for small businesses, etc. there are managed hosting companies that are easy and cheap.

Two tools that I use regularly are Netlify and Heroku.

Netlify - For static hosting. Basically, for web apps with static content where there is no backend involved.

Heroku - Being a MERN stack developer, I make use of Heroku to deploy my full-stack applications.

And Voila! You're a basic front-end developer

One might argue to be a Front-end Dev, you need to know a framework. Yup, agreed. But at this point, if you have covered most of the things listed above, believe it or not, you can call yourself a "Basic" Front-end Developer.

Front-End Frameworks

Frameworks allow us to build single-page applications with organized UIs and more page interactions. These are the 3 most popular front-end frameworks as of today :

• React - Maintained by Facebook. Most popular and easy to learn. I prefer React.
• Vue - Most recent you could say. Gaining traction. Easy to learn.
• Angular - Maintained by Google. Uses TypeScript.

React, Vue or Angular? This is a never-ending debate. You, ultimately, have to make a choice and choose one. I'd say try all three and then pick the one you like.

When it comes to these frameworks, there are also things like server-side rendering (Next.js/Nuxt.js) and static site generation (Gatsby). But they're optional, you don't need to know them right away. It's just a bonus if you know them.

Resources :

• React - 1. freeCodeCamp - Best way to learn by doing.
  1. NetNinja YouTube Course - React and Redux from Scratch.
• Vue - VueJs Youtube Tutorial by NetNinja.
• Angular - Angular Front to Back - Udemy course by Brad Traversy.

Conclusion

By this point, you should be able to build advance front-end apps, interact with APIs and data, manage app and component level states and have smooth front-end workflow.

Summing it up, if you know majority of the stuff I have talked about above, you can call yourself a front-end developer.

Unfortunately, this article only covers the Frontend part of being a full-stack web developer. I'm gonna be writing Part 2, i.e the backend part in another article very soon. Stay tuned !