In our pursuit of an objective measure of code quality, I encountered the term "Big O Notation." It initially seemed a bit abstract and theoretical, but its importance cannot be overstated. Big O Notation provides a systematic and universally accepted way to measure and compare the efficiency of algorithms. It's like a compass that guides you toward writing code that not only works but works efficiently, even when faced with vast amounts of data.

So why should you care about Big O notation? Let me break it down for you in a way that'll make you want to high-five your computer screen!

Time-Saving : Imagine you're at a big tech company tasked you with writing an algorithm. Knowing Big O helps you create algorithms that work faster and more efficiently. Picture this: you shave off a whole hour of processing time! That's like gaining an extra episode in your Netflix binge-watching marathon. Who doesn't want that?

Code Lingo: Big O gives you a secret language to chat about code performance with your team members. No more vague "it's kinda slow" talk. You'll be tossing around phrases like O(1), O(log n), and O(n^2) like a coding maestro. It's like having a secret handshake in the world of devs.

Trade-off Tango: Sometimes we face tough decisions while we code. Should I go for the flashy, super-speedy code that gobbles up memory like a hungry hippo, or opt for the lean, memory-efficient one that takes a bit longer to finish? Big O helps you weigh these choices with confidence. It's like picking between a turbocharged sports car and a fuel-efficient hybrid but for your code. And most of all helps me understand the different things I can factor into my decisions

Code CSI: Ever had a piece of code go rogue, slowing down your app or causing it to crash? Big O is your trusty detective tool. It helps you spot the misbehaving culprits in your code lineup. Think of it as your code CSI kit, ready to uncover performance bottlenecks faster than Sherlock Holmes or Jake Peralta.

Interview Hero: Job interviews in tech often throw Big O questions your way. Think of it as your secret weapon. Nail those questions, and you're one step closer to landing your dream job in a swanky tech company. It's like having a cheat code for leveling up in the world of coding careers.

Let's Talk Timing: What Makes Code "Better"?

When we say we want "better" code, what exactly do we mean? Is it all about speed, making our code run faster than Usain Bolt? Or perhaps it's about being more frugal with memory, like a financial guru managing their budget. And let's not forget about readability – the art of crafting code that's as clear as a crystal-clear mountain stream.

But here's where things get a bit tricky. If we use time as our sole metric for measuring code quality, we run into a snag. Time can be a slippery character, measured differently depending on various factors like the computer's processing power, the phase of the moon (okay, maybe not that last one).

For instance, think about rendering a high-definition image. On your speedy gaming rig, it might take a mere blink of an eye, but on Aunt Mildred's vintage computer, it could feel like an eternity. So, if we rely solely on time measurements, we might miss the bigger picture.

Enter the World of Operations

So, if not time, then what? Well, here's where we bring some math into the mix (don't worry, it's not rocket science). Instead of counting seconds, let's count something that remains constant no matter what computer you're on – the number of simple operations the computer has to perform.

But hold on, what's an operation, you ask? Great question!

An operation is a fundamental action the computer performs. These can be as simple as adding two numbers, comparing values, or moving data around in memory. The beauty of operations is that they're like LEGO blocks – you can use them to build complex structures, and the number of operations needed to perform a task remains consistent across different machines.

For example, let's say you're sorting a list of names alphabetically. Each time you compare two names to decide which one comes first, that's an operation. If you have a list of 10 names, you might need a handful of operations. If you have a list of 10,000 names, you'll need a lot more operations. if 'n' here represents the number of items you need to sort then increasing n increases the number of operations.

So, when we talk about better code, we're often talking about code that does the same task with fewer operations. In other words, it's like finding the shortest route from point A to point B, where each operation is a step – the fewer steps, the faster you get there! And that, my friends, is the magic of measuring code quality by counting operations. It levels the playing field, allowing us to evaluate code based on its efficiency and performance, regardless of the computer it runs on. 🚀

We'll explore two functions designed to perform the same task: calculating the sum of all numbers from 1 to 'n'. However, these functions take different paths to reach the same destination. One uses a traditional loop, while the other employs a mathematical formula. Our goal is to compare these two approaches based on their operational efficiency, shedding light on how the choice of coding techniques can significantly impact code performance. let's start by taking a closer look at the number of operations in both functions, including the operations within the loop:

Function 1: addUpToSecond

function addUpToSecond(n) {
  return n * (n + 1) / 2; // 3 operations (multiplication, addition, division)
}

For addUpToSecond(5), calculates the sum directly using a mathematical formula.

So, for addUpToSecond(5), there are a total of 3 operations(multiplication, addition, and division) regardless of the size of n.

That means that if I pass in 1000 or 100000 it will still take the same number of operations.

Function 2: addUpToFirst

function addUpToFirst(n) {
  var total = 0; // 1 operation
  for (var i = 0; i <= n; i++) {
    total += i; // 4 operations (addition, assignment of i, comparison, increment of i)
  }
  return total; // 1 operation
}

For addUpToFirst(5), the number of operations is as follows:

• Initializing total is the first operation and it occurs once when the program is run Now if we enter the loop:

• We know that total += i; is shorthand for total = total + i; . Meaning there are two operations happening addition and assignment. But notice this is happening in a loop so it is repeated n times. So now we have n additions and n assignments. So if n=5 , the loop will do repeat 5 times so there will be 5 additions and 5 subtractions.

  Let’s look at the line for (var i = 0; i <= n; i++) where the loop is created

• var i = 0: operation for assigning 0 to i that happens only once the loop has started.

• i <= n : Comparison of i and n which happens on every iteration of the loop meaning it occurs n times

• i++ : This is shorthand for i=i+1 which has two operations (addition and assignment) that occur on every iteration. Meaning they happen n times. (So if n is a billion it happens a billion times)

To get the total number of operations for addUpToFirst(n), we would use 5n+2.but regardless of the exact number the number of operations grows roughly proportionally with n.

The total number of operations for addUpToFirst(5) is (5x5) + 2 = 27 operations.

Now if we compare the two functions:

• addUpToFirst for n = 5 requires 27 operations.

• addUpToSecond for n = 5 requires 3 operations.

As you can see, addUpToSecond is significantly more efficient in terms of the number of operations, especially as 'n' increases. This emphasizes the efficiency gained by using a mathematical formula instead of a loop, making addUpToSecond it faster and more efficient than addUpToFirst.

Visualizing Code Efficiency: A Closer Look at Execution Time

To get a detailed understanding of how two functions perform in terms of execution time, we'll utilize a helpful tool (https://rithmschool.github.io/function-timer-demo/). However, there's a slight twist here – we'll start with a small 'n' value and gradually increase it to find the optimal results for each function. we'll notice a fascinating trend in the visualization.

Trend 1: Function 1 (addUpToSecond)

For Function 1, which utilizes a loop to calculate the sum, we'll observe the following trend:

• Initially, as 'n' starts with a small value (e.g., 10), the execution time is relatively short (measured in microseconds).

• However, as we increment 'n' to 100, 1000, and beyond, the execution time steadily increases.

• This increase in execution time follows a linear pattern, roughly proportional to 'n'. In the visualization, you'll see a linear slope where execution time gradually rises as 'n' grows.

• The key takeaway is that for Function 1, the time it takes to complete the task increases linearly with the size of 'n'. This behavior is consistent with a linear time complexity, often represented as O(n).

Trend 2: Function 2 (addUpToFirst)

For Function 2, which relies on a mathematical formula, we'll observe a different trend:

• Similar to Function 1, the execution time starts at a low level when 'n' is small.

• However, as 'n' increases, the execution time remains remarkably stable and minimal. It does not exhibit the same linear growth seen in Function 1.

• In the visualization, you'll notice a nearly flat line, indicating that the execution time is not significantly affected by changes in 'n'.

• This behavior aligns with a constant time complexity, often represented as O(1), where the execution time remains constant, regardless of the input size.

In summary, the trend reveals that Function 1's execution time increases linearly with 'n', while Function 2's execution time remains nearly constant, regardless of the value of 'n'. This visualization vividly illustrates the concept of code efficiency and how the choice of coding techniques can significantly impact the time required to complete a task, especially as the problem size ('n') grows. From this, we can establish that efficiency depends on time and space.

So what is Big 0

Big O notation is a mathematical notation used in computer science and mathematics to describe the upper bound or worst-case scenario of the time complexity or space complexity of an algorithm or function. It provides a way to analyze and compare algorithms based on their efficiency and how they scale with input size. (Think of special notation that helps us describe how fast or slow a computer program is and how it handles bigger and bigger tasks)

In Big O notation, an algorithm's performance is expressed using a function, typically denoted as O(f(n)), where "f(n)" represents the relationship between the input size (often denoted as 'n') and the number of basic operations performed by the algorithm. This function describes how the algorithm's runtime or space usage grows as the input size increases. So f(n) can be linear (f(n) = n), quadratic (f(n) = n^2), constant (f(n) =1), or something entirely different

The most common Big O notations include:

1. O(1) (Constant Time): The algorithm's runtime or space usage remains constant regardless of the input size. It indicates highly efficient algorithms that execute in a fixed amount of time or require a fixed amount of memory. (This is like having a magic spell that instantly finds the word, no matter how big the book is. It's super fast and always takes the same amount of time, whether it's a small book or a huge library.)

2. O(log n) (Logarithmic Time): The algorithm's runtime or space usage grows logarithmically with the input size. These algorithms become more efficient as the input size increases. (Think of this as a clever guessing game. As the book gets bigger, you need a few more guesses, but it's still pretty fast, and the more you guess, the faster you get at it.)

3. O(n) (Linear Time): The algorithm's runtime or space usage scales linearly with the input size. For every additional element in the input, the algorithm performs a constant amount of work. (This is like reading the book page by page. If the book doubles in size, it takes twice as long. It's simple but can get slow for really big books.)

4. O(n log n) (Logarithmic Time): The algorithm's runtime or space usage grows in proportion to 'n' multiplied by the logarithm of 'n.' Algorithms with this complexity are often efficient and are commonly seen in sorting and searching algorithms. (Imagine reading the book, making some notes, and then finding what you need. It takes a bit longer than just reading but is still pretty efficient.)

5. O(n^2) (Quadratic Time): The algorithm's runtime or space usage grows quadratically with the input size. It indicates algorithms that perform nested iterations over the input. (This is like checking every word on every page one by one. As the book gets bigger, it takes much more time, and it can be slow for large books.)

6. O(2^n) (Exponential Time): The algorithm's runtime or space usage grows exponentially with the input size. These algorithms become impractical for large input sizes due to their rapid increase in resource requirements. (This is extremely slow. It's like making a copy of the entire book for every word you want to find. For big books, it's painfully slow)

7. O(n!) (Factorial Time): The algorithm's runtime or space usage grows factorially with the input size. These algorithms are highly inefficient and are typically used for small, specialized cases. (This is the slowest. It's like writing out every possible combination of words and checking them all. Even for moderately-sized books, it can take forever.)

image from geeks for geeks

Big O notation provides a standard way to analyze and compare algorithms, enabling developers to make informed decisions about algorithm selection and optimization to ensure efficient and scalable software. It focuses on the worst-case scenario, helping to predict how an algorithm will perform when faced with the largest possible input.

If we go back to the examples discussed earlier

• The time complexity of sumUsingLoop is O(n). This means that as the input size 'n' increases, the number of operations also increases linearly. If 'n' doubles, the number of operations roughly doubles as well.

• The time complexity of sumUsingFormula is O(1), which is constant time. Regardless of how large 'n' becomes, the number of operations remains the same. It's highly efficient and doesn't depend on the input size. Contrast:

• When comparing the two functions, you can see that sumUsingFormula is far more efficient in terms of time complexity. Its execution time remains constant, making it the preferred choice for large values of 'n.'

• In contrast, sumUsingLoop has a linear time complexity. As 'n' grows, the number of operations increases proportionally. This means it might not be the best choice for large datasets or inputs because it can become slower as 'n' gets larger.

• Big O notation precisely describes this difference in efficiency. It tells us that sumUsingFormula is O(1), indicating constant time, while sumUsingLoop is O(n), indicating linear time. So, this allows us to understand and compare the efficiency of algorithms or code. It helps us make informed decisions about which approach to use based on the problem's size and the resources available. In this case, it's clear that sumUsingFormula is the more efficient option for summing numbers from 1 to 'n' for larger values of 'n.'

Understanding Big O Simplification

You might be wondering how we simplified O(5n + 2) into O(n) .Let's break down how we simplify the Big O notation to O(n).

In Big O notation, we're interested in understanding how the number of operations or the execution time grows concerning the size of the input (usually denoted as 'n'). When simplifying, we focus on the term that has the most significant impact as 'n' becomes large, and we ignore constants and lower-order terms.

In the expression O(5n + 2), we have two terms: 5n and 2.

Here's why we simplify it to O(n):

1. Focus on the Dominant Term: In this case, the term 5n dominates because its growth rate is directly proportional to 'n.' As 'n' increases, the number of operations increases linearly with 'n' due to the 5n term.

2. Ignore Constants: Big O notation doesn't concern itself with constants because they don't affect the overall growth rate concerning 'n.' The "+ 2" term represents a constant (2) that doesn't change as 'n' varies.

3. Ignore Lower-Order Terms: Big O notation focuses on the most significant term that contributes to the growth rate. In this case, 5n is the dominant term, and it's a linear term.

4. 1. Arithmetic operations are constant: In most cases, basic arithmetic operations like addition, subtraction, multiplication, and division are considered constant time operations. They take the same amount of time regardless of the values involved.

5. Variable assignment is constant: Assigning a value to a variable typically takes constant time. It doesn't matter how large or small the value being assigned is; the time it takes remains constant.

6. Accessing elements in an array (by index) or object (by key) is constant: This statement highlights the concept of constant-time access to elements in data structures like arrays and objects. It doesn't matter how big the array or object is; accessing an element by its index or key takes roughly the same amount of time.

7. In a loop, the complexity is the length of the loop times the complexity of whatever happens inside the loop: This is a crucial principle in analyzing algorithms with loops. The time complexity of a loop is determined by multiplying the number of iterations (the length of the loop) by the complexity of the operations inside the loop. This helps in understanding how loops impact overall algorithm efficiency.

These principles provide a foundation for understanding how various operations and code structures contribute to an algorithm's time complexity. They are essential when breaking down and analyzing the performance of algorithms and code.

It's worth noting that while these principles are generally true, there can be exceptions and variations depending on the specific programming language, hardware, and optimizations applied. However, they provide a good starting point for reasoning about algorithmic efficiency.

So, when we simplify O(5n + 2) to O(n), we're essentially saying that as 'n' becomes large, the number of operations grows linearly with 'n,' and the constant term 2 doesn't significantly impact the overall growth rate concerning 'n'. If you want to learn more about simplifying big expressions read this https://medium.com/swlh/lets-simplify-big-o-9aed90d11f34

In Big O notation, we aim to express the upper bound or worst-case scenario of an algorithm's growth rate as a function of 'n' while simplifying the expression by focusing on the most dominant term, ignoring constants, and ignoring lower-order terms. This simplification helps us compare and analyze algorithms more effectively.

Let’s look at a few more algorithms in the https://rithmschool.github.io/function-timer-demo/ tool and try to get their big O notation. So for the countUpAnddown

function countUpAndDown(n) {
  console.log("Going up!");
//loop one 
  for (var i = 0; i < n; i++) {
    console.log(i);
  }
  console.log("At the top!\nGoing down...");
  // loop two
  for (var j = n - 1; j >= 0; j--) {
    console.log(j);
  }
  console.log("Back down. Bye!");
}

It's understandable to think that because there are two loops in the countUpAndDown function, both with time complexities of O(n), the overall time complexity is 2n. However, when analyzing the time complexity of consecutive loops, we don't simply add their complexities together.

In this case, you have two separate loops, each with its own iteration over 'n.' When determining the overall time complexity, you take the highest time complexity because the loops run sequentially, not concurrently.

So, in this function:

• The first loop has a time complexity of O(n).

• The second loop also has a time complexity of O(n).

But since they run one after the other, you consider the highest time complexity, which is O(n). This represents the overall time complexity of the function. Therefore, the time complexity of countUpAndDown is O(n), not 2n.

For printAllPairs

function printAllPairs(n) {
  for (var i = 0; i < n; i++) {
    for (var j = 0; j < n; j++) {
      console.log(i, j);
    }
  }
}

For the nested loops in the printAllPairs function, where you have two loops iterating from 0 to 'n,' the time complexity can be analyzed as follows:

• The outer loop runs 'n' times, and for each iteration of the outer loop, the inner loop also runs 'n' times. This means that for each of the 'n' iterations of the outer loop, the inner loop performs 'n' iterations.

To determine the overall time complexity, you can multiply the number of iterations of the outer loop by the number of iterations of the inner loop:

• 'n' iterations of the outer loop 'n' iterations of the inner loop = n n = n^2

So, the time complexity of the printAllPairs function with nested loops is O(n^2), which is quadratic time complexity. This indicates that the number of operations grows quadratically with the size of 'n,' and it can become significantly slower as 'n' increases.

Space Complexity

So far we have been focusing on time complexity: how can we analyze the runtime of an algorithm as the size of the inputs increases? So good news is we can still use big O notation to analyze space complexity: how much additional memory do we need to allocate in order to run the code in our algorithm

let’s talk about the inputs, so we shall ignore the size of n since it obviously increases with the n. we shall focus on auxiliary space complexity which refers to space required by the algorithm, not including the space taken by the inputs.

A few rules of thumb

• Most primitives(Booleans, numbers, undefined, null) are constant space.

• Strings require O(n) space (where n is the string length)

• Reference types are generally O( n), where n is the length (for arrays) or the number of keys (for objects)

Let’s look at a few examples:

Example 1: sum function

function sum(arr) {
  let total = 0;
  for (let i = 0; i < arr.length; i++) {
    total += arr[i];
  }
  return total;
}

In this example:

• The function sum takes an array arr as input.

• A single variable total is created, which is constant space (O(1)) because it doesn't depend on the size of the input.

• The loop uses an iterator i, which is also constant space (O(1)).

• Now since the total is already in memory we don't consider total += arr[i];

• The space complexity is primarily determined by the input array arr. As the array's size increases, the space required to store it increases proportionally. Therefore, the space complexity of this function is O(n), where 'n' is the length of the input array.

Example 2: double function

function double(arr) {
  let newArr = [];
  for (let i = 0; i < arr.length; i++) {
    newArr.push(2 * arr[i]);
  }
  return newArr;
}

In this example:

• The function double takes an array arr as input.

• A new array newArr is created, which is directly related to the size of the input array. As arr grows, so does newArr. Therefore, the space complexity for newArr is O(n), where 'n' is the length of the input array.

• The loop uses an iterator, i which is constant space (O(1)).

So, for the double function, the primary contributor to space complexity is the new array, newArr making it O(n).

Lastly let’s talk about logarithms

We've explored some of the familiar complexities in Big O notation, such as O(1) for constant time, O(n) for linear time, and O(n^2) for quadratic time. However, as we delve deeper into algorithm analysis, we encounter more intricate mathematical expressions, and one that frequently arises is the logarithm.

Logarithmic time complexity is a desirable characteristic of algorithms because it means that the algorithm's performance improves as the input size increases. Certain searching algorithms, such as binary search, have logarithmic time complexity because they repeatedly divide the search space in half. Efficient sorting algorithms, such as quicksort, merge sort, and heapsort, involve logarithms because they divide the input into smaller and smaller pieces until they are sorted. Recursion sometimes involves logarithmic space complexity because each recursive call adds a new layer to the call stack, which has a logarithmic relationship to the input size.

Resources

• Colt Steele Slides

In search of a better solution, I went on a quest for a "batteries-included" framework akin to Django in Python, Laravel in PHP, or .NET in C#. I wanted something that:

Enforced best practices: Consistent structures and patterns would save time, prevent errors, and improve code maintainability.

Supported TypeScript out of the box: For a more robust and scalable development experience.

Handled authentication out of the box: Eliminate the need to build authentication logic from scratch, saving development time and improving security.

My search led me to NestJS, and it instantly transformed my Node.js development experience. This blog will be your ultimate deep dive into NestJS, exploring its features, components, benefits, and why it's the perfect choice for building robust and scalable Node.js applications. Now that we've established the pain points of inconsistent setups and the desire for a structured framework, let's dive deeper into NestJS itself.

What is NestJS?

NestJS is a JavaScript application framework designed specifically for building efficient and scalable server-side applications using Node.js. It embraces modern development practices, offering several key features:

Progressive JavaScript: the ability to gradually adopt modern JavaScript features while still maintaining compatibility with older.

TypeScript Support: Embraces the benefits of TypeScript for type safety and advanced features, while still allowing pure JavaScript development for flexibility.

Paradigm Blend: NestJS incorporates elements from various programming paradigms like Object-Oriented Programming (OOP), Functional Programming (FP), and Functional Reactive Programming (FRP), providing flexibility and diverse tools for different situations.

Opinionated Approach: NestJS guides developers towards best practices by promoting specific patterns and structures, leading to cleaner, more maintainable code. This "opinionated" approach draws inspiration from frameworks in the ASP.NET and Java worlds.

Express Integration: NestJS leverages the popular Express framework under the hood, allowing you to utilize familiar Express concepts like middleware and routing within the NestJS structure.

Batteries Included: NestJS boasts a rich ecosystem with numerous features "out of the box," including support for web sockets, microservices architecture, and extensive testing capabilities. This reduces the need for extensive third-party library integrations.

NestJS provides a robust foundation for building modern and scalable Node.js applications, promoting best practices through its structure and offering a comprehensive feature set without sacrificing developer flexibility. By combining powerful features with familiar paradigms, NestJS empowers developers to focus on business logic and deliver exceptional applications.

Why Embrace NestJS for Your Next Project?

NestJS stands out as a compelling choice for building robust and scalable Node.js applications, offering several key advantages:

1. Enforcing Best Practices:

NestJS promotes well-established design patterns, guiding developers towards a structured and organized codebase. This approach simplifies the process of creating maintainable, scalable, and extensible systems, reducing the risk of technical debt in the long run.

2. Suitable Abstractions:

NestJS provides appropriate abstractions that effectively shield developers from low-level complexities. This simplifies development and allows them to focus on core business logic without getting bogged down in the intricacies of underlying technologies.

3. Opinionated Approach:

NestJS isn't afraid to take a stance on best practices. It encourages consistent patterns and structures across projects, leading to code that's easier to understand, maintain, and collaborate on. This "opinionated" approach, while valuing flexibility, ultimately fosters consistency and coherence within a project and across different teams. This translates to shorter onboarding times and reduced training overhead, especially for those with experience in similar frameworks like Spring Boot, thanks to shared concepts. This is particularly valuable for startups where time is often a critical resource.

4. Enhanced Reusability:

NestJS promotes code reusability at multiple levels:

Code-Level Reusability: The framework offers reusable components and modules, reducing redundancy and streamlining development.

Experience and Knowledge Reusability: By borrowing concepts from established frameworks like ASP.NET, Angular, and Spring, NestJS leverages existing knowledge and experience, shortening the learning curve for developers familiar with these platforms.

In essence, NestJS empowers developers to:

Focus on innovation: Simplified development and enforced best practices free up valuable time and cognitive resources to focus on delivering innovative solutions and features.

Build maintainable systems: The structured approach fosters code that's easier to understand, modify, and scale, ensuring long-term project health.

Leverage existing knowledge: Familiarity with similar frameworks translates into quicker adoption and utilization of NestJS, accelerating development and reducing onboarding times.

By combining these benefits, NestJS presents a compelling choice for developers seeking a structured, efficient, and scalable foundation for their next Node.js application.

Getting Started with NestJS: Setup and Installation

Prerequisites:

Before diving into NestJS, ensure you have the following installed on your system:

• Node.js: NestJS is built upon Node.js, so you'll need a recent version installed. Download and install it from the official website.

• ES6 Features: like classes

• Backend basics

Getting Started:

1. Install Nest CLI:

Once you have Node.js running, you can install the Nest CLI (Command Line Interface) globally using npm:

npm install -g @nestjs/cli

This command installs the Nest CLI tools globally, allowing you to easily create and manage NestJS projects from your terminal.

2. Create a New Nest Project:

With the Nest CLI installed, you can create a new NestJS project using the following command:

nest new <project_name>

Replace <project_name> with your desired project name (e.g., my-awesome-app).

This command will create a new directory named <project_name> with the basic NestJS project structure, including essential files and folders for your application.

Next Steps:

After creating the project, navigate to the project directory using cd <project_name>:

You can then install dependencies and run the application using the following commands:

npm install
npm run start

These commands will install the required dependencies and start your NestJS application in development mode. You can then access your application in your browser, typically at http://localhost:3000.

Mastering the NestJS CLI: Essential Commands

The NestJS CLI is a powerful tool that streamlines project creation, development, and management. Here's a breakdown of some key commands you'll use frequently:

1.nest new <project_name>:

Purpose: Scaffolds a new NestJS project with the specified name, providing the fundamental directory structure and essential files to kick-start your application.

2.nest start:

Purpose: Starts the development server, transpiling your TypeScript code into JavaScript for execution.

--watchflag: Enables automatic transpilation whenever you make changes to your code, ensuring your application reflects the latest updates without manual intervention.

3.nest generate <element>:

Purpose: Generates various building blocks of your NestJS application, including :

Modules: Organize your application logic and functionality.

Controllers: Handle incoming API requests and responses.

Pipes: Transform and validate data before it reaches your controllers.

Guards: Implement authorization logic to control access to specific application parts.

Providers: Create services and utility functions used throughout your application.

Services: Encapsulate reusable business logic and interact with external resources like databases.

Test file inclusion: Importantly, this command also generates a corresponding test file for the specified element, promoting good testing practices from the outset.

With these fundamental CLI commands, you'll be well-equipped to navigate the development process and build robust NestJS applications efficiently. If you want to see more of these check out the official docs.

NestJS Project Structure: Files and Scripts Explained

NestJS offers a well-organized project structure to streamline development and maintainability. This section delves into essential files and scripts within our newly created NestJS project:

1.package.jsonScripts:

npm run build: Transpiles your TypeScript code into JavaScript for production use. The generated code resides in the dist folder, ready for deployment to your server.

npm run format: Leverages the prettier library to format your code consistently, enforcing a uniform style guide across your project. This promotes code readability and improves team collaboration. Ideally, you'd run this before committing changes or pushing code.

npm run start: Starts the NestJS web server using the transpiled code in the dist folder. This command is typically used on the server where your application runs.

npm run start:dev: Similar to npm run start, but includes the --watch flag. This enables a file watcher that automatically rebuilds your code and restarts the server whenever you make changes, streamlining the development workflow.

2. Application Files:

srcFolder: Holds all of your application's source code, categorized into different files.

3. Core Application Files:

nestJS App src folder

I'll make an effort to provide a brief explanation of the files in your src folder. When we get to the nest's construction blocks, we'll dig deeper;

main.ts: The entry point of your application. When you run nest start, it executes this file, finding and instantiating the root module (AppModule) to create the application instance. It also sets up global middleware and starts the Express server on the specified port (3000 by default). This file contains the bootstrapping logic, keeping it separate from application-specific concerns, making it easier to modify or test in isolation following the Encapsulation & Single Responsibility Principle (SRP).

app.controller.ts: A basic controller providing an endpoint at http://localhost:3000. The controller focuses on handling requests and responses, delegating business logic to the injected AppService (see below). Inversion of Control(IoC) helps manage dependencies, improving testability and flexibility.

app.controller.spec.ts: The corresponding test suite for the AppController. These test suites are automatically generated when you create elements using nest generate, providing a starting point for writing unit tests.

app.service.ts: A simple injectable provider that returns a "hello world" message. In real-world scenarios, service classes handle the bulk of your application's business logic.

app.module.ts: The root module, acts as the dependency injection container explicitly managing dependencies and their lifecycles. It registers all your controllers and providers for the application to use. This AppModule is typically maintained and other modules are imported into it. This improves code testability and makes the system more flexible to change.

4. NestJS-Specific Files:

nest-cli.json: Configures the Nest CLI, allowing customization of project generation settings or default CLI behaviors (e.g., default file naming conventions).

tsconfig.json: The base TypeScript configuration file, controlling the compilation behavior of your TypeScript code.

**tsconfig.build.json: ** Occasionally, this file may exist to provide specific configuration for the TypeScript compiler used in the build process.

public: May contain static assets to be served directly by the web server.

3. Testing-Related Files:

test/*: You might have a dedicated test folder containing different types of tests:

.e2e-spec.ts: End-to-end tests that simulate real user interactions with your application through the browser.

Other integration test files: These might focus on testing how different components of your application interact with each other.

4. Other Files:

.eslint.js*: allows you to define configuration rules for your project using various formats. This format offers a concise and readable way to specify your desired coding style and enforce best practices. You can go ahead and add linters to the project to enforce your team code styles

Note: This is not exhaustive. As your project grows, you might introduce new file types or folders to organize things like:

NestJS Module Structure: Feature-Based Organization

NestJS adopts a per-feature module approach, similar to Angular and Django. This means that all the elements needed to implement a single feature (like CRUD operations for a database model) are grouped within a dedicated folder and bundled into a corresponding module.

Comparison with Traditional Layered Structure:

Traditional approaches, often seen in ASP.NET, Java, and elsewhere, organize classes by their type (e.g., controllers, services, models) in separate folders. Here's an example:

Controllers/
|--- TodoController.cs
Services/
|--- TodoService.cs
Models/
|--- TodoEntity.cs

NestJS Approach:

In NestJS, the structure looks different, grouping elements by feature:

todo/
|--- todo.controller.ts
|--- todo.entity.ts
|--- todo.module.ts
|--- todo.service.ts

Benefits of Per-Feature Modules:

Improved Discoverability: Grouping related code by feature makes it easier to find and understand specific functionalities within your application.

Enhanced Reusability: Entire modules, representing complete features, can be easily moved around, integrated into other projects, or packaged as libraries.

Clear Delegation: Feature modules facilitate assigning ownership and development responsibilities to individual teams or members.

This approach makes it rather painless to pick up and move large portions of functionality to new codebases or into packageable libraries, and also makes it easy to split up code responsibilities among teams or team members.

Core Building Blocks of NestJS

As highlighted by NestJS's founder, the framework offers several key building blocks that empower developers to efficiently construct robust and scalable applications. Here's a breakdown of these essential elements:

Modules

Modules are where all of the controllers and providers are registered, along with all of the imported sub-modules which contain their own controllers and providers. Modules hook up the dependency injection containers and enable the resolving of required dependencies for controllers and providers. In NestJS, modules are created by decorating a class with the @Module decorator. A simple example of a Module class would look like this:

//sample.module.ts
@Module({
    imports: [DatabaseModule],
    controllers: [TodoController],
    providers: [TodoService],
    exports: [TodoService],
})
export class TodoModule  {}

The @Module decorator takes in a metadata object with four properties: • imports: Importing other @Module classes allows for using other sub-modules and creating the hierarchy of functionality. For instance, the AppModule will be importing the TodoModule, enabling the TodoModule functionality to be enabled at the root of the application. This is also how third-party modules such as @nestjs/typeorm, @nestjs/config, and others are wired into your application. • controllers: The controller's array contains the @Controller classes that are registered to this module. By defining them in this array, they are made accessible via HTTP requests. • providers: The provider's array contains all @Injectable classes such as data services, instance factories, pipes, guards, middleware, and interceptors. • exports: This array allows for making providers and imports registered to this module available for use outside of the current module. For example, a TodoService registered to a TodoModule is only available for classes inside the TodoModule. Once TodoService is added to the exports array, it is now available to outside modules. (This is the main difference between nest and angular)

Controllers

Controllers are responsible for handling incoming requests and returning responses to the client. Controllers can group related request-handling logic into a single class. For example, a TodoController class might handle all incoming requests related to users, including showing, creating, updating, and deleting to-dos. They are responsible for interpreting input, passing the request details to services, and then formatting the service results in a way that can be exposed as responses. In the case of NestJS, “Controller” specifically refers to a class that handles HTTP requests. In NestJS, controllers are decorated with the @Controller decorator. By passing a string into the @Controller argument, we define a base route path for all of the routes inside the controller. The routes inside this class are notated with HTTP method decorators and path designations. It is best practice to keep controllers relatively “thin” and avoid putting significant business logic, data logic, or otherwise processing logic in your controller route methods: that work belongs in a provider service. By keeping the controller’s responsibility clearly defined as input and output transformation, it becomes easier to write, read, design, and test your code. A simple example of a Controller class would look like:

//sample.controller.ts
@Controller('api/app')
export  class  AppController  {
    constructor(private  readonly  appService:  AppService)  {}

    @Get('health')
    getHealth():  HealthCheck  {
        return  this.appService.getHealth();
    }
}

Providers

Providers is a blanket term in NestJS that encompasses service classes, repositories, factories, utility classes, and anything of that nature. This also includes important NestJS elements like middleware and guards. These are marked with the @Injectable() decorator. A provider is an instruction to the dependency injection system on how to obtain a value for dependency it can be a simple injectable class or a factory, third-party library.

Services

Services contain the core business logic of your application, handling complex operations, interacting with databases or other external resources, and generally orchestrating application logic.

Others

Interceptors

These inspect, enhance, or transform HTTP requests from the client to the applications or transform responses on their way back to the client.

Guards

These control the request behavior. So when a request is sent before it can proceed each guard checks if the request should be allowed to proceed for instance extract the json-web-token.

Pipes

Pipes in NestJS transform request parameters at a method level. While you can create your own, the @nestjs/common package comes with very helpful pipes that cover the most common use cases. • ValidationPipe: provides request validation using the class-validator library. • ParseIntPipe: parses the route parameter to a number type. • ParseBoolPipe: parses the route parameter to a boolean type. • ParseArrayPipe: parses the route parameter to an array of a given type. • ParseUUIDPipe: parses the route parameter to a UUID of a provided version. • DefaultValuePipe: allows for a default value if no value is supplied in the route.

Building a NestJS Todo List API

Let's create a simple Todo List API in NestJS to solidify our understanding of its core concepts. Here's a step-by-step approach:

1. Project Setup:

Prerequisites: Ensure you have Node.js and npm (or yarn) installed on your system.

Create Project: Open your terminal and run:

nest new todo-api

This creates a new NestJS project named todo-api

Creating Todo directory and files

To start building our custom Todo module, let’s first create the empty files we will need. While the NestJS CLI has some excellent generation tools that we can use (which we will review later!), for this exercise we will create them by hand to demonstrate how these files all work together. Inside of your application directory, make the following directory and files:

mkdir src/todo/
touch src/todo/todo.controller.ts
touch src/todo/todo.interface.ts
touch src/todo/todo.module.ts
touch src/todo/todo.service.ts

Optionally you can use the Nest CLI. The Nest CLI simplifies this process quite a bit and we can accomplish the same module setup with the following commands:

nest generate module todo
nest generate controller todo
nest generate service todo
cd todo && nest generate interface todo

Create the Todo interface

Inside of the todo/todo.interface.ts file, we will define the shape of the To-do JSON object. Note that interfaces are different from classes in that interfaces are “abstract” - there is no JavaScript code output and they are purely used for the TypeScript compiler and IntelliSense tooling - while classes are actual instantiations in memory. To create an interface, use the TypeScript keyword interface. Our To-do class will have three properties:
• an optional id (optional new To-do requests will auto-assign the id)
• a label string
• a complete Boolean flag We will add these to the interface as such:

//todo.interface.ts
export interface  Todo  {
    id?:  number;
    label:  string;
    complete:  boolean;
}

Create the TodoService data service

Following the prescribed NestJS architecture pattern, we will create a TodoService class that handles the data logic for maintaining our To-dos. Inside of the todo.service.ts file, we will define an exported TypeScript class, TodoService, and decorate it with the @Injectable decorator.

//todo.service.ts
import  {  Injectable  }  from  '@nestjs/common';

@Injectable()
export  class  TodoService  {
}

We will be using an in-memory array as our storage mechanism. This will not persist and will be cleared out every time the development server is restarted, but it will serve as a simple mechanism to start your NestJS journey. To create this array, we will define and instantiate a storage class-level variable. Once added, your todo.service.ts class should look as such:

// todo.service.ts
import  { Injectable }  from  '@nestjs/common';
import  { Todo }  from  './todo.interface';

@Injectable()
export class TodoService  {
    private storage: Todo[] = [];
}

Note: that NestJS providers are singletons by default and any injection of the TodoService will share the same in-memory array

Create theTodoControllerREST API Controller

We now need a Controller to handle our HTTP requests. To do so, we create and export a TodoController class that is decorated with the NestJS @Controller decorator with the base route path of “todo”.

// todo.controller.ts
import  {  Controller  }  from  '@nestjs/common';

@Controller('todo')
export  class  TodoController  {
}

To leverage the TodoService we created, we will use NestJS’ dependency injection through constructor injection. Using TypeScript’s constructor assignment feature, we can easily set the provider as a private, readonly class-level instance property.

//todo.controller.ts
import  {  Controller  }  from  '@nestjs/common';
import  {  TodoService  }  from  './todo.service';

@Controller('todo')
export  class  TodoController  {
    constructor(private  readonly  todoService:  TodoService)  {}
}

NestJS will analyze the parameters in the constructor, find the types in the dependency injection container, and resolve them. We will now be able to use the TodoService in-controller methods via this.todoService. To validate our module, we will set up a single GET route that returns an empty array (note the added import). Routes are enabled using HTTP method decorators: @Get, @Post, @Put, @Patch, and @Delete. Just like the parameter passed to @Controller, the value passed to the method decorator defines the path of the route. In the case of this GET request, we will leave it as undefined, ultimately resolving to the base route path of /todo.

// todo.controller.ts
import  {  Controller,  Get  }  from  '@nestjs/common';
import  {  TodoService  }  from  './todo.service';
import  {  Todo  }  from  './todo.interface';

@Controller('todo')
export  class  TodoController  {
    constructor(private  readonly  todoService:  TodoService)  {}

    @Get()
    findAll():  Todo[]  {
        return  [];
    }
}

Create theTodoModulemodule

With our Controller and Provider classes created, we now need to create a class and decorate it with the @Module decorator to register them to the NestJS application. To do so, we’ll create a TodoModule class and decorate it with the @Module decorator.

// todo.module.ts
import  {  Module  }  from  '@nestjs/common';

@Module({})
export  class  TodoModule  {}

Now we can add the TodoService as a Provider to this module to make it available for injection.

// todo.module.ts
import  {  Module  }  from  '@nestjs/common';
import  {  TodoService  }  from  './todo.service';

@Module({
    providers:  [TodoService],
})
export  class  TodoModule  {}

With the TodoService now registered, we can register the TodoController which will resolve the service as a dependency.

//todo.module.ts
import  {  Module  }  from  '@nestjs/common';
import  {  TodoController  }  from  './todo.controller';
import  {  TodoService  }  from  './todo.service';

@Module({
    controllers:  [TodoController],
    providers:  [TodoService],
})
export  class  TodoModule  {}

Import TodoModule into AppModule

We now have a contained module of functionality, from the HTTP request to the data storage. However, the root module AppModule we saw in the previous chapters has no reference to TodoModule. As we know, our entry point main.ts creates the INestApplication from the AppModule, so without this reference, our TodoModule logic is unavailable. To create this link between AppModule and TodoModule, open the app.module.ts file. In this @Module decorator, add TodoModule to the imports array.

// app.module.ts
import  {  Module  }  from  '@nestjs/common';
import  {  AppController  }  from  './app.controller';
import  {  AppService  }  from  './app.service';
import  {  TodoModule  }  from  './todo/todo.module';

@Module({
    imports:  [TodoModule],
    controllers:  [AppController],
    providers:  [AppService],
})
export  class  AppModule  {}

If the development server is not still running, start it by running npm run start:dev. In the console output, you should see Nest wiring up the TodoModule and creating the TodoController route:

With your server still running, open the Postman application. Make a new request to the TodoController route at http://localhost:3000/todo. The controller will return a JSON response of an empty array, which we return in the findAll() method. We are now resolving HTTP requests to our TodoController and are ready to start adding the CRUD actions to the controller and service.

//todo.controller.ts
import  {
Controller,
Get,
} from  '@nestjs/common';
import  {  TodoService  }  from  './todo.service';
import  {  Todo  }  from  './todo.interface';

@Controller('todo')
export  class  TodoController  {
    constructor(private  readonly  todoService:  TodoService)  {}

    @Get()
    findAll():  Todo[]  {
        return  this.todoService.findAll();
    }
}

Ensure that the development server is still running in your command-line tool. Open Postman and make a GET request to http://localhost:3000/todo. In response, we’ll get an empty array (again).

create()

Add the POST route

With the data service method in place, we now need to enable an HTTP endpoint in our controller to call it. To do this, we will create a @Post route on the TodoController. Following REST standards, we’ll configure this route to be POST/todo. With @Post, @Put, and @Patch routes, the HTTP content body is used to transfer data objects, such as JSON, XML, or text. In this example, we will be sending a JSON object of a Todo item. For NestJS to parse and interpret the content body, the decorator @Body should be applied to the route method parameter. NestJS will apply JSON.parse() to the content and provide you a JSON object to work with. Since we expect this payload to match our Todo interface, we will type it as such.

//todo.controller.ts
import  {
Body,
Controller,
Get,
Post,
} from  '@nestjs/common';
import  {  Todo  }  from  './todo.interface';
import  {  TodoService  }  from  './todo.service';

@Controller('todo')
export  class  TodoController  {
    constructor(private  readonly  todoService:  TodoService)  {}

    @Post()
    create(@Body()  todo:  Todo):  void  {
        return  this.todoService.create(todo);
    }

    @Get()
    findAll():  Todo[]  {
        return  this.todoService.findAll();
    }
}

We can now send a POST request to http://localhost:3000/todo with a JSON payload to add it to the storage array. In Postman, do the following to set up your POST request:

1. Create a new request tab.

2. Change the GET value in the HTTP method dropdown to POST.

3. Enter the http://localhost:3000/todo value in the URL.

4. In the Body tab, select raw. In the dropdown to the right of binary, select “JSON(application/json)”.

In the text-area, supply the following body:

{
    "label":  "Create  an  awesome  API",
    "complete":  false
}

Send the request. Our response will be empty but with a status of 201 Created. We can now make a GET request to http://localhost:3000/todo again to see our new To-do item in our array with a set id of 1.

Quick aside: Adding the NestJS Logger

You may have noticed that there was no indication in our command-line console that the request was processed. While this is likely ideal in most scenarios, it would be very helpful for us to see that we are hitting the routes that we expect. NestJS provides a Logger implementation that makes it easy to add logging to your application. It is best practice to use this Logger class over the console log methods because the log messages are formatted cohesively, and the Logger allows you to swap out functionality or disable logging completely at a global level with a simple configuration in your main.ts file. To add logging to our controller, create a new instance of a Logger as a class-level variable on the TodoController. We will add a log statement to each of our methods as well.

// todo.controller.ts
import  {
Body,
Controller,
Get,
Logger,
Post,
} from  '@nestjs/common';
import  {  Todo  }  from  './todo.interface';
import  {  TodoService  }  from  './todo.service';

@Controller('todo')
export  class  TodoController  {
    private  readonly  logger  =  new  Logger(TodoController.name);

    constructor(private  readonly  todoService:  TodoService)  {}

    @Post()
    create(@Body()  todo:  Todo):  void  {
        this.logger.log('Handling create() request...');
        return  this.todoService.create(todo);
    }

    @Get()
    findAll():  Todo[]  {
        this.logger.log('Handling findAll() request...');
        return  this.todoService.findAll();
    }
}

Now when we make a request to either method, we will see items in our console such as:

[TodoController]  Handling  create()  request...
[TodoController]  Handling  findAll()  request...

findOne()

Add the GET route

We will now need to update the TodoController accordingly to enable this service method through an HTTP request. In todo.controller.ts, we will add a new @Get method, but this time we will take in a route parameter in the @Get decorator. Route parameters are variables inside of a given path. Routers use pattern matching to interpret and parse these paths and pluck out the variables in the provided route pattern. To access this variable in your NestJS route method, the @Param decorator is applied to the method argument, supplying the name of the route parameter. In our API, we want to supply the To-do object’s id as a route parameter, so we use the route pattern of :id to indicate a parameter variable with an id, and then use the @Param('id') decorator to hook the value into the method argument.

//todo.controller.ts
import  {
Body,
Controller,
Get,
Logger,
Param,
Post,
} from  '@nestjs/common';
import  {  Todo  }  from  './todo.interface';
import  {  TodoService  }  from  './todo.service';

@Controller('todo')
export  class  TodoController  {
    // ...

    @Get(':id')
    findOne(@Param('id')  id:  number):  Todo  {
        this.logger.log('Handling findOne() request with id='  +  id  +  '...');
        return  this.todoService.findOne(id);
    }
}

Since the storage array was cleared when we restarted our development server, we will do the following to test:

Send the POST request outlined in the create() section to create a new To-do item.

Send a GET request to http://localhost:3000/todo to see all the items in storage, including your new To-do.

Send a GET request to http://localhost:3000/todo/1, our new route, to retrieve the To-do item directly. Uh oh, the response is empty! Our command-line console says we hit the route with expected ID ([TodoController] Handling findOne() request with id=1...) . So, what happened? It is important to understand that by default, @Param values are strings. While we gave it the type of number, recall that TypeScript types are abstract and have no impact on the actual executing code; this is to say that the executing code had no way of knowing it should have parsed the route parameter id to a number. This is where the @Pipe decorator comes in.

To fix our findOne() endpoint, we need to add the ParseIntPipe to our @Param pipe.

//todo.controller.ts
import  {
Body,
Controller,
Get,
Logger,
Param,
ParseIntPipe,
Post,
} from  '@nestjs/common';
import  {  Todo  }  from  './todo.interface';
import  {  TodoService  }  from  './todo.service';

@Controller('todo')
export  class  TodoController  {
// ...
    @Get(':id')
    findOne(@Param('id',  ParseIntPipe)  id:  number):  Todo  {
        this.logger.log('Handling findOne() request with id='  +  id  +  '...');
        return  this.todoService.findOne(id);
    }
}

This will parse the value to a number and now our .find() method in our data service will find an exact equality against the Todo item we POST. Since the storage array was cleared when we restarted our development server, we will do the following to test:

Send the POST request outlined in the create() section to create a new Todo item.

Send a GET request to http://localhost:3000/todo to see all the items in storage, including your new Todo.

Send a GET request to http://localhost:3000/todo/1, our new route, to retrieve the To-do item directly. With this pipe in place, we’re now able to retrieve the To-do item.

Integrating User Interface

To test with this user interface, start up your development web server with npm run start:dev. In the user interface, try to create a new To-do item by typing in the “What’s next?” input and hitting enter. Uh oh, nothing happened!

Enable CORS

If you check out your browser console, you’ll see some errors about a missing Access-Control-Allow-Origin header. These errors are due to cross-origin reference sharing (CORS) restrictions that prevent web applications from making XHR requests to other domains. These restrictions are a security feature browsers have put in place using what are known as pre-flight requests and API response headers. Pre-flight requests are OPTION HTTP requests that are executed before the actual XHR request. Your browser automatically injects this request and if the restrictions specified in the response headers are met by the request parameters, then the actual request will continue as expected. By default, these restrictions prevent requests from any other origin; in our case, our server at localhost is preventing XHR requests from stackblitz.com. NestJS makes opening these CORS restrictions simple. In your main.ts file, call app.enableCors(); in the bootstrap() method. This will add headers to your controller route responses that enable cross-domain requests.

// main.ts

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

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

Resources

Building a platform: NestJS from the ground up | Kamil Mysliwiec | JS Poland 2018
Wanago Blog
Code with Vlad's book
Radiansys blog