The problem? Most teams tightly couple their business logic to specific message brokers, making these transitions painful and error-prone.

Here's what tightly coupled code typically looks like:

// Tightly coupled to Kafka - mixing business logic with infrastructure
import { Kafka } from 'kafkajs';

const kafka = new Kafka({ brokers: ['kafka:9092'] });
const producer = kafka.producer();

export async function processPayment(paymentData: PaymentData) {
  const result = await chargeCard(paymentData);

  // Kafka-specific code mixed with business logic
  await producer.send({
    topic: 'payment-events',
    messages: [{
      key: result.paymentId,
      value: JSON.stringify({
        paymentId: result.paymentId,
        orderId: result.orderId,
        status: 'completed'
      })
    }]
  });

  return result;
}

This approach has several maintenance problems:

• Infrastructure changes require touching business logic

• Testing requires complex broker setup

• Different teams might implement messaging differently

Diagram: Tightly Coupled Flow (Kafka-specific)

flowchart LR
  A[processPayment] --> B[chargeCard]
  B --> C[Kafka producer.send]
  style C fill:#fdd,stroke:#f66,stroke-width:2px
  C:::infra
  classDef infra fill:#fdd,stroke:#f66,stroke-width:2px,color:#800;

Enter Dapr: Infrastructure Abstraction Done Right

Dapr solves this by providing a consistent API layer between your application and infrastructure. Instead of importing broker-specific libraries, you interact with Dapr's standardized interface.

Here's the same payment service with Dapr:

import { DaprClient } from '@dapr/dapr';

const daprClient = new DaprClient();

export async function processPayment(paymentData: PaymentData) {
  const result = await chargeCard(paymentData);

  // Clean, infrastructure-agnostic publish
  await daprClient.pubsub.publish('payment-events', 'payment.completed', {
    paymentId: result.paymentId,
    orderId: result.orderId,
    status: 'completed'
  }, {
    partitionKey: result.paymentId
  });

  return result;
}

Diagram: Infrastructure-agnostic Flow with Dapr

flowchart TD
  A[processPayment] --> B[chargeCard]
  B --> C[pubsub.publish]
  style C fill:#ddf,stroke:#66f,stroke-width:2px
  C:::infra
  classDef infra fill:#ddf,stroke:#66f,stroke-width:2px,color:#004;

The infrastructure choice becomes a configuration concern:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: payment-events
spec:
  type: pubsub.kafka
  version: v1
  metadata:
  - name: brokers
    value: "kafka:9092"

Need to switch to a different broker? Change the config, not the code:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: payment-events
spec:
  type: pubsub.azure.servicebus
  version: v1
  metadata:
  - name: connectionString
    value: "Endpoint=sb://..."

Real-World Example: Order Processing System

Let me demonstrate this with a complete order processing flow. When orders are created, multiple services need to react:

Order Service (publishes events):

import { DaprClient } from '@dapr/dapr';

const daprClient = new DaprClient();

export async function createOrder(orderData: CreateOrderRequest) {
  const order = await saveOrder(orderData);

  // Publish to multiple systems cleanly
  await Promise.all([
    daprClient.pubsub.publish('order-events', 'order.created', order),
    daprClient.pubsub.publish('analytics-events', 'order.metrics', {
      customerId: order.customerId,
      value: order.total,
      timestamp: new Date()
    })
  ]);

  return order;
}

Inventory Service (subscribes to events):

import { DaprServer } from '@dapr/dapr';

const daprServer = new DaprServer();

// Clean subscription handling
await daprServer.pubsub.subscribe('order-events', 'order.created', async (data) => {
  const order = data as Order;

  // Pure business logic - no infrastructure concerns
  await reserveInventory(order.items);
  await updateStockLevels(order.items);

  console.log(`Reserved inventory for order ${order.id}`);
});

await daprServer.start();

Email Service (also subscribes):

import { DaprServer } from '@dapr/dapr';

const daprServer = new DaprServer();

await daprServer.pubsub.subscribe('order-events', 'order.created', async (data) => {
  const order = data as Order;

  await sendConfirmationEmail({
    to: order.customerEmail,
    orderId: order.id,
    items: order.items
  });
});

await daprServer.start();

Diagram: Order Processing Pub/Sub Sequence

sequenceDiagram
  participant OrderService
  participant PubSub
  participant InventoryService
  participant EmailService

  OrderService->>PubSub: publish(order.created)
  PubSub->>InventoryService: order.created
  PubSub->>EmailService: order.created

Infrastructure Evolution Made Simple

As your system evolves, you can adapt the messaging layer without code changes. Here are some common scenarios:

Development Environment (lightweight Redis):

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order-events
spec:
  type: pubsub.redis
  version: v1
  metadata:
  - name: redisHost
    value: "localhost:6379"

Production Environment (same Redis for consistency):

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order-events
spec:
  type: pubsub.redis
  version: v1
  metadata:
  - name: redisHost
    value: "redis-cluster:6379"
  - name: redisPassword
    secretKeyRef:
      name: redis-secret
      key: password

💡 Tip: Keep the same broker type across stage/prod to minimize surprises.

Migrating to Kafka (when scale demands it):

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order-events
spec:
  type: pubsub.kafka
  version: v1
  metadata:
  - name: brokers
    value: "kafka-cluster:9092"
  - name: consumerGroup
    value: "order-processors"

Most teams wait until it's painful to migrate infra. Dapr makes it painless up front.

Why This Matters for Maintenance

Consistent Patterns: Every developer uses the same pub/sub API regardless of the underlying infrastructure. No need to become a Kafka expert or Redis specialist.

Easier Testing: Mock the Dapr client instead of complex broker setups. Unit tests run fast without external dependencies.

Reduced Cognitive Load: Developers focus on business logic, not infrastructure plumbing. The abstraction prevents reinventing the wheel across teams.

Infrastructure Flexibility: Migrate brokers during planned maintenance windows without touching application code. Rollback is just a config change.

Operational Consistency: Dapr provides built-in observability, retries, and circuit breakers across all components. No custom implementations needed.

The Trade-offs

Additional Complexity: You're adding another runtime component. The sidecar pattern means more moving parts in your deployment.

Performance Overhead: There's a small latency cost (typically 1-3ms) for the extra network hop to the Dapr sidecar.

Learning Curve: Teams need to understand Dapr's component model and configuration patterns.

Component Maturity: Not all Dapr components are equally battle-tested. Some have limitations you'll need to work around.

Final Thoughts

Dapr's value shines in long-term maintenance scenarios. When you need to evolve your messaging infrastructure—and you will—having clean abstractions makes the difference between a smooth migration and weeks of refactoring.

The key insight is treating infrastructure as a pluggable concern rather than a fundamental architectural decision. Your business logic shouldn't care whether messages flow through Kafka, RabbitMQ, or cloud services.

Start with a single service and try Dapr's pub/sub. Once you experience the clean separation, you'll want to apply it everywhere. The investment in abstraction pays dividends when inevitable infrastructure changes come.

TL;DR

Dapr lets you swap message brokers like changing your socks—just update a config file, not your code. Your future self will thank you when that inevitable infrastructure migration comes knocking.

1. Index Bloating: One of the persistent issues I encountered was index bloating. PostgreSQL, while a reliable database system, sometimes lets indexes consume more disk space than necessary. This not only slows down performance but also adds unexpected storage costs. I spent significant time optimizing indexes to strike the right balance between performance and disk usage.

2. Table Bloating: Table bloat, another common problem, occurs as tables accumulate data. This bloat can affect query performance and overall system responsiveness. To counteract this issue, I implemented regular maintenance routines. However, finding the right frequency for these routines without disrupting day-to-day operations proved to be a delicate task.

3. Limit 1 Performance Bug: A curious bug surfaced when I encountered a performance issue related to the LIMIT clause. In an unexpected turn of events, setting a limit of 70 on a query intended to retrieve a single item actually improved performance. This showcases the intricate nature of database optimization, where solutions may not always align with conventional wisdom.

4. Full Vacuum Fallout: Performing a full vacuum on a production database is a delicate operation. Even with careful planning to execute it during low-traffic periods, I faced an unexpected consequence. The temporary increase in table size caused the database to consume 100% of disk space, resulting in a crash. Luckily, due to strategic planning, the impact on end-users was kept minimal, underscoring the importance of cautious execution in routine maintenance tasks.

Conclusion: Throughout my journey in 2023, grappling with PostgreSQL has been both challenging and rewarding. Despite the hurdles of index and table bloating, peculiar performance bugs, and the cautious dance of production vacuuming, I've found immense satisfaction in working with this robust database system. Certain features, such as JSONB, timestamp with time zone and MVCC (Multi Version Concurrency Control) have proven to be invaluable tools, enhancing the overall development experience.

While PostgreSQL has been a reliable companion, it's crucial to remember the age-old wisdom of using the right tool for the right job. Each database system has its strengths, and understanding when to leverage PostgreSQL's capabilities and when to explore other options is key to building efficient and scalable applications. As I reflect on my experiences, I carry with me not only the lessons learned from overcoming challenges but also a deep appreciation for the diverse toolkit that empowers developers in the ever-evolving landscape of backend development.

As we bid farewell to another year filled with coding, debugging, and pushing the boundaries of what's possible, it's time to reflect on the pages that have molded our minds in 2023 and prepare for the adventures that 2024 holds. As an engineer navigating the fast-paced world of Indian startups, I've discovered some invaluable books that not only honed my technical skills but also added unexpected dimensions to my engineering toolkit.

1. Designing Data-Intensive Applications by Martin Kleppmann: Why it's the book of my year: Delve deep into the intricacies of data engineering. If you aim to equip your applications to handle the chaos of the modern tech landscape, this book serves as your reliable map and compass. Plus, I've learned more about how databases work internally, making it an invaluable resource.

2. Never Split the Difference by Chris Voss: Why negotiation matters: While we may not be FBI agents, every line of code we write is a negotiation with the system. Voss shares negotiation tactics that surprisingly translate well into our tech discussions.

3. Psychology of Money by Morgan Housel: Beyond the code: Let's discuss the green stuff. Housel's book goes beyond numbers; it's about understanding the psychology behind financial decisions. A must-read to keep both your wallet and sanity intact.

4. Software Engineering at Google by Titus Winters, Tom Manshreck, and Hyrum Wright: Inside the Google Brain: Ever wondered how the tech behemoth handles software engineering? Gain an insider's view into Google's playbook. Spoiler: It's not all about the search bar.

But what's on my radar for 2024?

1. The Design of Everyday Things by Don Norman: User-centric design for the win: Let's make our software not just functional but downright delightful. Norman's classic promises to open our eyes to the magic of design in everyday tech.

2. Thinking, Fast and Slow by Daniel Kahneman: Get into your user's head: Our brains are peculiar creatures. Kahneman's exploration of fast and slow thinking is a goldmine for understanding our users and, well, ourselves.

3. The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier: From code to leadership: Contemplating climbing the career ladder? Fournier's got the lowdown on the transition from being the code wizard to the tech leader. Spoiler alert: It's not just about fixing bugs anymore.

P.S.: Wondering if all these books will save me from AI taking over the software world. Understanding data, mastering negotiation, and decoding money psychology—hoping it's the secret sauce! A touch of humor might just be the extra code we need. 😄 Happy coding and happy reading!

Hey there, fellow developers! Today, I want to share with you a powerful technique that can take your NestJS applications to a whole new level. It's called dependency injection (DI), and trust me, once you get the hang of it, it'll become your secret weapon for writing clean, maintainable, and modular code. So buckle up and get ready to dive into the wonderful world of dependency injection in NestJS!

Unleashing the Power of Dependency Injection

Okay, let's break it down. Dependency injection is like having a super-smart assistant who automatically handles all the nitty-gritty stuff for you. It's a software design pattern that lets you decouple components from their dependencies, making your code more flexible and scalable.

Picture this: you're building an awesome NestJS app that sends SMS notifications to users. But hey, what if you want to switch from one SMS provider to another without breaking a sweat? That's where DI comes in to save the day! With dependency injection, you can seamlessly swap out providers just by updating the module where it's injected. No more headaches or messy code changes. How cool is that? - We will get to this example as soon as we knock down the constructor injection which is one of the techniques that powers dependency injection.

Simplifying Your Life with Constructor Injection

Now, let's talk about constructor injection, a key aspect of DI. Imagine you have a complex service in your app that requires multiple dependencies to function properly. Without dependency injection, you would have to manually create and manage instances of each dependency within the service. It can quickly become a nightmare, especially when the number of dependencies increases.

But fear not! Dependency injection comes to the rescue. With constructor injection, you can simply declare the dependencies as constructor parameters, and NestJS injects the required instances for you. It's like having a magical genie fulfilling your service's every wish.

Imagine we have a ComplexService that needs three dependencies: DependencyA, DependencyB, and DependencyC. Now, let's say DependencyA itself requires some constructor values. With dependency injection, you don't need to worry about providing those values explicitly. Here's an example:

import { Injectable } from '@nestjs/common';
import { DependencyA } from './dependency-a';
import { DependencyB } from './dependency-b';
import { DependencyC } from './dependency-c';

@Injectable()
export class ComplexService {
  constructor(
    private readonly dependencyA: DependencyA,
    private readonly dependencyB: DependencyB,
    private readonly dependencyC: DependencyC,
  ) {
    // Constructor logic goes here
  }

  // Service methods and functionality
}

In this example, even if DependencyA requires some constructor values, you don't need to pass them explicitly when creating an instance of ComplexService. NestJS will automatically handle the injection of all dependencies, including the required constructor values of DependencyA.

What If There's No Dependency Injection?

Now, imagine a scenario where you don't use dependency injection. Without DI, you would have to manually create instances of each dependency within the service. Your code might look like this:

import { Injectable } from '@nestjs/common';
import { DependencyA } from './dependency-a';
import { DependencyB } from './dependency-b';
import { DependencyC } from './dependency-c';

@Injectable()
export class ComplexService {
  private readonly dependencyA: DependencyA;
  private readonly dependencyB: DependencyB;
  private readonly dependencyC: DependencyC;

  constructor() {
    this.dependencyA = new DependencyA(/* Constructor values for DependencyA */);
    this.dependencyB = new DependencyB();
    this.dependencyC = new DependencyC();
    // Constructor logic goes here
  }

  // Service methods and functionality
}

As you can see, without dependency injection, you need to manually create and manage instances of each dependency, including providing the required constructor values. This can quickly become cumbersome and error-prone, especially as your application grows in complexity.

Switching Providers (Dependency Service) with Ease

Let's dive into a practical example to understand how dependency injection can make our lives easier.

Imagine we have an SmsService responsible for sending SMS notifications to users, and it needs a way to interact with different SMS providers, such as Twilio or Nexmo.

To achieve this flexibility, we use a concept called dependency injection. It allows us to decouple the SmsService from any specific SMS provider implementation. But how does it work?

In our scenario, we define an interface called ISmsProvider. An interface is like a contract that specifies a set of methods that a class must implement. In our case, the ISmsProvider interface defines a method called sendSMS that takes in a phone number and a message and returns a boolean indicating whether the SMS was successfully sent.

Here's an example of how the ISmsProvider interface could look:

interface ISmsProvider {
  sendSMS(phoneNumber: string, message: string): boolean;
}

By defining this interface, we're essentially saying that any class that wants to be an SMS provider must implement the sendSMS method with the same parameters and return type.

Now, let's move on to the SmsService. Instead of directly using a specific provider like Twilio or Nexmo, we declare a constructor parameter of type ISmsProvider in the SmsService class. This means that the SmsService expects an object that conforms to the ISmsProvider interface to be injected when creating an instance of the SmsService.

By injecting the ISmsProvider through the constructor, we create a loose coupling between the SmsService and the actual SMS provider implementation. This allows us to switch providers easily without modifying the core logic of the SmsService.

Let's see an example:

class SmsService {
  constructor(private readonly smsProvider: ISmsProvider) {}

  sendSMS(phoneNumber: string, message: string): boolean {
    return this.smsProvider.sendSMS(phoneNumber, message);
  }
}

In this example, the SmsService class has a method called sendSMS that takes a phone number and a message as parameters. It uses the injected smsProvider object to call the sendSMS method on the provider, abstracting away the specific implementation details.

Here's an example of the TwilioSmsProvider:

import { Injectable } from '@nestjs/common';
import { ISmsProvider } from './sms.provider.interface';

@Injectable()
export class TwilioSmsProvider implements ISmsProvider {
  sendSMS(phoneNumber: string, message: string): Promise<boolean> {
    // Implement the Twilio SMS sending logic here
  }
}

To switch providers, all we need to do is update the module configuration where the SmsService is injected. Here's an example:

import { Module } from '@nestjs/common';
import { SmsService } from './sms.service';
import { ISmsProvider } from './sms.provider.interface';
import { TwilioSmsProvider } from './twilio-sms.provider';

@Module({
  providers: [
    {
      provide: ISmsProvider,
      useClass: TwilioSmsProvider,
    },
    SmsService,
  ],
})
export class SmsModule {}

In the SmsModule configuration, we define that the ISmsProvider should be provided by the TwilioSmsProvider class. By simply updating this configuration, we can seamlessly switch to using Twilio as our SMS provider.

The beauty of dependency injection is that we don't need to touch the SmsService implementation. It remains blissfully unaware of the underlying provider implementation. This decoupling allows us to easily switch providers, improve flexibility, and keep our codebase clean and modular.

Testability? You Bet!

But wait, there's more! Dependency injection also supercharges the testability of your code. By injecting mock or stub implementations of dependencies during unit tests, you can isolate your components and ensure reliable and thorough testing. No more tangled web of dependencies ruining your testing party. It's all about that sweet, sweet isolation!

Conclusion

Congratulations, my fellow developer! You're now armed with the knowledge of dependency injection in NestJS. With its modularity, scalability, and testability superpowers, you can build remarkable applications that are a breeze to maintain and extend.

So, don't be shy—embrace dependency injection, unlock the full potential of NestJS, and watch your codebase soar to new heights. Happy coding, and may the DI force be with you!

• Docker installed https://docs.docker.com/engine/install/
• A nest Js application

Containerized Nest Js Application

Creating Dockerfile with multi-stage build

create a file named Dockerfile in the root directory of the nestjs application

Replace 9009 with your application port

FROM node:12 As development
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM node:12-alpine As production
RUN apk update && apk upgrade && \
  apk add --no-cache bash git openssh
ARG NODE_ENV=production
ENV NODE_ENV=${NODE_ENV}
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm install --only=production
COPY . .
COPY --from=development /usr/src/app/dist ./dist
EXPOSE 9009
CMD ["node", "dist/main"]

Creating .dockerignore

From the official docs of docker for .dockerignore:

Before the docker CLI sends the context to the docker daemon, it looks for a file named .dockerignore in the root directory of the context. If this file exists, the CLI modifies the context to exclude files and directories that match patterns in it. This helps to avoid unnecessarily sending large or sensitive files and directories to the daemon and potentially adding them to images using ADD or COPY.

node_modules
npm-debug.log
dist

Build Docker Image

When building an image, we use the following command:

docker build -t username/image_name:tag_name .

in the below command replace api with your application name

docker build -t sreeteja06/api:v0.1 .

Running the image

replace api with your application name

replace 9009:9009 with your application port

docker run -p 9009:9009 api

Run detached

docker run -d -p 9009:9009 api

docker-compose

docker-compose helps developers with their local development. Since our application is containerized and works the same on every machine, why should our database be dependent on the developer’s machine?

We are going to create a docker-compose config that will initiate and wire up three services for us.

The mariadb service will, as their names imply, run containerized mariadb.

In the application root directory, create a file called docker-compose.yml and fill it with the following content:

replace api with your application name and 9009:9009 with your port

version: '3.7'

services:
  db:
    image: mariadb
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: example
      MYSQL_DATABASE: mydb
      MYSQL_USER: user
      MYSQL_PASSWORD: user
    ports:
      - 3306:3306
    volumes:
      - mariadb-data:/data

  api:
    image: api
    restart: always
    ports:
      - 9009:9009

volumes:
  mariadb-data:

Running the application in development

To run the application, we now have to use the following command:

docker-compose up

Run Detached

docker-compose up -d

And Docker will take care of everything for us.

Stop docker-compose by running

docker-compose down

Remove volumes by running

docker-compose down -v

at the end of this post, you will be able to log the following details

• date and time of the request ( formatted as hh:mm a ddd, MMMM Do YYYY )
• HTTP Method (ex: GET, POST, PUT, DELETE)
• endpoint path (ex: /, /users, /payments)
• response time ( The time between the request coming into morgan and when the response headers are written, in milliseconds. )
• remote-address ( The remote address of the request. This will use req.ip, otherwise the standard req.connection.remoteAddress value.)
• remote-user ( The user authenticated as part of Basic auth for the request. )
• user-agent ( The User-Agent request header is a characteristic string that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting user agent. )

Install Dependencies

npm i morgan moment-timezone

# or if you are using yarn
yarn add morgan moment-timezone

Setting up morgan tokens

morgan logger allows you to customize with the .token() method. The .token() method takes in name of the token as the first argument, following a callback function. morgan will run the callback function each time a log occurs using the token.

morgan.token('date', (req, res, tz: string) => {
  return moment()
    .tz(tz)
    .format('hh:mm a ddd, MMMM Do YYYY');
});
morgan.token('splitter', () => {
  return '\x1b[36m--------------------------------------------\x1b[0m\n';
});
morgan.token('statusColor', (req, res) => {
  const status = (typeof res.headersSent !== 'boolean'
  ? Boolean(res.header)
  : res.headersSent)
    ? res.statusCode
    : undefined;
  const color =
    status >= 500
      ? 31
      : status >= 400
      ? 33
      : status >= 300
      ? 36
      : status >= 200
      ? 32
      : 0;

  return '\x1b[' + color + 'm' + status + '\x1b[0m';
});

Morgan in express middleware

  app.use(
    morgan(
      `:splitter :date[Asia/Kolkata]   \x1b[33m:method\x1b[0m \x1b[36m:url\x1b[0m :statusColor \x1b[35m:response-time ms\x1b[0m | \x1b[35m:remote-addr\x1b[0m | :remote-user | \x1b[30m:user-agent\x1b[0m`,
    ),
  );

here I have used my local timezone, you can change Asia/Kolkata to your local timezone.

Skipping logs

if you want to skip logging a specific request that's called frequently but you don't need to have the log you can use the below code and replace startsWith argument with the request URL of yours

app.use(
    morgan(
      `:splitter :date[Asia/Kolkata]    \x1b[33m:method\x1b[0m \x1b[36m:url\x1b[0m :statusColor \x1b[35m:response-time ms\x1b[0m | \x1b[35m:remote-addr\x1b[0m | :remote-user | \x1b[30m:user-agent\x1b[0m`,
      {
        skip: (req, res) => {
          return req.originalUrl.startsWith('/metrics');
        },
      },
    ),
  );

Preventing DOS Attacks

DOS attacks will crash the server, which makes the API's inaccessible. For example, the attacker sends plenty of requests and large amounts of data to overwhelm and exhaust the system resources which will lead to a server crash.

Rate-limiting

Rate limiting is a very powerful feature for securing backend APIs from malicious attacks and for handling unwanted streams of requests from users. You can rate limit your API's by using this simple npm package express-rate-limit.

const express = require('express');
const rateLimt = require('express-rate-limit');

const app = express();

const limiter = rateLimit({
    windowMs: 20 * 60 * 1000, // 20 minutes
    max: 100 // limit each ip to 100 requests per windowMs
});

app.use(limiter);

Limit the Body payload

In this type of attack, the server is sent a large payload, which the server then attempts to decode, but is compelled to use an excessive amount of memory, thus overwhelming the system and crashing the service. We can restrict the size of the payload by using the body-parser and also we can restrict it in a web server like Nginx.

const bodyParser = require('body-parser')
app.use(bodyParser.json({ limit: "1mb" }))

Preventing XSS Attacks

Untrusted data that is sent down to the browser might get executed instead of just being displayed, this is commonly being referred to as a cross-site-scripting (XSS) attack.

Data Validation and sanitization

Always perform input data validation and sanitization, use XSS or xss-clean

const xss = require('xss-clean')
// Make sure that this comes before any other routes
app.use(xss())

Headers

The Content Security Policy you can apply the HTTP Content-Security-Policy (CSP) header to prevent unauthorized code execution. CSP supports many directives that help you to control how content can be combined in your HTML page. You can use the helmet to set up the appropriate header

const helmet = require('helmet')
app.use(helmet())

Helmet enables the following HTTP headers.

• Strict-Transport-Security
• X-frame-Options
• X-XSS-Protection
• X-Content-Type-Protection
• Content-Security-Policy
• Cache-Control
• Expect-CT
• Disable X-Powered-By

These headers prevent malicious users from various types of attacks such as clickjacking, cross-site scripting, etc.

Preventing SQL/NoSQL Injections

To prevent SQL/NoSQL injection and other malicious attacks, always make use of an ORM/ODM or a database library that escapes data or supports named or indexed parameterized queries, and takes care of validating user input for expected types. Never just use JavaScript template strings or string concatenation to inject values into queries as this opens your application to a wide spectrum of vulnerabilities. All the reputable Node.js data access libraries (e.g. Sequelize , Knex , mongoose ) have built-in protection against injection attacks

Preventing Brute Force Attacks

• The most efficient way is to limit the number of login attempts.
• Use Bcrypt to encrypt the passwords, which will slow down the attacker when guessing.
• You could use express-rate-limit, which works for both DOS attack and brute force attack.
• Implement 2 step verification.

Check dependencies

With the npm ecosystem, it is common to have many dependencies for a project. Dependencies should always be kept in check as new vulnerabilities are found. Use tools like npm audit, nsp, or snyk to track, monitor and patch vulnerable dependencies. Integrate these tools with your CI setup so you catch a vulnerable dependency before it makes it to production.

ESLint

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs. ESLINT

Prettier

Prettier is very popular because it improves code readability and makes the coding style consistent for teams. Developers are more likely to adopt a standard rather than writing their own code style from scratch, so tools like Prettier will make your code look good without you ever having to dabble in the formatting.Prettier

Setting up VS-Code

Make sure you installed the vs code extensions for Prettier and ESLint .

Installing Dev Dependencies

Make sure you are inside a node project or create a package.json file by running the npm init command and initialize the git by running git init.

npm install -D eslint prettier
npx install-peerdeps --dev eslint-config-airbnb
npm install -D eslint-config-prettier eslint-plugin-prettier husky lint-staged

Configuring ESLint

Create a file by name .eslintrc.json and copy the below lines into the file

{
  "extends": ["airbnb", "prettier"],
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": ["error"]
  },
}

Configuring Prettier

Create a file by name .prettierrc and copy the below lines into the file

{
  "printWidth": 100,
  "singleQuote": true
}

Enable format on save

to quickly format your code you can enable formatOnSave on vs-code which enables formatting when you press CTRL + S. You can enable this in vs-code settings, you can open the setting by CTRL +, and search for formatonsave and enable it.

Configure git pre-commit hook

In package.json on the same level as dependencies paste the following lines

"husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ]
  }

you can skip the pre-commit check while committing if you don't need for a single commit by providing the --no-verify flag

git commit -m "no check" --no-verify

Testing pre-commit hook

create an index.js file and copy the contents

const fs = require('fs');
const os = require('os');

ESLint warns you about the unused variables, as a push first, fix after developer we are gonna commit the files by

git add .
git commit -m "test"

Now if everything is working correct you will see this error

index.js
  1:7  error  'fs' is assigned a value but never used  no-unused-vars
  2:7  error  'os' is assigned a value but never used  no-unused-vars

✖ 2 problems (2 errors, 0 warnings)

husky > pre-commit hook failed (add --no-verify to bypass)

Before we get started

Install Windows terminal from the Windows Store

Create a text file

create a text file and paste the below lines in the file. replace {username} with the username of the system you can find it by running echo %USERNAME% in the cmd.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\wt]

@="Open Windows terminal"

"Icon"="C:\\Users\\{username}\\AppData\\Local\\Microsoft\\WindowsApps\\terminal.ico"

[HKEY_CLASSES_ROOT\Directory\Background\shell\wt\command]

@="\"C:\\Users\\{username}}\\AppData\\Local\\Microsoft\\WindowsApps\\wt.exe\" -d %V.\"\""

once you have copied it into the text file, now rename the file extension to .reg. If you are unable to do this enable file name extensions in the view panel of the file explorer.

once you edited the file extension from .txt to .reg, now run the file. Windows asks for confirmation, and after you give the green signal you can now see the windows terminal here on the context menu.

const { default: Axios } = require('axios');

const urls = ['https://supercharged.dev', 'https://blog.supercharged.dev'];

const getUrlStatus = async () => {
  const statuses = await urls.map(async (item) => {
    const urlResponse = await Axios.get(item);
    return urlResponse.status;
  });
  return statuses;
};

const main = async () => {
  console.log(await getUrlStatus());
};

main();

When you run the above example you expect it to provide the status returned by the URL's, but you get the following result

[ Promise { <pending> }, Promise { <pending> } ]

The problem here is we are awaiting an array of promises rather than the promise. To fix this all we have to do is use Promise.all function.

The Promise.all() method takes an iterable of promises as an input and returns a single Promise that resolves to an array of the results of the input promises. This returned promise will resolve when all of the input's promises have resolved, or if the input iterable contains no promises. It rejects immediately upon any of the input promises rejecting or non-promises throwing an error and will reject with this first rejection message/error. MDN docs

So after making changes to the example above we have

const { default: Axios } = require('axios');

const urls = ['https://supercharged.dev', 'https://blog.supercharged.dev'];

const getUrlStatus = async () => {
  const statuses = await Promise.all(
    urls.map(async (item) => {
      const urlResponse = await Axios.get(item);
      return urlResponse.status;
    })
  );
  return statuses;
};

const main = async () => {
  console.log(await getUrlStatus());
};

main();

And the response is.... (Drumroll 🥁)

[ 200, 200 ]

If you want to allow failures in promise.all you can use the below snippet

const getUrlStatus = async () => {
  let statuses = urls.map(async (item) => {
    const urlResponse = await Axios.get(item);
    return urlResponse.status;
  });
  statuses = await Promise.all(
    statuses.map((promise) => promise.catch((err) => null))
  );
  return statuses;
};

you will get a null for the promises that failed.