Effective team collaboration is crucial for the success of the software development process. When development teams work cohesively, they can enhance productivity, and produce higher-quality software. Strong collaboration fosters better communication, reduces misunderstandings, and allows for more efficient problem-solving, ultimately leading to a more successful and agile development process.

In this article, I will discuss the advanced usage of common tools for development team collaboration: Git and Jira. By leveraging these common tools to their full potential, development teams can significantly enhance their productivity and workflow.

Advanced Git

Git is a powerful version control system that facilitates efficient code management and collaboration among developers. Common commands such as add, commit,push, and mergeare widely used by developers to track and share changes. However, Git offers a wide range of advanced features and commands that can further enhance productivity and streamline workflows.

Cherry-pick

One of the advanced Git commands that can greatly enhance your workflow is the cherry-pick command. This command allows you to apply changes introduced by existing commits from one branch onto another branch. It is particularly useful in scenarios where you need to selectively integrate specific changes without merging entire branches.

This may look similar to git merge. However, git merge will apply all changes from another branch to the current branch. Meanwhile git cherry-pick will only apply all changes in a single commit from another branch.

To use cherry-pick, you can follow this syntax:

git cherry-pick <commmit SHA> 

Commit SHA is the string hash to uniquely identify a commit. You can find the commit SHA by using git log. Alternatively, you can find the commit SHA from your repository website such as GitLab or GitHub.

You can also apply the cherry-picked changes without automatically commit it. This works well if you want apply changes from another commit with additional modification. To do this, you can use the — no-commit flag.

Revert

Another essential advanced Git command is git revert. git revert is used to undo changes introduced by previous commits. This command is particularly valuable when you need to safely undo changes in a collaborative environment without rewriting the commit history, as it creates a new commit that reverses the effects of a previous one.

To use revert, you can follow this syntax:

git revert <commit SHA>

Below are the comparison of the commit history before and after the revert. Note the new HEAD commit that reverts the prior commit.

Amend

Git allows you to make small changes to the most recent commit using git commit --amend command. This command is particularly useful for making small changes or corrections to the last commit without creating a new commit. Whether you forgot to include a file, need to update the commit message, or made a small mistake, git commit --amend helps you refine your commit history for better clarity and accuracy.

To amend a commit, you need to stage the changes you want to apply using git add.

After that, use git commit --amend to apply the changes to the latest commit.

Stash

Git allows you to temporarily storing changes that are not ready to be committed using git stash. It allows developers to save their work-in-progress state, switch to another branch, or address urgent tasks without committing incomplete or experimental changes to the repository. This command is particularly useful when you need to switch context quickly without losing your current modifications.

After making some changes, you can stash the changes by simply using the command git stash.

As you can see in the image above, the changes has disappeared and stashed. In this state, you can safely switch branch or make additional changes without affecting the stashed changes.

To see the stashes available, you can use the command git stash list.

To apply the changes in a stash, use the command git stash apply.

After the stash is not used anymore, you can delete the stash by using the command git stash drop.

Advanced Jira

Jira is a robust project management tool designed to help teams plan, track, and release software effectively. Jira provides valuable insights into team performance through its reporting and analytics features, allowing teams to identify areas for improvement and optimize their workflows effectively.

Sprint Insights

Jira provides sprint insights, offering your team valuable information about the ongoing sprint’s progress. This feature allows teams to stay informed about their current sprint’s status, including completed tasks and remaining work, encouraging them to manage their workload effectively to ensure successful sprint completion.

This feature also gives a Sprint burndown chart that provides alternative visual representation of the sprint progress.

In this sprint insight example, we can see that the current sprint is still ongoing with 54% of the tasks are in progress and no tasks are done yet.

Sprint Burndown Chart

Continuing on the sprint burndown chart, Jira offers a detailed burndown chart for current sprint. The y-axis of the chart shows the amount of story points left. The x-axis shows the timeline of current sprint. The orange line represented the story points left over time.

In this chart, it’s evident that no tasks have been completed since the start of the sprint. The burndown chart indicates that halfway through the sprint, no story points have been completed. Therefore, it’s crucial for the team to increase their pace to ensure that tasks are completed by the deadline.

Sprint Velocity

Jira also offers a sprint velocity report, which provides a comprehensive overview of the team’s performance over multiple sprints. This report calculates the average number of story points completed per sprint, allowing teams to assess their productivity and capacity for future sprints. By analyzing trends in sprint velocity, teams can make informed decisions about their workload allocation and sprint planning, ensuring a balanced and achievable pace of work. The sprint velocity report in Jira serves as a valuable tool for teams to continuously improve their performance and deliver projects on time and within scope.

Looking at the chart, we can see how the team did in the last three sprints. The gray bar shows the story points commitment at the start of the sprint while the green bar shows the story points completed at the end of the sprint. With the velocity report, the team can estimate how much work they can handle in the next sprint. This helps the team to better plan and allocate resources, ensuring a balanced workload and increased productivity in future sprints.

Cumulative Flow Diagram

Jira provides a cumulative flow diagram, a visual representation of how work progresses through various stages of the workflow over time. By tracking the number of tasks in each stage, teams can identify bottlenecks and monitor the flow of work throughout the project. This helps teams understand where work is piling up and where it’s flowing smoothly, allowing them to take proactive measures to improve efficiency and streamline their processes.

In this chart, we can see the issues in various stage of the development process over the course of the project. The stages includes “To Do”, “In Progress”, “In Review”, and “Done”. By comparing the growth rates of different colored sections, we can identify bottlenecks. For instance, in the chart provided, the purple section representing “To Do” tasks grows notably faster than others between May 15 and May 29. This indicates a bottleneck in the next stage, “In Progress.” To address this, the team needs to investigate the reasons behind the bottleneck, such as high workload or dependencies, and implement strategies to mitigate them.

In this article, we have discussed the advanced usage of Git and Jira as collaboration tools. With Git, developers can manage code changes with precision and agility such as using using cherry-pick, revert, amend, and stash. Meanwhile, Jira’s reporting features gives valuable insights for the team to plan, track, and optimize their workflow effectively. By embracing these advanced tools and practices, teams can streamline collaboration, boost productivity, and deliver high-quality software solutions in a dynamic and competitive landscape.

In my current project, I have to store users’ sensitive data in a database in a safe manner. After some exploration, I managed to create security functions tailor-made for my application needs. In this article, I want to share how I do it.

Encryption vs Hashing

First things first, let’s talk about encryption and hashing. Encryption and hashing are two fundamental techniques used to protect sensitive information. Encryption involves transforming data into a ciphertext format using an algorithm and a key, making it unreadable without the corresponding decryption key. This process allows for secure storage and transmission of data, as only authorized parties with the decryption key can access the original information.

On the other hand, hashing is a one-way process that converts data into a fixed-size string of characters, known as a hash value, using a hashing algorithm. Unlike encryption, hashing is irreversible, meaning that it cannot be decrypted to obtain the original data. Instead, it is commonly used for verifying data integrity and authentication, such as in password storage. Even small changes to the input data will result in vastly different hash values, making it an effective tool for detecting tampering or unauthorized modifications.

Scenario

My project is a NestJS project using Prisma ORM. I have to create user registration and login endpoints, which will work with sensitive data. The sensitive data is then stored in the User table, represented by this Prisma model:

model User {
  id       String @id @default(uuid())
  email    String @unique
  password String
  name     String
  phoneNo  String
}

In my case, I have to secure the email, password, and the phone number before storing it to the database. To achieve this, we can use encryption and/or hashing, depends on the nature of the data that needs to be secured.

The user’s password is highly confidential. Only the user is allowed to know the password. Furthermore, to maintain confidentiality, users are unable to retrieve their passwords after registration. Users are expected to memorize or store the password by themselves. In this case, we can hash the password before storing it. Hashing ensures that the resulting hash is irreversible, thus maintaining confidentiality. It also allows us to verify the correctness of the password when needed.

The email and phone number are also confidential, though not as sensitive as the password. In this scenario, both the email and phone number can be retrieved and displayed to the user. To achieve this, we can encrypt the data before storing it. When we retrieve the data, we decrypt it before sending it back to the user.

Unsecured Register and Login

Upon registration, user have to provide all data, and on login, user have to provide email and password. Therefore, we can create DTOs as follows:

export class RegisterDTO {
  email: string;
  name: string;
  password: string;
  phoneNo: string;
}

export class LoginDTO {
  email: string;
  password: string;
}

Next, we create controller and service functions to process the request. The API endpoint will be at auth/register and auth/login.

// controller
import { Body, Controller, Post } from '@nestjs/common';
import { AuthService } from './auth.service';
import { LoginDTO, RegisterDTO } from './dto';

@Controller('auth')
export class AuthController {
  constructor(private readonly authService: AuthService) {}

  @Post('register')
  async register(@Body() dto: RegisterDTO) {
    await this.authService.register(dto);

    return { message: 'Successfully register' };
  }

  @Post('login')
  async login(@Body() dto: LoginDTO) {
    const user = await this.authService.login(dto);

    return { message: 'Successfully login', ...user };
  }
}

// service
import { BadRequestException, Injectable } from '@nestjs/common';
import { LoginDTO, RegisterDTO } from './dto';
import { PrismaService } from 'src/prisma/prisma.service';

@Injectable()
export class AuthService {
  constructor(private readonly prisma: PrismaService) {}

  async register(registerDTO: RegisterDTO) {
    const user = await this.prisma.user.findUnique({
      where: {
        email: registerDTO.email,
      },
    });

    if (user) {
      throw new BadRequestException('User already exists');
    }

    await this.prisma.user.create({
      data: {
        ...registerDTO,
      },
    });
  }

  async login(loginDTO: LoginDTO) {
    const user = await this.prisma.user.findUnique({
      where: {
        email: loginDTO.email,
      },
    });

    if (!user) {
      throw new BadRequestException('Incorrect email or password');
    }

    if (user.password !== loginDTO.password) {
      throw new BadRequestException('Incorrect email or password');
    }
  }
}

Up until this point, we have not created any security related features yet. All data is stored as-is in the database.

Secured Register and Login

Next, let’s create security related function for hashing and encryption. I will use bcrypt library for hashing and the built-in crypto library for encryption.

First, let’s create the hash function. Hashing with bcrypt is pretty simple. All we need is the data and a salt. A salt is a random string of data that is added to the input of a hash function before it is hashed. Salting is used to add a noise to our data.

// security.ts
import { hash as bcryptHash } from 'bcrypt';

export const hash = async (data: string) =>
  bcryptHash(data, process.env.HASH_SALT as string);

In my case, I will use a salt stored in the HASH_SALT environment variable to ensure a deterministic behavior. Why? More on this later.

bcrypt expected a salt with specific format to ensure that it can properly generate secure hash values and handle the comparison correctly. To achieve this, we can use the genSalt or genSaltSync functions provided by bcrypt:

Trying to use a salt without adhering the format will resulting in an error.

For comparing data and a hash, bcrypt has provided a compare function that we will use later.

Moving on to encryption. For encryption, we need a password to encrypt our data. This allows us to decrypt our encrypted data and retrieve our original data. This is the custom encrypt-decrypt function I come up with.

// security.ts
import {
  createCipheriv,
  createDecipheriv,
  randomBytes,
  randomFill,
  scrypt,
} from 'crypto';

export const _encrypt = async (data: string): Promise<string> => {
  const algorithm = 'aes-192-cbc';
  const salt = randomBytes(8).toString('hex');

  return new Promise((resolve, reject) => {
    scrypt(process.env.ENCRYPT_PASSWORD as string, salt, 24, (err, key) => {
      if (err) reject(err);

      randomFill(new Uint8Array(16), (err, iv) => {
        const ivHex = Buffer.from(iv).toString('hex');
        if (err) reject(err);

        const cipher = createCipheriv(algorithm, key, iv);

        let encrypted = cipher.update(data, 'utf8', 'hex');
        encrypted += cipher.final('hex');

        const result = `${salt}|${ivHex}|${encrypted}`;
        resolve(result);
      });
    });
  });
};

export const _decrypt = async (encryptedData: string): Promise<string> => {
  const algorithm = 'aes-192-cbc';

  return new Promise((resolve, reject) => {
    const [salt, ivHex, encrypted] = encryptedData.split('|');

    if (!salt || !ivHex || !encrypted) reject(new Error('Invalid data'));

    const iv = Buffer.from(ivHex, 'hex');

    scrypt(process.env.ENCRYPT_PASSWORD as string, salt, 24, (err, key) => {
      if (err) reject(err);

      const decipher = createDecipheriv(algorithm, key, iv);

      let decrypted = decipher.update(encrypted, 'hex', 'utf8');
      decrypted += decipher.final('utf8');

      resolve(decrypted);
    });
  });
};

export const encrypt = async (data: string) => {
  const encrypted = await _encrypt(data);
  const hashed = await hash(data);

  return `${hashed}|${encrypted}`;
};

export const decrypt = async (data: string) => {
  const [_, ...rest] = data.split('|');
  const encrypted = rest.join('|');

  return await _decrypt(encrypted);
};

• I’m using aes-192-cbc algorithm. No specific reason for this, just following the example on the documentation page. You can choose to use another encryption algorithm.
• The _encrypt function contains the data encryption logic. Upon receiving a data, the function will create a random salt to be added to the input. After that, a random initialization vector (IV) is created to initialize the encryption process. The vector ensures that the same data encrypted with the same password produces different results. The data is encrypted using the password stored as ENCRYPT_PASSWORD environment variable. At the end, I merged the salt, IV, and the encrypted text into one with | as separator. This is needed for the decryption process.
• The _decrypt function contains the data decryption logic. Knowing that the encrypted data is formatted as ${salt}|${ivHex}|${encrypted}, I splitted the string to obtain the salt, IV, and the encrypted text. Using the provided salt, IV, and the encryption password, I managed to decrypt the data and returned the original value.
• The encrypt and decrypt function is not necessarily needed. These functions are used to combine hashing with encryption. In my case, I will encrypt the user’s email before storing to the database. However, I still need the capability of querying the database based on the user’s email. Using only encryption won’t work, because the encrypted data is always different thanks to the random salt. This is why I created a hash function with deterministic behavior. By appending the hash result of the plain data, I can query the encrypted data by it’s hash. The final format of my decrypted data is ${hash}|{salt}|${ivHex}|${encrypted}
• The decrypt function is used to remove the hash from the encrypted data, and then forwarding the rest of the data to the _decrypt function for the real decryption.

Using those functions, I can update my service functions to ensure the security of the data.

// service
import { BadRequestException, Injectable } from '@nestjs/common';
import { LoginDTO, RegisterDTO } from './dto';
import { PrismaService } from 'src/prisma/prisma.service';
import { encrypt, hash } from './security';
import { compare } from 'bcrypt';

@Injectable()
export class AuthService {
  constructor(private readonly prisma: PrismaService) {}

  async register(registerDTO: RegisterDTO) {
    const emailHash = await hash(registerDTO.email);

    const user = await this.prisma.user.findFirst({
      where: {
        email: {
          startsWith: `${emailHash}|`,
        },
      },
    });

    if (user) {
      throw new BadRequestException('User already exists');
    }

    const passwordHash = await hash(registerDTO.password);
    const emailEncrypt = await encrypt(registerDTO.email);
    const phoneNoEncrypt = await encrypt(registerDTO.phoneNo);

    await this.prisma.user.create({
      data: {
        name: registerDTO.name,
        password: passwordHash,
        email: emailEncrypt,
        phoneNo: phoneNoEncrypt,
      },
    });
  }

  async login(loginDTO: LoginDTO) {
    const emailHash = await hash(loginDTO.email);

    const user = await this.prisma.user.findFirst({
      where: {
        email: {
          startsWith: `${emailHash}|`,
        },
      },
    });

    if (!user) {
      throw new BadRequestException('Incorrect email or password');
    }

    if (await compare(loginDTO.password, user.password)) {
      const { email, name, phoneNo } = user;
      return {
        email,
        name,
        phoneNo,
      };
    }

    throw new BadRequestException('Incorrect email or password');
  }
}

For comparison, here are the unsecured and secured data inside the database.

And that’s it! This is my first time delving into data hashing and security. I have so much to learn regarding these topics. While writing this article, I realized that the encryption format I used may not be the best practice. I should have stored the hash and encrypted data in separate columns to improve the database query performance. Nevertheless, I want to share how I originally did it. Learning is a journey, and without encountering bad practices, I won’t ever reach the best practices. If you found another way of doing it, feel free to share it with me.

References:

• https://nodejs.org/api/crypto.html#class-decipher

In my current project, I had to set up Sentry for NestJS. Initially, I encountered some difficulties because Sentry doesn’t offer a specific guide for NestJS apps like it does for other frameworks such as Express or Django. However, after some exploration, I managed to set it up successfully for my project. In this article, I want to share how I set up Sentry for my NestJS app and integrating Sentry alerts with Discord.

What is Sentry?

Sentry is an error tracking and monitoring platform designed to help developers identify, diagnose, and fix issues in their applications. With Sentry, developers can gain deep insights into errors and exceptions occurring in their codebase across various platforms and frameworks. By providing real-time error reporting, stack traces, and detailed context about each issue, Sentry empowers teams to proactively manage and resolve bugs before they impact users. Its intuitive interface, customizable alerting system, and extensive integrations make it a popular choice for developers looking to maintain the stability and reliability of their software applications.

Sentry offers a range of pricing plan for using their product. In this article, I’m using the free Developer plan. This plan allows us to use basic Sentry services free of charge. Additionally, new users will get 14-day trial of the Business plan, which gives access to advanced services.

Setting up Sentry

First things first, create a Sentry account if you don’t have one yet. You have to fill out an organization name for your account. Upon creation, you will gain access to org-slug.sentry.io. This page provides access to your Sentry projects. This article will use org-slug.sentry.io as a placeholder for your Sentry page URL.

Go to org-slug.sentry.io/project/new to create a new Sentry project. As you can see, there are no NestJS option for the Choose your platform section. Choose Node.js as your platform and then fill out your project name. Leave out other fields as default and then click Create Project. Choose skip when asked to select a specific framework.

After your project is created, you will be taken to a page containing guide for setting up Sentry for your app. We won’t follow the guide as it is for setting up our NestJS app.

Assuming you already have a NestJS app, run yarn add @sentry/node @nestjs/config to install the required dependencies. The @nestjs/config library is needed to ensure environment variables is successfully read.

Take note of the dsn field value and store it as an environment variable SENTRY_DSN. This value will be used to connect your app to your Sentry project. Don’t store this value directly on your code as this is a sensitive value.

Setting up NestJS

Basically, we will set up our NestJS app to send any unhandled error to Sentry, which is the 5xx. To achieve this, we will take advantage of the Exception Filters provided by NestJS. We will create a custom filter that acts as a middleware. The middleware will inform Sentry of any 5xx errors before the error response is returned to the user.

In your NestJS app, create a folder sentry inside src. Create a file called sentry.filter.ts inside it. Fill out the file with:

import { Catch, ArgumentsHost, HttpException } from '@nestjs/common';
import { BaseExceptionFilter } from '@nestjs/core';
import * as Sentry from '@sentry/node';

@Catch()
export class SentryFilter extends BaseExceptionFilter {
  catch(exception: HttpException, host: ArgumentsHost) {
    const status = exception.getStatus();

    if (status >= 500) {
      Sentry.captureException(exception);
    }
    super.catch(exception, host);
  }
}

The if statement is important because, without it, any 4xx errors will also be sent to Sentry. We don’t want this behavior because 4xx errors are handled errors and not our focus.

Inside the app.module.ts, imports ConfigModule to ensure environment variables are read on time.

import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { ConfigModule } from '@nestjs/config';

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

Inside your bootsrap function inmain.ts file, add the Sentry configuration:

import { HttpAdapterHost, NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import * as Sentry from '@sentry/node';
import { SentryFilter } from './sentry/sentry.filter';

async function bootstrap() {
  Sentry.init({
    dsn: process.env.SENTRY_DSN,
  });

  const app = await NestFactory.create(AppModule);

  const { httpAdapter } = app.get(HttpAdapterHost);
  app.useGlobalFilters(new SentryFilter(httpAdapter));

  await app.listen(3000);
}
bootstrap();

Congrats! The NestJS app have been successfully set up with Sentry. To test it, we can create a controller that throws an error. For example:

import { Controller, Get, InternalServerErrorException } from '@nestjs/common';

@Controller('error')
export class ErrorController {
  constructor() {}

  @Get()
  async error() {
    throw new InternalServerErrorException({
      message: 'This is a test error',
    });
  }
}

When the URL /error is called, an error will be thrown and Sentry will catch it and create an issue.

By clicking the issue, you will see the detailed information about the issue. At the top, you can see the general information about the issue.

Scrolling for a bit, you can see the stack trace for the issue.

At the very bottom, you’ll see the contexts for the issue.

If you‘re not aware yet, calling the URL /error multiple times won’t create additional issue. Instead, it will adds to the event count of the original issue. Below, I have created more test errors and invoked it multiple times.

Configuring Profiling

Sentry also provide profiling to monitor the performance of our application. If you haven’t set it up, click the Profiling button on the sidebar, then follow the guide for setting it up.

On the Profiling page, you can see various reports regarding your app. At the top, you can see the profiles by duration percentiles.

At the bottom, you can see the transactions that your app have completed.

You can click the transactions and see the details for each transaction.

By clicking the View Transaction Summary button, you can see the detailed information regarding that transaction, such as the duration breakdown and the transaction spans.

Configuring Discord Alerts

By default, Sentry will send an alert email to your registered email to inform you each time a new issue is created.

Sentry allows you to configure this behavior or add additional alert channel, such as sending message to Discord. To achieve this, head to org-slug.sentry.io/settings/integrations/discord/ and click Add Installation. A modal will shows up to let you choose a Discord server. Sentry bot will then join your chosen server.

Go to org-slug.sentry.io/alerts/rules/ and edit your project’s rules. You will see some information about the alert conditions such as events, filters, and actions.

To send an alert to your Discord server, click Add action... and select Send a Discord notification. This option will only available if you have successfully add a Discord installation in the previous step. Choose your server and fill out the channel ID for your desired channel. You can obtain your channel ID by right clicking your Discord channel and click Copy Channel ID.

Click Send Test Notification to test out your Discord channel alert. If the test is success, you will receive a message in your channel like this:

You can add more configuration to your rule if you want. If you’re done, don’t forget to click Save to save your rule.

Another call to the /error URL will send a notification to the channel:

Congrats! You have successfully set up a Discord alert channel for Sentry!

With Sentry’s powerful error tracking capabilities, we can easily identify, diagnose, and resolve issues in our codebase, ensuring a smoother and more reliable user experience. Additionally, we can easily receive alert notifications from various options provided by Sentry. Hopefully, this article will help you use Sentry effectively in your app.

References:

• https://dev.to/marcelozapatta/how-to-integrate-sentry-in-nestjs-3ema

With the advancements of tools that helps developers to generate code, it’s tempting to believe that coding is “easy”. While anyone can string together lines of code to create a functioning program, developing software that is not just functional but also maintainable and readable requires skill, experience, and discipline.

A good developer knows what will happen if they are neglecting code quality. Bad code not only introduces inefficiencies but also produces possible source of issues. These issues manifest in many forms, such as code smells. Code smells are subtle indications of deeper underlying problems.

To address these challenges, code analysis tools such as SonarQube emerged. SonarQube offers a comprehensive platform for code quality analysis, providing insights into various aspects of code health and offering actionable suggestions for improvement. By leveraging static code analysis techniques, SonarQube not only identifies potential issues but also helps in enforcing coding standards and promoting best practices to avoid future issues.

In this article, we will explore some features of SonarQube and how to set it up for a NestJS application.

Setting Up Credentials

Before configuring your app with SonarQube analysis, you have to create an account in a SonarQube platform. After obtaining an account, create or connect a project to your source code repository and obtain your project key.

Next, obtain an access token for your account. This token will be used to authenticate access to your SonarQube project. This token can be obtained from My Account > Security tab.

Configuring SonarQube

To set up SonarQube for NestJS, we can use sonarqube-scanner package to make things easier. Add the package to the development dependencies. For example using yarn:

yarn add -D sonarqube-scanner

The analysis itself is best to incorporated in a CI/CD pipeline. Therefore, the source code analysis will become automated. To achieve this in Gitlab CI/CD for example, we can use this job yml:

sonar:
  stage: sonar
  image: node
  before_script:
    - yarn
  script:
    - yarn sonar-scanner -Dsonar.host.url=$SONAR_HOST -Dsonar.login=$SONAR_LOGIN -Dsonar.projectKey=$SONAR_PROJECT_KEY -Dsonar.projectName=$SONAR_PROJECT_NAME -Dsonar.sources=src -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info
  dependencies:
    - test

There are some properties and variables used in the command

• sonar.host.url is used to define the location of the SonarQube host. For example, I’m using my university’s SonarQube platform, therefore I set the SONAR_HOST variable as https://sonarqube.cs.ui.ac.id.
• sonar.login is used to authenticate the analysis request. Set your SONAR_LOGIN variable as the access token that have been generated earlier.
• sonar.projectKey is used to identify a project to connect to. Set your SONAR_PROJECT_KEY as the project key obtained when creating a SonarQube project.
• sonar.projectName is used to set the name of your project in the SonarQube GUI. Set the SONAR_PROJECT_NAME variable as the name you desire. This variable is optional.
• sonar.sources is used to tell SonarQube where the source code that needs analysis is located. For NestJS projects, this usually in the src folder.
• sonar.javascript.lcov.reportPaths is used to pass the coverage report of your JS/TS project test result to SonarQube. For example, if you are using jest with default setting, the coverage report will be available in coverage/lcov.info.

For the testing coverage report, you can use this job yml before the sonar job:

test:
  stage: test
  image: $NODE_IMAGE
  before_script:
    - yarn
  script:
    - yarn jest --ci --coverage --verbose
  coverage: '/All files[^|]*\|[^|]*\s+([\d\.]+)/'
  artifacts:
    paths:
      - coverage/ 

The artifacts paths is needed to store and forward the coverage result to the next.

Here is the final yml:

test:
  stage: test
  image: $NODE_IMAGE
  before_script:
    - yarn
  script:
    - yarn jest --ci --coverage --verbose
  coverage: '/All files[^|]*\|[^|]*\s+([\d\.]+)/'
  artifacts:
    paths:
      - coverage/

sonar:
  stage: sonar
  image: node
  before_script:
    - yarn
  script:
    - yarn sonar-scanner -Dsonar.host.url=$SONAR_HOST -Dsonar.login=$SONAR_LOGIN -Dsonar.projectKey=$SONAR_PROJECT_KEY -Dsonar.projectName=$SONAR_PROJECT_NAME -Dsonar.sources=src -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info
  dependencies:
    - test

Don’t forget to add the necessary variables as pipeline variables.

Push your code and job script and wait the pipeline to run. On success, open your SonarQube platform to see the analysis.

SonarQube Analysis

After successfully setting up SonarQube for our code, we can start analysing. There are a lot of metrics in SonarQube that can be used to analyse your code.

Quality Gate

A Quality Gate is a set of measure-based boolean conditions. It helps to know immediately whether your projects are production-ready. Each project’s Quality Gate status is displayed prominently on its homepage.

In the example above, the Quality Gate Status is Failed because the project has 4.76% of Duplicated Lines. This exceeds the acceptable condition for line duplications (3.0% by default).

SonarQube also tells us where the line duplications happens. In the example above, the code block highlighted by the vertical gray box (starting from line 66) is duplicated by lines 169–210.

Code Smells

The code smells tab give you all code smells detected by SonarQube. By clicking one of the code smells, SonarQube will give us the detailed explanation, such as code smells description, location, the reason why the code is detected as code smells, non compliant code example, and the compliant code example.

The detailed explanations helps us to learn more about code smells and prevent aditional code smells in the future.

Code Coverage

As we have set up before, SonarQube also shows the coverage results of our tests.

This page shows the total coverage of our code and which files is not fully covered yet.

In the example above, the fillSurvey function has lines that are not fully covered by tests yet. The lines which highlighted by vertical red block are the lines that are not covered by tests.

Refactoring

Of course, after analysing our code, we have to do some refactoring to resolve the issues highlighted by SonarQube. Why would we do code analysis if we don’t want to fix our code?

In the example above, after some refactoring and reanalyse the code I managed to pass the Quality Gate and reduce some code smells. The activity graph can be a good indicator to see our source code analysis result history.

Ensuring code quality is not just a matter of writing functional code. It’s about fostering a culture of excellence, where maintainability, readability, and reliability are important. Using tools like SonarQube helps developers teams to identify and address code smells and other quality issues, ultimately enhancing the long-term sustainability of the software projects.

In today’s fast-changing world of software development, Docker has emerged as one of the front runner in shipping applications. It’s like a magic box where you can put all the stuff your app needs to run, making it easy to move around and work on different computers. In this article, we will explore how to containerize a NestJS app using Docker and utilize some of Docker mechanisms to reduce image build time and size.

First Things First, What is Docker?

Docker is a platform for developing, shipping, and running applications in an isolated environment. With Docker, we can isolate our application together with its dependencies. Therefore, we ensure the consistency between different environments and reduce the “It works on my machine!” problems.

Docker utilizes operating system level virtualization to create its containers. The Docker containers leverage the host operating system’s kernel and share resources more efficiently. This way, the created containers are lightweight and faster to start when compared with the traditional hardware virtualization.

Docker Container

Docker Container is an isolated instance of an application, wrapped together with its dependencies. We can interact with the container using Docker CLI or other interfaces provided by Docker. Docker Container is created based on Docker Image and other options given when the container is created.

Docker Image

Docker Image is a template for creating Docker Containers. One way of creating Docker Image is using Dockerfile. Dockerfile is a file containing instructions to create an Image based on the code repository where the file is located. Docker Image can be stored in an image registry, such as Docker Hub.

Containerizing NestJS

Docker can be used to containerized many things. In this section, we will explore how to create a Dockerfile for NestJS application and publish the image to the Docker Hub for later use.

The Project

Before creating the Dockerfile, we have to identify our NestJS application first. Let’s assume that we use nest-cli to bootstrap our project, using yarn package management, and will listen on port 3000.

Dockerfile

We will use Dockerfile to containerize our application. Usually, Dockerfile is placed at the root directory of our project. We will create a multi stage Dockerfile with three stages:

• base: for declaring the base image.
• build: for building the source code into a runnable application.
• production: for defining the final image definition.

Why 3 stages? Although single stage Dockerfile will work fine, by using 3 stages, we can minimize the time taken to build our image by utilizing Docker caching mechanism. We also can reduce the size of the resulting image size. We will see more about these benefits later.

First Stage: base

This stage is only used to declare the base image for our resulting image. The image declared in this stage will be used by other stages.

FROM node:alpine AS base

Each line of the Dockerfile is an instruction for Docker on how to build our app into an image. This stage only contains one instruction.

• The FROM keyword is used to declare a stage. FROM node:alpine as base basically means that we create a stage called base using node:alpine image as the base image. The node:alpine image itself is a lightweight Linux distribution with node runtime environment installed.

Why do we create this single line stage? Each line in a Dockerfile creates a layer in the image container. Docker caches these layers to speed up subsequent builds. By declaring the base image in the first stage, Docker can cache this stage’s layers. This means that if the Dockerfile doesn’t change and the base image is already available locally, Docker can reuse the cached layers for this stage in subsequent builds. This caching mechanism speeds up the build process by avoiding redundant operations.

Second Stage: build

This stage will focus on building our source code into a runnable application. With nest-cli, we can build our app using the build command.

FROM base AS build

WORKDIR /usr/src/app
COPY package.json yarn.lock ./
RUN yarn install --no-lockfile
COPY . .
RUN yarn build

In this stage we have much more instruction than previous stage.

• FROM base AS build means that this stage is derived from the base stage. By using the base stage instead of manually using the node:alpine image again, Docker can reuse the cached layer across stages.
• The WORKDIR keyword is used to determine the location of our working directory inside the container. This instruction set our working directory to /usr/src/app.
• The COPY <src> <src> ... <dest> instruction is used to copy folder/files declared as src and adds them to the filesystem of the container at the path <dest>. COPY package.json yarn.lock ./ means that the package.json and yarn.lock from local directory is copied to the working directory of the container.
• The RUN keyword is used to run a command inside the container. RUN yarn install --no-lockfile will run the command yarn install --no-lockfile. The command itself will install the dependencies defined by package.json and yarn.lock, but won’t update the yarn.lock to avoid dependency mismatch between production and development environment. This command will generate the node_modules folder in our root directory, which contains our application dependencies. This folder is needed to run our code later.
• COPY . . will copy the rest of our source code to the container. The source code is needed for building our application.
• Lastly, we use RUN yarn build to build our application. By default, this command will generate the dist folder in our root directory. This folder contains the production ready application code.

You may be wondering why we separate copying the package.json and yarn.lock from the rest of our code. Once again, this is to utilize Docker caching mechanism. Those two files are much less volatile than the rest of our source code. Docker caching mechanism is smart enough to not run the yarn install command when those two files are not changed and therefore reduce the time needed to build our image. If we copy all file at once and then run yarn install, any file changes will force Docker to reinstall our dependencies.

Third Stage: production

This stage will focus on managing our production application image size. Because this is the last stage, the resulting image will be created based on the container from this stage.

FROM base AS production

COPY --from=build /usr/src/app/node_modules ./node_modules
COPY --from=build /usr/src/app/dist ./dist
COPY --from=build /usr/src/app/package.json .
COPY --from=build /usr/src/app/yarn.lock .

CMD ["sh", "-c", "yarn start:prod"]

• This stage use COPY keyword to copy production ready files that is needed for minimal size image. The file is copied from the previous build stage.
• The CMD keyword is used to provide defaults for an executing container. When our container is started, the container will run yarn start:prod on the default shell. The yarn start:prod itself is a command created by nest-cli to start the production application.

And that’s concludes our Dockerfile! Here is the full version:

FROM node:alpine AS base

FROM base AS build

WORKDIR /usr/src/app
COPY package.json yarn.lock ./
RUN yarn install --no-lockfile
COPY . .
RUN yarn build

FROM base AS production

COPY --from=build /usr/src/app/node_modules ./node_modules
COPY --from=build /usr/src/app/dist ./dist
COPY --from=build /usr/src/app/package.json .
COPY --from=build /usr/src/app/yarn.lock .

CMD ["sh", "-c", "yarn start:prod"]

Building the image

After the Dockerfile is complete, we have to build the image using command docker build -t <IMAGE_NAME> .. This commands tell Docker to build an image based on Dockerfile located in the current (.) directory and give it a name IMAGE_NAME.

After the image is built, we can push the image to Docker Hub using command docker push <DOCKER_IMAGE_NAME>. Make sure that you have a Docker Hub account and login to your account using docker login.

To run a container based on your image, we can use command docker run -d --name <CONTAINER_NAME> -p 8000:3000 <DOCKER_IMAGE_NAME>. This commands will pull image <DOCKER_IMAGE_NAME> (if one is not available locally) and create a container called <CONTAINER_NAME>. The -d flag tells Docker to run the container in detached mode (in the background). The -p flag is used to maps port 8000 of your machine to port 3000 of the container, which is where your application will listens to. Therefore, to access your application from your local machine, you have to access localhost:8000.

What’s Next?

Your image is published to Docker Hub and ready to use. You can use it to deploy your application to various platform or share it with your team to improve development workflow. You also can automate the image building stage in a CI/CD pipeline.

Docker’s efficiency and versatility make it the go-to tool for developers looking to streamline their workflow and deploy applications with ease. With its robust features and widespread adoption, Docker empowers teams to build, ship, and run applications reliably across any environment. Embracing Docker not only enhances productivity but also future-proofs your development process.

References

• https://docs.docker.com/get-started/overview/
• https://docs.docker.com/reference/dockerfile/

Software development is a team effort. As teams navigate the complexities of management, coding, and communication, having access to the most effective tools can help reduce confusion and boost the productivity of the team. In this article, I will share what tools my team uses in our current project.

Scrum Board

Scrum Board is used as a project management tools in a project using Scrum methodology. This board is used to plan and manage the project in a sprintly basis. There are many columns in the board that gives various information, such as Task, Status, Assignee, Due Date, and Story Point.

There are many Scrum Board tools out there, such as Jira, ClickUp, and Notion, which is more of a note tools, but can be used as a Scrum Board. There are also boards provided by code repository such as GitHub Projects and GitLab Issues Board.

Using Scrum Board, team members can effectively plan their sprint in a centralized location. They can also track their own and other’s progress, which helps improve team’s accountability.

Each task also have a detail page, which can be filled with more detailed information. Team members can add notes and/or comments to the page to specify the detailed information for the task.

Code Management

Every project have their own source code repository. But a good repository is more than just storing code in a repository. It’s storing code with a standard.

For example, my team uses a format for commit messages. We uses tag [RED], [GREEN], [REFACTOR] for TDD commits and (file) to tell others which file is modified. With a commit messages format, our team managed to tidy up our commits, and therefore easier for us to review our commit history.

Our team also review each other codes when someone create a Merge Request. The merge request needs to be approved by other member first before it can be merged. We also communicate any comment/review through the merge request comment section. This way, we can centralized our communication for that merge request. Using the comment section also allows us to point out specific code that needs improvement.

Communication Platform

Our team uses two different communication platforms, LINE and Discord. We uses LINE for non technical communication, such as generic information and communication with TA. On the other hand, we uses Discord for technical communication, such as issues and GitLab notification.

We uses Discord webhook feature to connect our GitLab repository to Discord. Therefore, any commit, merge request, comments, and pipeline activity in the repository is forwarded as a notification to Discord. This way, we can monitor the repository activity asynchronously.

Having some tools to support your team development is crucial to improve communication, productivity, collaboration, and avoid any confusion. This article just provides some example what tools can be used. Of course, there are some better tools out there, but this is how our team works. How about yours?

NestJS is one of the most popular framework for building backend application, offering developers an elegant and structured environment for building scalable server-side solutions. One of the fundamental aspects of a backend application is the ability to connecting to and querying databases. Within NestJS environment, many approaches exists for this purpose. One such method, gaining popularity for its simplicity and efficiency, is integrating Prisma for database interactions.

Rather than exploring the broader landscape of using Prisma, our focus lies in the process of designing and creating robust unit tests for a NestJS application that utilizes Prisma for database operations. For this article, we will use Jest as our testing framework.

Before starting, let’s define our example project configuration.

Prisma Schema

We will create a simple schema for this example. One table User is sufficient.

// schema.prisma
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  username String @id
  name     String
}

PrismaModule

This module will allows us to inject our PrismaService to other modules. PrismaService will act as an abstraction for PrismaClient from Prisma.

// prisma.service.ts
@Injectable()
export class PrismaService
  extends PrismaClient
  implements OnModuleInit, OnModuleDestroy
{
  async onModuleInit() {
    await this.$connect();
  }

  async onModuleDestroy() {
    await this.$disconnect();
  }
}

UserModule

This module is our test subject. UserService will have PrismaService as a dependency that will be used to query the database.

// user.service.ts
@Injectable()
export class UserService {
  constructor(private readonly prismaService: PrismaService) {}

  async getUserByUsername(username: string) {
    const user = await this.prismaService.user.findUnique({
      where: {
        username,
      },
    });

    if (!user) {
      throw new NotFoundException({
        message: 'User with the given username not found',
      });
    }

    return user;
  }

  async getAllUser() {
    const allUser = await this.prismaService.user.findMany({});

    return allUser;
  }
}

We have two simple functions, the first one is to find user based on username, and the second one is to find all users.

With the configuration complete, let’s get to the unit testing. Our main goal is to test the functions within UserService. But, as you can see, our UserService functions are dependent on the PrismaService. We need to isolate the functions from PrismaService. Why? There are a lot of reason to this:

1. By isolating the function from its dependencies, we can focus solely on the logic of our function.
2. Our test can be designed more efficiently because we don’t have to deal with the complexity of external dependency, especially in Test Driven Development.
3. Introduces more control to our input and output prediction/assertion. Our test environment will be more stable and reproducible.

How do we isolate the function? We can do so by stubbing or mocking the dependency.

Stub VS Mock

Stub and mock are two core techniques in unit testing. Both are used for isolating a component for it’s dependency.

Stubbing is a technique where we isolate our function from its dependency by replacing the actual implementation of the dependency with a simplified, predefined behavior. This allows us to simulate the response or result of our dependency.

Meanwhile, mocking is a technique similar to stubs. It involves replacing dependencies, but it goes a step further by recording interactions with the mocked dependency. By using a mock, we can verify various aspects of the interaction inside our function, such as the number of times our dependency is called, the parameters it’s called with, and more.

In Jest, its pretty easy to stubbing and mocking. Jest already provide us with a built-in mock utility, which can be used to both stubbing and mocking dependency.

Creating Unit Test

Let’s start creating simple test structure for our functions.

// user.spec.ts
describe('UserService', () => {
  let userService: UserService;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [UserService],
    }).compile();

    userService = module.get<UserService>(UserService);
  });

  describe('getUserByUsername', () => {
    it('should return user if exists', async () => {
      const existingUser = {
        username: 'existing-user',
        name: 'Existing User',
      };

      const result = await userService.getUserByUsername(existingUser.username);
      expect(result).toEqual(existingUser);
    });

    it('should throw NotFoundException if user not exists', async () => {
      await expect(
        userService.getUserByUsername('non-existing-user'),
      ).rejects.toThrow(NotFoundException);
    });
  });

  describe('getAllUser', () => {
    it('should return all user', async () => {
      const allUser = [
        {
          username: 'user1',
          name: 'User 1',
        },
        {
          username: 'user2',
          name: 'User 2',
        },
      ];

      const result = await userService.getAllUser();
      expect(result).toEqual(allUser);
    });

    it('should return empty array if there are no users', async () => {
      const result = await userService.getAllUser();
      expect(result).toEqual([]);
    });
  });
});

This is a pretty standard unit test for a NestJS component. Next, let’s start mocking the PrismaService.

Simple Mocking

This is the most straightforward method for mocking a dependency. We can create an object that mirrors the structure of our actual dependency, we essentially create a mock. For our current PrismaService, we have a user table. We also called two functions from the UserService, that isfindUnique and findMany. So, we can create a mock object such as:

const prismaMock = {
  user: {
    findUnique: jest.fn(),
    findMany: jest.fn(),
  },
};

The jest.fn() is used to declare a mock function. This function will allows us to mock a response and do assertions. Incorporating that mock to our test, we can create a working mock behavior.

const prismaMock = {
  user: {
    findUnique: jest.fn(),
    findMany: jest.fn(),
  },
};

describe('UserService', () => {
  let userService: UserService;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [
        UserService,
        {
          provide: PrismaService,
          useValue: prismaMock,
        },
      ],
    }).compile();

    userService = module.get<UserService>(UserService);

    prismaMock.user.findUnique.mockClear();
    prismaMock.user.findMany.mockClear();
  });

  describe('getUserByUsername', () => {
    it('should return user if exists', async () => {
      const existingUser = {
        username: 'existing-user',
        name: 'Existing User',
      };

      prismaMock.user.findUnique.mockResolvedValue(existingUser);

      const result = await userService.getUserByUsername(existingUser.username);
      expect(result).toEqual(existingUser);
      expect(prismaMock.user.findUnique).toBeCalledTimes(1);
      expect(prismaMock.user.findUnique).toBeCalledWith({
        where: { username: existingUser.username },
      });
    });

    it('should throw NotFoundException if user not exists', async () => {
      prismaMock.user.findUnique.mockResolvedValue(null);

      await expect(
        userService.getUserByUsername('non-existing-user'),
      ).rejects.toThrow(NotFoundException);
      expect(prismaMock.user.findUnique).toBeCalledTimes(1);
      expect(prismaMock.user.findUnique).toBeCalledWith({
        where: { username: 'non-existing-user' },
      });
    });
  });

  describe('getAllUser', () => {
    it('should return all user', async () => {
      const allUser = [
        {
          username: 'user1',
          name: 'User 1',
        },
        {
          username: 'user2',
          name: 'User 2',
        },
      ];

      prismaMock.user.findMany.mockResolvedValue(allUser);

      const result = await userService.getAllUser();
      expect(result).toEqual(allUser);
      expect(prismaMock.user.findMany).toBeCalledTimes(1);
      expect(prismaMock.user.findMany).toBeCalledWith({});
    });

    it('should return empty array if there are no users', async () => {
      prismaMock.user.findMany.mockResolvedValue([]);

      const result = await userService.getAllUser();
      expect(result).toEqual([]);
      expect(prismaMock.user.findMany).toBeCalledTimes(1);
      expect(prismaMock.user.findMany).toBeCalledWith({});
    });
  });
});

Dynamic Mocking

The previous mocking technique is working as expected. But, you may catch some problem in that technique. We manually define our mock as an object based on the usage in our UserService. What if there are changes made in the service? If we invoke a user.findFirst() or a user.create() functions in our service, we have to manually add those functions to our mock object. What if we create another table to our schema? We have to add those table to our mock object too. What if we create another unit test file? We have to create the mock object there too. This manual upkeep can be error-prone, potentially leading to mismatches between the mock object and the evolving service. Thankfully, there exists a way to dynamically create our mock object.

For this technique, we will use the jest-mock-extended package. This package is recommended by Prisma, as it allows us to deeply mock the PrismaClient and provides us a type-safe mock object. Let’s change our test file to:

describe('UserService', () => {
  let userService: UserService;
  let prismaMock: DeepMockProxy<PrismaClient>;

  beforeEach(async () => {
    prismaMock = mockDeep<PrismaClient>();

    const module: TestingModule = await Test.createTestingModule({
      providers: [
        UserService,
        {
          provide: PrismaService,
          useValue: prismaMock,
        },
      ],
    }).compile();

    authService = module.get<AuthService>(AuthService);
  });

// ... the rest of our code

The mockDeep function is used to deeply mock the PrismaClient. Therefore, any modification to the database schema will be automatically mirrored to our mock object.

Mocking external dependencies in unit tests allows us to introduce more control to our test environment. It may seem complicated at first, but with more hands-on experience, we can gain a detailed understanding of how to tailor mocks to specific scenarios and improve the quality of our unit test. With a high quality test, we can ensure the robustness of our codebase. Happy testing!

In software development, testing is an integral part of development to ensure the quality of the code. One of the most adopted testing paradigm is Test Driven Development (TDD). In this article, we will explore more about TDD and how to implement it using Jest, a testing framework.

What is TDD?

Test Driven Development (TDD) is an approach of software development that put emphasis on writing tests before the actual code. This way, developers can catch eventual issues early on and reduce the time needed for debugging later.

TDD follows a cyclic process that consists of 3 primary steps: writing failing tests, implementing the minimum code to pass the tests, and refactoring the code while ensuring the tests continue to pass. After the refactoring is done, the cycle continues on for the next functionality to implement.

1. Writing Failing Tests

The TDD process starts with writing tests for the functionality that will be implemented later. These tests will fail since the corresponding code implementation hasn’t realized yet. While writing tests, we have to consider various scenarios that the eventual code implementation should address.

The first scenario is the positive cases. In these scenarios, we explore the expected and desired behavior of the functionality under normal, ideal conditions. Positive cases represent the typical user interactions or system inputs that the code is designed to handle successfully. The tests created usually in a form of asserting the result of a function against the expected result. Another form of asserting used is validating whether specific functions are expectedly invoked.

The second scenario is the negative cases. In these scenarios, we intentionally test the boundaries and limitations of the functionality by introducing inputs or conditions that are expected to trigger errors, exceptions, or undesired outcomes. The tests for these scenarios usually asserting whether or not an exception is thrown, examining the type of the thrown exception, and validating whether specific functions are expectedly not invoked.

The third scenario is the edge cases. These scenarios test out the extreme variations of input. Tests for edge cases can either be positive or negative, depending on the nature of the input and the functionality being examined.

2. Implementing Minimum Passing Code

After the tests are complete, the next step is writing the code to pass the tests. The goal here is to write as minimum code as can be to pass the tests. This goal allows developer to focus more on the functionality of the code and avoid overcomplexity.

3. Refactoring

After all tests have passed, it’s time to refactor the code. In this step, we identify and eliminate redundancy in our codebase. By refactoring, we can increase the quality, maintainability, and scalability of our code.

While refactoring, we should always check the status of our tests. The passed tests should not reverted to failed, or else the refactoring process won’t have any value in it.

TDD using Jest

Jest is one of many JavaScript testing framework. Jest offers user-friendly syntax and powerful features, such as automatic test runners and built-in assertions. When integrated with TypeScript, we can create more type-safe tests, ensuring the quality of our code. In the next section, we will explore how to implement a TDD cycle using Jest.

The Functionality

Before we start our TDD, we have to define what our functionality will be. For this example, we will create a function to handle user registration.

// register.ts
export type RegisterRequest = {
  username: string
  password: string
  name: string
}

class RegisterFailedException extends Error {
  constructor(message: string) {
    super(message);
    Object.setPrototypeOf(this, RegisterFailedException.prototype);
  }
}

export const register = (request: RegisterRequest) => {
  throw new RegisterFailedException("Function not implemented");
}

The register function will handle the incoming RegisterRequest, and then returns true if the register is success. If it fails, we will throw a RegisterFailedException.

Step 1: Writing Failing Tests

Now let’s identify some test cases for our register function.

• Positive case: the incoming request is valid and the return value is true.
• Negative case: the incoming request have missing values, such as empty strings. The function will throw RegisterFailedException.
• Edge case: the incoming request is valid, but the password is not at least 6 characters long. We want to ensure our user’s password is pretty secure. The function will throw RegisterFailedException.

// register.test.ts
describe('register test', () => {
  it('should return true if register success', () => {
    const request: RegisterRequest = {
      username: 'testuser',
      password: 'test1234',
      name: 'Test User',
    };

    const result = register(request);
    expect(result).toBe(true);
  });

  it('should throw exception if request invalid', () => {
    const request: RegisterRequest = {
      username: 'testuser',
      password: 'test1234',
      name: '',
    };

    const result = () => register(request);

    expect(result).toThrow(RegisterFailedException);
    expect(result).toThrow('Incomplete request');
  });

  it('should throw exception if request invalid', () => {
    const request: RegisterRequest = {
      username: 'testuser',
      password: 'test',
      name: 'Test User',
    };

    const result = () => register(request);

    expect(result).toThrow(RegisterFailedException);
    expect(result).toThrow('Password must be at least 6 characters long');
  });
});

Step 2: Implementing Minimum Passing Code

Based on our test, we know what cases that we should consider when implementing the register function.

// register.ts
export const register = (request: RegisterRequest) => {
  const { username, password, name } = request;
  if (username.length === 0 || password.length === 0 || name.length === 0) {
    throw new RegisterFailedException('Incomplete request');
  }

  if (password.length < 6) {
    throw new RegisterFailedException(
      'Password must be at least 6 characters long',
    );
  }

  // do register logic

  return true;
};

All tests should be passing now.

Step 3: Refactoring

Now, let’s start refactoring our code. Our code is pretty small and straightforward right now, so not much can be done. Let’s just reduce some redundancy. Of course, for a real implementation, we should identify many aspect such as the usage of design pattern, code smells, etc.

// register.ts
export const register = ({ username, password, name }: RegisterRequest) => {
  if (username.length === 0 || password.length === 0 || name.length === 0) {
    throw new RegisterFailedException('Incomplete request');
  }

  if (password.length < 6) {
    throw new RegisterFailedException(
      'Password must be at least 6 characters long',
    );
  }

  // do register logic

  return true;
};

Keep in mind that while refactoring, we should always maintain the passing status of our tests.

And just like that, we completed our TDD cycle! Of course, this is just an example. There are a lot of cases that still needs to be considered for such small register function, especially in a real world application. To name a few, we should create tests for input with missing username or password, username duplication, etc.

TDD can significantly enhance the quality and maintainability of your codebase. By writing tests before implementing functionality, you not only ensure that your code meets the specified requirements but also create a safety net for future changes. Also, remember that the true value lies not just in passing tests but in building a foundation for robust and reliable software development. Happy testing!

NestJS is a popular Node.js framework for building server side application. Fueled by the capabilities of TypeScript, NestJS seamlessly incorporates various aspects of Object-Oriented Programming (OOP). In this paradigm, following the SOLID principles is crucial for developing applications not only maintainable, scalable, and robust but also align with NestJS’s opinionated nature. With developers typically following the framework’s guidelines, optimizing your application through the implementation of SOLID principles in NestJS is a recommended approach.

1. Single Responsibility Principle (SRP)

SRP states that each class should be responsible for a single part or functionality of a system. NestJS encourages a modular structure where each module, class, and function has a well-defined responsibility.

Suppose that we have created a module called auth. This module will be responsible for handling anything related to authentication. Within this module, we create classes such asAuthController that handles the routing logic for/auth endpoint group and AuthService that handles the corresponding business process.

src/auth
 |- auth.controller.ts
 |- auth.service.ts
 |- auth.module.ts

To further refine the structure, individual functions within the AuthController can be dedicated to specific endpoints. For example, the register function is used to handle the /auth/registerendpoint and the login function to handle the /auth/login endpoint. The same process can be applied to the AuthService class.

// auth.controller.ts
@Controller('auth')
export class AuthController {

  @Post('/register')
  async register() {
    # routing logic for /auth/register
  }

  @Post('/login')
  async login() {
    # routing logic for /auth/login
  }
}

By following this modular and responsibility-driven design, not only our code will be easier to understand and maintain, but also scalable as the application grows. This separation of concerns allows us to make changes or additions to specific functionalities without affecting the entire system.

2. Open Closed Principle (OCP)

OCP emphasizes that a software component should be open for extension but closed for modification. In the context of NestJS, this principle can be effectively implemented using decorators.

Consider a scenario where every incoming request is authenticated by default, but certain API endpoints, such as our previous /auth/login endpoint, need to bypass authentication. To adhere to the OCP, we can create a custom decorator, let’s call it IsPublic, to easily mark specific endpoints as public, indicating that they should not undergo the authentication process.

// auth.controller.ts
@Controller('auth')
export class AuthController {

  @IsPublic()
  @Post('/auth')
  async register() {
    # routing logic for /auth/login
  }
}

Keep in mind that IsPublic is a custom decorator. Full implementation can be found here.

This way, we have extended the behavior of the register function without modifying the logic of our code. NestJS provides other useful built-in decorator to extends the functionality of our code such as the @Body() and @Param() decorators.

3. Liskov Substitution Principle (LSP)

NestJS relies on dependency injection, allowing the runtime to manage class instantiation and inject instances where needed. In a scenario where we have two services sharing the same abstraction, dynamic injection on a module can be achieved by using the useClass property to conditionally switch between services. This approach aligns with the Liskov Substitution Principle (LSP), emphasizing that objects of a superclass should seamlessly replace objects of its subclasses without disrupting the system.

// abstract.service.ts
export abstract class AbstractService {
  abstract performTask(): string;
}

// first.service.ts
@Injectable()
export class FirstService implements AbstractService {
  performTask(): string {
    return 'FirstService is performing the task.';
  }
}

// second.service.ts
@Injectable()
export class SecondService implements AbstractService {
  performTask(): string {
    return 'SecondService is performing the task differently.';
  }
}

// other.module.ts
@Module({
  providers: [
    {
      provide: AbstractService,
      useClass: condition ? FirstService : SecondService,
    },
    FirstService,
    SecondService
  ],
  exports: [AbstractService],
})
export class OtherModule {}

This dynamic injection adheres to the LSP, allowing us to switching between services implementing the same abstraction.

4. Interface Segregation Principle (ISP)

JavaScript, being a dynamically-typed language, allows flexibility but may lead to runtime errors due to lack of strict typing. With the introduction of TypeScript as a superset of JavaScript, we now can enable static typing through interfaces and types. In NestJS, leveraging these interfaces/types is common, particularly when defining request body structures.

However, it’s crucial to be mindful of the Interface Segregation Principle. ISP asserts that clients should not be compelled to depend on fields or methods they don’t use. In the context of NestJS, it’s tempting to create a generic DTO (Data Transfer Objects) that includes fields for various operations.

# user.dto.ts
export interface UserDTO {
  email: string;
  password: string;
  name: string;
}

// auth.controller.ts
@Controller('auth')
export class AuthController {

  @Post('/register')
  async register(@Body() body: UserDTO) {
    # routing logic for /auth/register
  }

  @Post('/login')
  async login(@Body() body: UserDTO) {
    # routing logic for /auth/login
  }
}

However, this can lead to unnecessary dependency, as the login function does not need the name properties. It’s important to create a separate interfaces to adhere to ISP.

// register.dto.ts
export interface LoginDTO {
  email: string;
  password: string;
}

// register.dto.ts
export interface RegisterDTO {
  email: string;
  password: string;
  name: string;
}

// auth.controller.ts
@Controller('auth')
export class AuthController {

  @Post('/register')
  async register(@Body() body: RegisterDTO) {
    # routing logic for /auth/register
  }

  @Post('/login')
  async login(@Body() body: LoginDTO) {
    # routing logic for /auth/login
  }
}

Or, if you want to use extension instead.

// register.dto.ts
export interface LoginDTO {
  email: string;
  password: string;
}

// register.dto.ts
export interface RegisterDTO extends LoginDTO {
  name: string;
}

By adhering to ISP, each DTO accurately represents the required data for its respective operation, reducing dependencies and contributing to a more maintainable and modular codebase.

5. Dependency Inversion Principle (DIP)

Dependency injection in NestJS gives us the ability to modularize our code effectively. When designing our modules, it is recommended to follow the Dependency Inversion Principle, that is high-level modules remain independent of low-level modules. To achieve this, we create abstractions for the low-level modules, treating them as contracts that define the interaction between modules. For example, suppose that we have a DatabaseService that will be injected to our AuthService.

// database.service.ts
@Injectable()
export class DatabaseService {
  // Database operations
}

// database.module.ts
@Module({
  providers: [DatabaseService],
  exports: [DatabaseService]
})
export class DatabaseModule {}

// auth.module.ts
@Module({
  imports: [DatabaseModule],
  controllers: [AuthController],
  providers: [AuthService],
})
export class AuthModule{}

// auth.service.ts
@Injectable()
export class AuthService {
  constructor(private readonly databaseService: DatabaseService) {}
}

Instead of injecting the DatabaseService directly, we can create an abstraction of the DatabaseService, and then export that abstraction instead.

// database.abstract.ts
@Injectable()
export abstract class DatabaseAbstract {
  // Abstract database operations
}

// database.service.ts
@Injectable()
export class DatabaseService extends DatabaseAbstract{
  // Concrete database operations
}

// database.module.ts
@Module({
  providers: [{
      provide: DatabaseAbstract,
      useClass: DatabaseService
    },
    DatabaseService
  ],
  exports: [DatabaseAbstract]
})
export class DatabaseModule {}

// auth.service.ts
@Injectable()
export class AuthService {
  constructor(private readonly databaseService: DatabaseAbstract) {}
}

This practice not only minimizes coupling between modules but also significantly enhances code flexibility, particularly within the low-level module context. Any changes made on the low-level module will not disrupt the high-level module.

In conclusion, NestJS offers a robust foundation for server-side application development. By integrating the SOLID principles, developers can elevate their applications to new levels of maintainability, scalability, and resilience. Embrace the principles, explore the possibilities, and witness your NestJS-powered applications flourish in the dynamic realm of web development.

References:

• https://www.educative.io/answers/what-are-the-solid-principles-in-java
• https://docs.nestjs.com/