Forem: Tejas Nikhar

Understanding DNS Record Types: A Practical Deep Dive 🌍

Tejas Nikhar — Fri, 02 May 2025 04:58:04 +0000

A few months ago, while managing our infrastructure, we faced an interesting challenge. Our development servers were hosted on Azure, while our production and staging environments ran on AWS. Every three months, the SSL certificates for our Azure servers would expire, and we had to manually generate new certificates, update them in Azure, and modify the CNAME records in AWS Route 53.

This repetitive task led me to explore the Domain Name System (DNS) more deeply. What exactly was happening behind the scenes when we updated the CNAME? Why did some changes propagate instantly while others took longer? And what other DNS records existed beyond A, CNAME, and MX?

This article will break down different types of DNS records, their purpose, and how they impact real-world scenarios like SSL certificate management, email routing, and load balancing.

What is DNS and Why Does It Matter?

The Domain Name System (DNS) is essentially the phonebook of the internet. It translates human-readable domain names (e.g., example.com) into machine-readable IP addresses (e.g., 192.168.1.1 or 2606:4700:4700::1111).

Without DNS, you'd have to remember the IP address of every website you visit! DNS records are the backbone of how traffic is routed across the internet, and different record types serve different purposes.

How DNS Resolution Actually Works

Have you ever wondered what happens when you type "example.com" in your browser? Let me break it down:

Your computer first checks its local cache: "Do I already know where example.com is?"
If not, it asks your configured DNS resolver (usually provided by your ISP)
If your resolver doesn't know, it starts by asking a root nameserver
The root server directs it to the .com nameservers (using NS records!)
The .com nameserver directs it to example.com's nameservers
Finally, example.com's nameserver provides the actual IP address

This whole process usually happens in milliseconds! It's like asking for directions at each stop until you reach your destination.

Common DNS Record Types and Their Uses

1. A Record (Address Record)

Purpose: Maps a domain to an IPv4 address.
Example:

example.com -> 192.168.1.100

Use Case: When a user enters example.com, the browser queries DNS to resolve it to an IP address where the website is hosted.

2. AAAA Record (IPv6 Address Record)

Purpose: Maps a domain to an IPv6 address.
Example:

example.com -> 2606:4700:4700::1111

Use Case: If a website supports IPv6, this record is used instead of an A record.

3. CNAME Record (Canonical Name Record)

Purpose: Points one domain to another domain instead of an IP address.
Example:

www.example.com -> example.com

Use Case:
- If www.example.com is an alias for example.com, DNS resolution for the www subdomain will be directed to the target domain.
- Used heavily in CDNs and cloud services to point to dynamically assigned hosts.

4. MX Record (Mail Exchange Record)

Purpose: Directs email traffic to the correct mail server.
Example:

example.com -> mail.google.com (Priority 10)

Use Case: Required for email functionality. Without an MX record, emails sent to @example.com would have nowhere to go.

5. TXT Record (Text Record)

Purpose: Stores arbitrary text data, often used for domain verification and email security.
Example:

example.com -> "v=spf1 include:_spf.google.com ~all"

Use Case:
- Verifying domain ownership (e.g., Google Search Console, AWS Route 53, etc.)
- Email authentication using SPF, DKIM, and DMARC.

6. SRV Record (Service Record)

Purpose: Specifies services running on a domain.
Example:

_sip._tcp.example.com -> sipserver.example.com (Port 5060)

Use Case: Used in services like VoIP, XMPP (chat services), and LDAP.

7. NS Record (Name Server Record)

Purpose: Defines which name servers are authoritative for a domain.
Example:

example.com -> ns1.exampledns.com, ns2.exampledns.com

Use Case: When a user queries a domain, these name servers are contacted to resolve it.

8. PTR Record (Pointer Record)

Purpose: Performs reverse DNS lookups (IP to domain name).
Example:

100.1.168.192.in-addr.arpa -> example.com

Use Case: Used by email servers to check if an IP is associated with a legitimate domain (helps prevent spam).

9. SOA Record (Start of Authority Record)

Purpose: Provides administrative information about a DNS zone.
Example:

example.com -> Primary DNS: ns1.exampledns.com, Admin: hostmaster@example.com

Use Case: Every DNS zone requires an SOA record, containing data about zone updates and refresh rates.

Understanding TTL and DNS Propagation

TTL (Time-To-Live) values are measured in seconds and control how long DNS records are cached. When I was updating those CNAME records for our SSL certificates, here's what I learned:

High TTL (86400 = 24 hours):
- Pros: Reduces load on DNS servers, slightly faster lookups
- Cons: Changes take longer to propagate globally
Low TTL (300 = 5 minutes):
- Pros: Changes propagate quickly, great for emergency updates
- Cons: More frequent DNS lookups, slightly higher server load

Many DNS experts recommend a strategy of:

Keeping normal TTL around 3600-7200 seconds (1-2 hours)
Lowering TTL to 300 seconds (5 minutes) a day before planned DNS changes
Making your change
Setting TTL back to normal after confirming everything works

This was a game-changer for our certificate renewal process!

DNS Security: Protecting the Internet's Directory

Since DNS is so fundamental to how we use the internet, it's also a target for attacks. Here are some basic security features I've learned about:

DNSSEC (DNS Security Extensions)

This adds digital signatures to DNS records to prevent tampering. It's like having a security seal on the phonebook so you know the number you're calling really belongs to the bank, not a scammer!

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Normally, DNS queries are sent unencrypted (anyone watching your network can see what websites you're visiting). DoH and DoT encrypt these queries, adding privacy. Chrome, Firefox and many modern browsers now support these!

Troubleshooting DNS Issues: Tools I've Found Helpful

When things go wrong with DNS (and they sometimes do!), here are some tools I use:

dig (or nslookup on Windows): Shows you exactly what's stored in DNS for a domain

dig example.com A

whatsmydns.net: Checks how your DNS is resolving from different locations worldwide
GSuite Toolbox: If you use Google Workspace, their DNS checker is super helpful

How DNS Records Impact SSL Certificate Management

Managing SSL certificates efficiently often involves interacting with DNS records, especially for domain validation and automation. Here's how DNS plays a crucial role in SSL/TLS certificate management.

1. DNS-01 Challenge for Certificate Renewal

SSL certificate providers like Let's Encrypt, AWS Certificate Manager, and Cloudflare use DNS-01 validation as one of the methods to prove domain ownership.
Instead of requiring a temporary file to be placed on the server (HTTP-01 validation), DNS-01 requires adding a TXT record to the domain's DNS settings with a unique challenge response.
Once the provider confirms the TXT record exists and contains the correct response, the certificate is issued or renewed.
Why is this useful?
- Allows certificate validation without a running web server (useful for API gateways, serverless applications, and wildcard certificates).
- Wildcard certificates (*.example.com) can only be issued using DNS-01 validation.
- Can be fully automated using ACME clients like Certbot, acme.sh, or Lego to handle DNS record updates dynamically.

2. CNAME Updates and Propagation Delays

Many cloud providers (e.g., AWS, Azure, Cloudflare) allow using CNAME records to point to automatically managed certificate validation records instead of manually adding TXT records.
However, DNS records are cached by resolvers worldwide, which can lead to propagation delays when updating a CNAME record for certificate validation.
TTL (Time-To-Live) Settings:
- Each DNS record has a TTL value that defines how long caching servers should store the record before checking for an update.
- A high TTL (e.g., 24 hours) means slower propagation, whereas a lower TTL (e.g., 300 seconds or 5 minutes) allows quicker updates.
- If your CNAME or TXT records aren't updating immediately, check if your DNS provider supports instant purging or set a lower TTL in advance.
Real-World Example:
- Suppose you're using AWS Route 53 to validate an SSL certificate for example.com via CNAME.
- If your DNS resolver has cached an old CNAME value, Let's Encrypt or AWS ACM might fail to detect the updated validation record.
- Lowering the TTL before making changes ensures updates propagate faster.

By understanding and optimizing DNS validation mechanisms, teams can ensure seamless SSL
certificate renewals without unexpected failures or delays.

Advanced DNS Strategies

After working with DNS more extensively, I discovered some strategies that can really improve reliability:

Round-Robin DNS

Did you know you can have multiple A records with the same name but different IP addresses? This creates a simple load balancing method where DNS will rotate through the IPs for each request.

example.com -> 192.168.1.100
example.com -> 192.168.1.101
example.com -> 192.168.1.102

Subdomain Delegation

You can delegate control of specific subdomains to different DNS servers. For instance, if you want your development team to manage dev.example.com separately from your main domain:

dev.example.com NS ns1.devteam.com
dev.example.com NS ns2.devteam.com

This lets different teams manage their own DNS without giving access to the entire domain.

Key Takeaways

DNS is the backbone of the internet, enabling domain resolution, email routing, and security validations.
Understanding different DNS records helps in managing infrastructure more effectively.
CNAME and TXT records play a crucial role in SSL/TLS certificate renewals and domain verification.
TTL values directly impact how quickly DNS changes propagate.
DNS security features like DNSSEC and DoH provide additional protection.
Automating DNS-based SSL certificate renewal can prevent downtime and security issues.

While researching more about DNS record types, I came across this great visual breakdown shared by ByteByteGo: Visual guide to different DNS record types.

Next time you manage a domain or troubleshoot a DNS issue, take a moment to explore what's happening under the hood—because there's a lot more than meets the eye! 🚀

Mastering React Events: Understanding, Debugging, and Optimizing Event Handling 🚀

Tejas Nikhar — Sat, 29 Mar 2025 09:00:00 +0000

Events are the backbone of user interactions in any web application. Whether it's a button click, a form submission, or a keyboard shortcut, events dictate how users engage with our applications. React, like the DOM, provides an event system, but it's not just a direct wrapper around native events—it introduces a synthetic event system that optimizes and standardizes event handling across different browsers.

At first glance, event handling in React seems straightforward—attach an event listener to a component, and React takes care of the rest. But as applications scale, handling events efficiently becomes crucial to preventing unexpected behavior, performance bottlenecks, and debugging nightmares.

The Curious Case of the Disappearing Tooltip

It started as a simple feature: A custom tooltip component that should appear when an element is hovered and disappear when the mouse leaves. Yet, during rapid user interactions—such as continuous clicking—the tooltip would sometimes fail to appear at all. Debugging this issue led to a deep dive into how React handles events, how propagation works, and why certain event handlers behave unexpectedly.

This experience highlighted why understanding event flow, propagation, and optimizations is crucial for building robust React applications.

Understanding React's Synthetic Event System

Unlike traditional DOM event handling, React wraps native events with its own abstraction: SyntheticEvent. This system provides a consistent interface across browsers, improving event handling efficiency.

Why Synthetic Events?

Performance Optimizations: React pools events to reduce memory consumption. Instead of creating a new event object for every interaction, React reuses event objects and resets them after the callback executes.
Cross-Browser Compatibility: React normalizes event properties across different browsers, so developers don't have to worry about inconsistencies.
Event Delegation: Unlike direct DOM event listeners, React attaches a single event listener at the root (document or root container). This improves performance by reducing the number of event listeners in the DOM tree.

How Synthetic Events Work

When an event occurs, React:

Captures the native event.
Wraps it inside a SyntheticEvent.
Calls the appropriate React event handlers.
Returns the event to a pool for reuse.

The Evolution of Event Pooling

In React versions before 17, React reused event objects, meaning accessing properties like event.target asynchronously would return null. To persist event data, you had to use event.persist().

// Pre-React 17 approach
const handleClick = (event: React.MouseEvent) => {
    event.persist(); // Prevents React from reusing the event object
    setTimeout(() => {
        console.log(event.target); // Accessible even after the event lifecycle
    }, 1000);
};

But good news! Since React 17, event pooling has been removed. This means we no longer need to call event.persist() to access event properties asynchronously. React now creates a new event object for each event, which is more intuitive and easier to work with.

// React 17+ approach
const handleClick = (event: React.MouseEvent) => {
    // No need for event.persist() anymore!
    setTimeout(() => {
        console.log(event.target); // Works fine in React 17+
    }, 1000);
};

This change made a huge difference in my debugging process! I was initially calling persist() everywhere and later realized it wasn't needed anymore. Learning these version differences is part of the journey!

Common React Events and Their Use Cases

React categorizes events into several groups:

1. Mouse Events

onClick, onDoubleClick, onMouseDown, onMouseUp
onMouseEnter, onMouseLeave, onMouseOver, onMouseOut
onContextMenu (Right-click handling)

2. Keyboard Events

onKeyDown, onKeyUp

3. Form & Input Events

onChange, onInput, onFocus, onBlur
onSubmit, onReset

4. Clipboard Events

onCopy, onCut, onPaste

5. Drag & Drop Events

onDragStart, onDragEnd, onDragEnter, onDragLeave
onDragOver, onDrop

6. Touch Events (Mobile)

onTouchStart, onTouchMove, onTouchEnd, onTouchCancel

7. Focus Events

onFocus, onBlur

8. Composition Events (IME input handling)

onCompositionStart, onCompositionUpdate, onCompositionEnd

9. Wheel Events

onWheel

10. Media Events

onPlay, onPause, onEnded, onVolumeChange

Event Propagation: Bubbling, Capturing, and Stopping Events

Events in React follow the bubbling and capturing phases, just like native DOM events. This means an event can trigger multiple handlers as it moves from the target element up (bubbling) or down (capturing) the DOM tree.

To prevent unwanted behaviors, we use:

event.stopPropagation() – Prevents the event from reaching parent elements.
event.preventDefault() – Prevents the default browser action.

const handleClick = (e: React.MouseEvent) => {
    e.stopPropagation();
    console.log("Click prevented from bubbling!");
};

Understanding the Event Flow

When I first started with React, I was confused about why my event handlers were triggering in what seemed like a random order. Then I learned about event flow:

Capturing Phase: Event travels down from the root to the target element
Target Phase: Event reaches the target element
Bubbling Phase: Event bubbles up from the target back to the root

React event handlers typically operate during the bubbling phase, but you can capture events during the capturing phase by adding Capture to the event name:

<div
    onClickCapture={() => console.log("Capture phase!")}
    onClick={() => console.log("Bubble phase!")}
>
    <button onClick={() => console.log("Button clicked!")}>Click me</button>
</div>

When clicking the button, the logs will appear in this order:

"Capture phase!" (during capturing)
"Button clicked!" (at target)
"Bubble phase!" (during bubbling)

This knowledge helped me solve many event-related issues!

Handling Events Like a Pro: Custom Wrappers

To manage events effectively, we can abstract common patterns into utility functions:

export const preventDefaultOnly = (e: React.MouseEvent | React.ChangeEvent) => {
    e.preventDefault();
};

export const stopPropagationOnly = (e: React.MouseEvent | React.ChangeEvent) => {
    e.stopPropagation();
};

export const preventAndStopEvent = (e: React.MouseEvent | React.ChangeEvent) => {
    preventDefaultOnly(e);
    stopPropagationOnly(e);
};

Debouncing and Throttling Events

Handling rapid event firing efficiently is crucial for performance. Here's an improved debouncing function that creates a separate timer for each handler:

export const createDebounceHandler = <T extends (...args: any[]) => void>(
    handler: T,
    delay: number = 300
): T => {
    let timer: NodeJS.Timeout | null = null;

    return ((...args: any[]) => {
        if (timer) clearTimeout(timer);
        timer = setTimeout(() => handler(...args), delay);
    }) as T;
};

// Usage example
const debouncedSearch = createDebounceHandler((searchTerm) => {
    // Search API call here
    console.log("Searching for:", searchTerm);
}, 500);

Throttling for Scroll and Resize Events

Throttling is similar to debouncing but ensures a function runs at most once in a specified time interval:

export const createThrottleHandler = <T extends (...args: any[]) => void>(
    handler: T,
    interval: number = 300
): T => {
    let lastRun: number = 0;
    let timeout: NodeJS.Timeout | null = null;

    return ((...args: any[]) => {
        const now = Date.now();

        if (now - lastRun >= interval) {
            if (timeout) {
                clearTimeout(timeout);
                timeout = null;
            }
            lastRun = now;
            handler(...args);
        } else if (!timeout) {
            timeout = setTimeout(
                () => {
                    lastRun = Date.now();
                    timeout = null;
                    handler(...args);
                },
                interval - (now - lastRun)
            );
        }
    }) as T;
};

// Usage example
const throttledScroll = createThrottleHandler(() => {
    console.log("Scroll position:", window.scrollY);
}, 200);

I've learned that throttling works better for continuous events like scrolling, while debouncing is ideal for discrete events like typing or button clicks.

React Hooks and Event Handling

When I started using React Hooks, event handling got both easier and trickier! Here's what I've learned:

Using useCallback for Event Handlers

To prevent unnecessary re-renders, we can memoize event handlers with useCallback:

import { useCallback, useState } from "react";

function SearchComponent() {
    const [query, setQuery] = useState("");

    // This handler is memoized and won't be recreated on each render
    const handleInputChange = useCallback((e: React.ChangeEvent<HTMLInputElement>) => {
        setQuery(e.target.value);
    }, []); // Empty dependency array means this function never changes

    return <input type="text" value={query} onChange={handleInputChange} />;
}

Adding Global Event Listeners with useEffect

Sometimes we need to listen for events outside our components:

import { useEffect, useState } from "react";

function KeyboardShortcuts() {
    const [isCtrlPressed, setIsCtrlPressed] = useState(false);

    useEffect(() => {
        const handleKeyDown = (e: KeyboardEvent) => {
            if (e.key === "Control") setIsCtrlPressed(true);
        };

        const handleKeyUp = (e: KeyboardEvent) => {
            if (e.key === "Control") setIsCtrlPressed(false);
        };

        // Add global event listeners
        window.addEventListener("keydown", handleKeyDown);
        window.addEventListener("keyup", handleKeyUp);

        // Cleanup function - VERY IMPORTANT to prevent memory leaks!
        return () => {
            window.removeEventListener("keydown", handleKeyDown);
            window.removeEventListener("keyup", handleKeyUp);
        };
    }, []); // Empty dependency array means this only runs once

    return <div>{isCtrlPressed ? "Ctrl is pressed" : "Ctrl is not pressed"}</div>;
}

This pattern has been super helpful for keyboard shortcuts, click-outside detection, and other global interactions!

Common Event Handling Patterns

Controlled Forms

React's approach to forms is different from vanilla JavaScript. Instead of letting the DOM manage form state, we control it with React state:

import { useState } from "react";

function ContactForm() {
    const [formData, setFormData] = useState({
        name: "",
        email: "",
        message: "",
    });

    const handleChange = (e: React.ChangeEvent<HTMLInputElement | HTMLTextAreaElement>) => {
        const { name, value } = e.target;
        setFormData((prev) => ({
            ...prev,
            [name]: value,
        }));
    };

    const handleSubmit = (e: React.FormEvent) => {
        e.preventDefault(); // Prevent browser from refreshing
        console.log("Form submitted:", formData);
        // Submit to API here
    };

    return (
        <form onSubmit={handleSubmit}>
            <input
                type="text"
                name="name"
                value={formData.name}
                onChange={handleChange}
                placeholder="Your name"
            />
            <input
                type="email"
                name="email"
                value={formData.email}
                onChange={handleChange}
                placeholder="Your email"
            />
            <textarea
                name="message"
                value={formData.message}
                onChange={handleChange}
                placeholder="Your message"
            />
            <button type="submit">Send</button>
        </form>
    );
}

Event Delegation in Lists

When rendering lists in React, it's more efficient to handle events at the parent level rather than attaching handlers to each item:

function TodoList({ todos }) {
    const handleItemClick = (e: React.MouseEvent, todoId: string) => {
        e.stopPropagation(); // Prevent bubbling if needed
        console.log("Todo clicked:", todoId);
    };

    return (
        <ul>
            {todos.map((todo) => (
                <li key={todo.id} onClick={(e) => handleItemClick(e, todo.id)}>
                    {todo.text}
                </li>
            ))}
        </ul>
    );
}

React 18 Event Handling Considerations

React 18 introduced some changes that affect event handling:

Automatic Batching

Before React 18, updates inside event handlers were batched (multiple state updates resulted in a single render), but updates in promises, setTimeout, or native event handlers weren't batched.

React 18 introduced automatic batching for all updates, which improves performance but can change behavior:

// In React 18, these state updates are batched into a single render
function handleClick() {
    setCount((c) => c + 1);
    setFlag((f) => !f);
    // Only ONE render will occur, not two!
}

useTransition for Non-Urgent Updates

React 18 introduced useTransition to mark state updates as non-urgent, which helps with large updates:

import { useTransition, useState } from "react";

function SearchResults() {
    const [query, setQuery] = useState("");
    const [results, setResults] = useState([]);
    const [isPending, startTransition] = useTransition();

    const handleSearch = (e: React.ChangeEvent<HTMLInputElement>) => {
        // Update input immediately (urgent update)
        setQuery(e.target.value);

        // Mark results update as non-urgent
        startTransition(() => {
            // This could be an expensive operation
            const searchResults = performExpensiveSearch(e.target.value);
            setResults(searchResults);
        });
    };

    return (
        <>
            <input type="text" value={query} onChange={handleSearch} />
            {isPending ? <p>Loading...</p> : results.map(/* render results */)}
        </>
    );
}

I've found this pattern really helpful when handling events that trigger expensive operations!

Performance Optimization Tips

Through trial and error, I've discovered several ways to optimize event handling:

Avoid Creating Functions in Render

Creating new functions on every render can cause unnecessary re-renders in child components:

// 🔴 Bad: Creates a new function on every render
function BadExample() {
    return <button onClick={() => console.log("Clicked")}>Click Me</button>;
}

// ✅ Good: Define the function outside render
function GoodExample() {
    const handleClick = useCallback(() => {
        console.log("Clicked");
    }, []);

    return <button onClick={handleClick}>Click Me</button>;
}

When to Use Inline Functions

Sometimes inline functions are acceptable:

For simple event handlers in components that don't re-render often
When the function depends on props or state that change frequently
When passing additional parameters

function TodoList({ todos, onToggle }) {
    return (
        <ul>
            {todos.map((todo) => (
                // This is acceptable because we need to pass the todo id
                <li key={todo.id} onClick={() => onToggle(todo.id)}>
                    {todo.text}
                </li>
            ))}
        </ul>
    );
}

Conclusion

React's event system is powerful but comes with nuances that can lead to unexpected issues if not understood well. Mastering event propagation, preventing unnecessary handlers, and efficiently managing event listeners ensures smoother performance and a bug-free user experience.

The journey from being confused about synthetic events to understanding the nuances of event handling in React has been challenging but rewarding. I've gone from wondering why my tooltip was disappearing to implementing optimized event handling patterns that make my applications more responsive and reliable.

By diving deep into event flow and common patterns, you'll be better equipped to handle complex event-driven behaviors, whether it's fixing a vanishing tooltip or optimizing large-scale event handling for high-performance applications.

Remember that React's event system continues to evolve with each version, so keep learning and experimenting!

🚀 Happy coding!

Deep Dive into NestJS Decorators: Internals, Usage, and Custom Implementations 🛠️

Tejas Nikhar — Sun, 23 Mar 2025 08:30:00 +0000

While working with NestJS, I was amazed at how extensively it leverages decorators, even though JavaScript doesn't fully support them yet. This made me curious about how NestJS enables decorator
support. I then researched how TypeScript implements decorators and whether NestJS follows the same approach or relies on its own custom implementation. In this article, we'll explore exactly that.

Introduction

NestJS provides a powerful abstraction for building scalable applications, leveraging decorators to simplify and structure code. However, understanding how these decorators work internally can help in optimizing performance, debugging issues, and even creating custom decorators effectively.

This article takes a deep dive into:

How TypeScript decorators work
The current state of JavaScript decorator support
How NestJS leverages reflect-metadata to enable powerful decorator functionality
How to create and use custom decorators
Performance considerations when using decorators

1. Understanding TypeScript Decorators

What Are Decorators?

Decorators are special functions that modify the behavior of classes, methods, properties, or parameters they are attached to. They are essentially metadata annotations attached using the
@ symbol.

The Current State of Decorators in JavaScript

JavaScript doesn't fully support decorators in its standard yet because:

Decorators are still a Stage 3 proposal in ECMAScript (as of March 2025)
The proposal has gone through several iterations and design changes
Browser implementations are still in progress

However, TypeScript has supported decorators as an experimental feature for years, enabling frameworks like NestJS to leverage them.

How TypeScript Implements Decorators

TypeScript supports decorators through its compiler, which transforms decorator syntax into regular JavaScript function calls.

Let's look at a simple example:

// Decorator factory - returns the actual decorator function
function Log() {
    // The actual decorator function
    return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
        const originalMethod = descriptor.value;

        // Replace the original method with a new one that includes logging
        descriptor.value = function (...args: any[]) {
            console.log(`Calling ${propertyKey} with`, args);
            return originalMethod.apply(this, args);
        };
    };
}

class User {
    @Log()
    getUser(name: string) {
        return `User: ${name}`;
    }
}

const user = new User();
user.getUser("Tejas"); // Logs: "Calling getUser with ["Tejas"]" then returns "User: Tejas"

Different Types of Decorators

TypeScript supports five types of decorators:

Class decorators - Applied to the class constructor
Method decorators - Applied to methods
Property decorators - Applied to properties
Parameter decorators - Applied to function parameters
Accessor decorators - Applied to getters/setters

Each type of decorator receives different parameters and is used for different purposes in NestJS.

What Happens During Compilation?

When TypeScript compiles decorators, it transforms them into function calls that wrap around the original code. Here's a simplified version of what the compiled JavaScript might look like for our example:

// Simplified compiled output
var User = (function () {
    function User() {}

    // Original method
    User.prototype.getUser = function (name) {
        return "User: " + name;
    };

    // Apply decorator
    User.prototype.getUser = (function (originalMethod) {
        return function (...args) {
            console.log("Calling getUser with", args);
            return originalMethod.apply(this, args);
        };
    })(User.prototype.getUser);

    return User;
})();

This transformation happens at compile-time, but the decorator's effects occur at runtime.

2. How NestJS Uses Decorators Internally

NestJS Decorators & `reflect-metadata`

NestJS extends TypeScript's decorator capabilities using a library called reflect-metadata. This library implements a proposal for adding a Reflection API to JavaScript, allowing frameworks to store and retrieve metadata about classes, methods, and properties.

What Exactly is `reflect-metadata`?

reflect-metadata is a polyfill library that implements the Metadata Reflection API proposal. It allows you to:

Define metadata on classes and class members
Retrieve metadata at runtime
Use type information from TypeScript (with some compiler options enabled)

This is crucial for NestJS's dependency injection system, which needs to know about types to instantiate them correctly.

Example: Using `reflect-metadata` in NestJS

import "reflect-metadata"; // Must be imported once at the application entry point

// Create a metadata key
const META_KEY = "role";

// Decorator factory
function Role(role: string) {
    // The actual decorator
    return function (target: Object, key?: string | symbol) {
        // Store metadata on the target
        Reflect.defineMetadata(META_KEY, role, target, key);
    };
}

class User {
    @Role("admin")
    accessDashboard() {
        // Method implementation
    }
}

// Later, retrieve the metadata
const user = new User();
const role = Reflect.getMetadata(META_KEY, User.prototype, "accessDashboard");
console.log(role); // Output: 'admin'

How NestJS Uses `reflect-metadata` Under the Hood

NestJS uses reflect-metadata extensively to implement its core features:

Dependency Injection: NestJS stores type information to automatically inject dependencies
Request Routing: @Controller() and @Get() decorators store routing information
Guards & Interceptors: Decorators like @UseGuards() attach metadata for request handling
Validation: Decorators mark which fields should be validated

3. Deep Dive: How NestJS Executes Decorators Internally

The NestJS Bootstrapping Process

When you start a NestJS application, this happens:

The application calls NestFactory.create(AppModule)
NestJS creates a dependency injection container
It scans all modules starting from AppModule
For each module, it reads metadata from decorators to identify:
- Controllers
- Providers (services, etc.)
- Imports/exports
It builds a complete dependency graph

Step-by-Step Execution of a Decorator

Let's see how @Controller() works internally:

During application development, you decorate a class:

   @Controller("users")
   export class UserController {
    // Controller methods
   }

When this code is compiled, TypeScript transforms it, calling the Controller function
The Controller function (implemented by NestJS) stores metadata:

   // Simplified version of what NestJS does internally
   function Controller(prefix?: string): ClassDecorator {
    return (target: object) => {
        Reflect.defineMetadata("path", prefix || "", target);
        Reflect.defineMetadata("__isController", true, target);
    };
   }

During application startup, NestJS uses its DiscoveryService to scan modules:

   // Conceptual example of what happens internally
   const isController = Reflect.getMetadata("__isController", UserController);
   if (isController) {
    const path = Reflect.getMetadata("path", UserController);
    // Register the controller with the path 'users'
   }

NestJS creates instances and sets up routing based on this metadata

This is a simplified explanation, but it shows how NestJS uses decorators and metadata to build its entire system.

Real-World Example: How `@Injectable()` Works

The @Injectable() decorator is core to NestJS's dependency injection. Here's how it works:

// Your code
@Injectable()
export class UserService {
    constructor(private databaseService: DatabaseService) {}
}

// What NestJS does internally (simplified)
function Injectable(): ClassDecorator {
    return (target: object) => {
        Reflect.defineMetadata("__injectable", true, target);

        // Get parameter types from TypeScript
        const types = Reflect.getMetadata("design:paramtypes", target) || [];

        // Store dependency types for later injection
        Reflect.defineMetadata("__paramtypes", types, target);
    };
}

// During application startup, NestJS creates instances
const paramTypes = Reflect.getMetadata("__paramtypes", UserService);
// paramTypes would be [DatabaseService]

// NestJS would then:
// 1. Create/find an instance of DatabaseService
// 2. Create UserService passing in the DatabaseService instance
const databaseService = container.get(DatabaseService);
const userService = new UserService(databaseService);

4. Custom Decorators in NestJS

Creating custom decorators in NestJS is surprisingly easy because NestJS provides utilities to simplify the process.

Example: Creating a `@Permissions` Decorator

import { SetMetadata } from "@nestjs/common";

// NestJS provides SetMetadata to make decorator creation easier
export const Permissions = (...permissions: string[]) => SetMetadata("permissions", permissions);

Using the Decorator in a Controller

import { Controller, Get } from "@nestjs/common";
import { Permissions } from "./permissions.decorator";

@Controller("users")
export class UserController {
    @Get()
    @Permissions("read:users", "write:users")
    getUsers() {
        return "Users List";
    }
}

Retrieving Metadata in a Guard

NestJS provides the Reflector class to simplify metadata retrieval:

import { CanActivate, ExecutionContext, Injectable } from "@nestjs/common";
import { Reflector } from "@nestjs/core";

@Injectable()
export class PermissionsGuard implements CanActivate {
    constructor(private reflector: Reflector) {}

    canActivate(context: ExecutionContext): boolean {
        // Get the permissions required for this endpoint
        const requiredPermissions = this.reflector.get<string[]>("permissions", context.getHandler());

        if (!requiredPermissions) {
            return true; // No permissions required
        }

        const request = context.switchToHttp().getRequest();
        const user = request.user;

        // Check if user has all required permissions
        return requiredPermissions.every((permission) => user?.permissions?.includes(permission));
    }
}

Advanced: Custom Parameter Decorators

NestJS also supports custom parameter decorators, which can extract and transform data from requests:

import { createParamDecorator, ExecutionContext } from "@nestjs/common";

// Create a decorator that extracts a specific user property
export const UserProperty = createParamDecorator((data: string, ctx: ExecutionContext) => {
    const request = ctx.switchToHttp().getRequest();
    const user = request.user;

    // data is the property name passed to the decorator
    return data ? user?.[data] : user;
});

// Usage in a controller
@Controller("users")
export class UserController {
    @Get("profile")
    getProfile(@UserProperty("id") userId: string) {
        return `User ID: ${userId}`;
    }
}

Composing Multiple Decorators

One powerful feature of decorators is that you can combine them:

import { applyDecorators, Get, UseGuards } from "@nestjs/common";
import { PermissionsGuard } from "./permissions.guard";
import { Permissions } from "./permissions.decorator";

// Create a combined decorator
export function SecureEndpoint(path: string, ...permissions: string[]) {
    return applyDecorators(Get(path), Permissions(...permissions), UseGuards(PermissionsGuard));
}

// Usage
@Controller("users")
export class UserController {
    @SecureEndpoint("admin", "read:users", "manage:users")
    getAdminDashboard() {
        return "Admin Dashboard";
    }
}

This pattern is exactly how NestJS creates many of its built-in decorators!

5. Debugging Decorators in NestJS

Decorators can sometimes be tricky to debug, so here are some tips:

Common Decorator Problems and Solutions

Problem: Metadata Not Being Applied

// This might not work as expected
@Controller("users")
class UserController {}

Solution: Make sure you're exporting the class:

@Controller("users")
export class UserController {}

Problem: Decorator Order Matters

// This might produce unexpected results
@UseGuards(AuthGuard)
@Permissions('admin')
@Get()
method() {}

Solution: Remember that decorators are applied bottom-to-top, so reorder them:

@Get()
@Permissions('admin')
@UseGuards(AuthGuard)
method() {}

Problem: Missing reflect-metadata

If you get errors about metadata, make sure:

// At your application entry point
import "reflect-metadata";

Inspecting Metadata at Runtime

You can debug metadata by adding:

console.log(Reflect.getMetadataKeys(target));
console.log(Reflect.getMetadata("key", target));

6. Performance Considerations with NestJS Decorators

While decorators are powerful, they do have performance implications:

Benchmarking Decorator Overhead

In my testing, I found that heavy use of decorators and metadata can add approximately 5-10% overhead to request processing times, though this varies widely based on usage.

Optimization Strategies

Cache Metadata Lookups: If you're repeatedly accessing the same metadata, store it in a variable

  // Instead of this in a hot path
  const permissions = this.reflector.get('permissions', handler);

  // Do this
  private readonly handlerPermissionsMap = new Map();

  getPermissions(handler) {
    if (!this.handlerPermissionsMap.has(handler)) {
      const permissions = this.reflector.get('permissions', handler);
      this.handlerPermissionsMap.set(handler, permissions);
    }
    return this.handlerPermissionsMap.get(handler);
  }

Minimize Decorator Count: Don't overuse decorators; each one adds processing time
Lazy Evaluation: If your decorator performs expensive operations, do them lazily:

  function ExpensiveOperation() {
    let result;
    return (target, key, descriptor) => {
      const original = descriptor.value;
      descriptor.value = function(...args) {
        // Only calculate once
        if (!result) {
          result = /* expensive calculation */;
        }
        return original.apply(this, [...args, result]);
      };
    };
  }

Conclusion

NestJS decorators simplify development by abstracting complex logic into reusable annotations. Understanding their internals provides better debugging, optimization, and customization capabilities.

TypeScript decorators transform class behavior at runtime through compiler transformations
NestJS enhances decorators using reflect-metadata to implement its dependency injection system
Custom decorators allow developers to extend NestJS functionality efficiently
Debugging and optimizing decorators requires understanding their execution flow

With this knowledge, you can now optimize, debug, and even build advanced decorators in NestJS like a pro! 🚀

Additional Resources

Mastering Event-Driven Architecture: When and Why to Use It ⚡

Tejas Nikhar — Sun, 16 Mar 2025 10:30:00 +0000

Event-Driven Architecture (EDA) has gained significant traction, especially in systems requiring real-time processing and scalability. While designing our export service, I experienced firsthand the benefits of event-based communication. Instead of tightly coupled service calls, events enabled a highly scalable and decoupled system

Despite its advantages, EDA comes with challenges like debugging complexities and eventual consistency. This article explores its fundamentals, why it matters, and when to choose it over other architectures.

Introduction

Event-Driven Architecture (EDA) is a software design pattern where components communicate asynchronously by producing and consuming events. Instead of direct service calls, systems react to events (e.g., user actions, state changes) via an event bus or message broker.

In this article, we'll cover:

Core concepts of Event-Driven Architecture
Benefits of using EDA over traditional architectures
Role of microservices in EDA
Key challenges and trade-offs
Implementation patterns and anti-patterns
How to decide when to use EDA

Understanding Event-Driven Architecture

EDA revolves around events, which are immutable records of something that has occurred in a system. Unlike traditional request-response patterns, EDA creates a reactive system where services respond to events without direct dependencies.

Core Components of EDA

Event Producers – Generate events when something happens (e.g., "OrderPlaced", "UserSignedUp").
Event Consumers – Listen for and process specific events.
Event Broker (Message Bus) – Middleware like Kafka, RabbitMQ, AWS SNS/SQS, or BullMQ that routes events from producers to consumers.
Event Store (Optional) – Stores event history for auditing and replaying past events.

Key Event Patterns in EDA

Event Notification – Simple notifications that something has happened. Consumers must query additional information if needed.

   // Example event notification
   {
     "type": "UserSignedUp",
     "userId": "12345",
     "timestamp": "2025-03-01T14:23:45Z"
   }

Event-Carried State Transfer – Events contain all necessary data, eliminating the need for additional queries.

   // Example event with complete state
   {
     "type": "UserSignedUp",
     "userId": "12345",
     "timestamp": "2025-03-01T14:23:45Z",
     "userData": {
       "email": "user@example.com",
       "name": "John Doe",
       "plan": "premium"
     }
   }

Event Sourcing – Storing all state changes as a sequence of events, allowing system state reconstruction from the event log.

   [
     {"type": "AccountCreated", "accountId": "ACC123", "balance": 0, "timestamp": "..."},
     {"type": "MoneyDeposited", "accountId": "ACC123", "amount": 100, "timestamp": "..."},
     {"type": "MoneyWithdrawn", "accountId": "ACC123", "amount": 50, "timestamp": "..."}
   ]
   // Current balance can be calculated: 0 + 100 - 50 = 50

Command Query Responsibility Segregation (CQRS) – Separating write operations (commands) from read operations (queries), often used with Event Sourcing.

Essential Event Characteristics

Immutability – Events are facts that have already occurred and cannot be changed.
Atomicity – Events represent atomic operations that either happen completely or not at all.
Uniqueness – Each event has a unique identifier to prevent duplicate processing.
Ordering – Events often have a temporal order that must be preserved for correct processing.
Idempotence – Processing the same event multiple times should yield the same result.

Example: Ad Export Service Workflow 🚀

Imagine a seamless pipeline where ads are generated and delivered efficiently using an event-driven approach. Here's how our Ad Export Service operates:

🖥️ User Action: The frontend triggers an API request to the NestJS service, requesting an ad export.
📦 Data Preparation: The NestJS service prepares the required data and pushes it to an AWS SQS queue for further processing.
⚡ Triggering Lambda: The SQS queue fires an event that triggers an AWS Lambda function, ensuring a serverless and scalable execution.
🏗️ Ad Generation: The Lambda function processes the buffered data, generates the ad assets, and uploads them to Amazon S3 for storage.
🔗 Metadata Processing: Once the assets are uploaded, the Lambda function retrieves the S3 URLs and other metadata, then queues the data into BullMQ (a high-performance Redis-based job queue).
🎧 Real-Time Processing: The NestJS service has a BullMQ listener continuously monitoring for job completion events.
📝 Database Update: Upon receiving the data from BullMQ, the NestJS listener updates the database, ensuring the system stays in sync.

🌟 Why This Works So Well?

Asynchronous & Scalable → No blocking operations, making the system highly responsive.
Decoupled Services → Each component works independently, reducing dependencies.
Fault-Tolerant → If one part fails (e.g., Lambda execution), the rest of the system continues operating.
Event-Driven Efficiency → Only processes are triggered when needed, optimizing resource usage.

With this architecture, ad exports run smoothly, reliably, and at scale, ensuring an optimal experience for users. 🚀✨

Implementation Patterns & Anti-Patterns

Successful EDA implementation requires following established patterns while avoiding common pitfalls.

Effective Implementation Patterns

Event Schema Versioning

Events evolve over time, requiring schema versioning to maintain backward compatibility.

   // Good practice: Including schema version
   {
     "type": "UserCreated",
     "schemaVersion": "1.2",
     "payload": {
       "userId": "12345",
       "email": "user@example.com"
     }
   }

Implement strategies like:

Additive-only changes
Consumer-driven contracts
Schema registry (like Confluent Schema Registry for Kafka)

Dead Letter Queues (DLQ)

When a consumer fails to process an event after multiple retries, the event is moved to a DLQ for manual inspection.

   // AWS SQS DLQ configuration example
   const queueParams = {
    QueueName: "ExportServiceQueue",
    RedrivePolicy: JSON.stringify({
        deadLetterTargetArn: dlqArn,
        maxReceiveCount: 3, // Move to DLQ after 3 failed attempts
    }),
   };

Saga Pattern for Distributed Transactions

Coordinate multiple services to maintain data consistency through a sequence of local transactions.

   Order Service         Payment Service        Inventory Service
        |                      |                       |
        |---Create Order------>|                       |
        |                      |---Process Payment---->|
        |                      |                       |---Allocate Inventory
        |                      |<------Success---------|
        |<-----Success---------|                       |

If any step fails, compensating transactions restore system consistency.

Outbox Pattern

Ensure reliable event publishing by storing events in a local "outbox" table with database transactions.

   -- In a transaction:
   BEGIN;
   -- 1. Update business data
   UPDATE orders SET status = 'CONFIRMED' WHERE id = '12345';
   -- 2. Insert into outbox
   INSERT INTO outbox(id, event_type, payload)
   VALUES(uuid(), 'OrderConfirmed', '{"orderId":"12345","status":"CONFIRMED"}');
   COMMIT;

A separate process reads from the outbox and publishes events to the message broker.

Anti-Patterns to Avoid

Event Overload

Generating too many fine-grained events creates unnecessary network traffic and processing overhead.

   // Anti-pattern: Too many granular events
   publishEvent("UserFirstNameUpdated", { userId: "123", firstName: "John" });
   publishEvent("UserLastNameUpdated", { userId: "123", lastName: "Doe" });
   publishEvent("UserEmailUpdated", { userId: "123", email: "john@example.com" });

   // Better approach: One meaningful event
   publishEvent("UserProfileUpdated", {
    userId: "123",
    updates: {
        firstName: "John",
        lastName: "Doe",
        email: "john@example.com",
    },
   });

Synchronous Event Processing

Waiting for event processing completion defeats the purpose of EDA.

   // Anti-pattern: Synchronous waiting
   function updateUser(userId, data) {
    updateUserInDB(userId, data);
    const event = createUserUpdatedEvent(userId, data);
    sendEventAndWaitForCompletion(event); // Blocking call
    return "User updated";
   }

   // Better approach: Asynchronous processing
   function updateUser(userId, data) {
    updateUserInDB(userId, data);
    const event = createUserUpdatedEvent(userId, data);
    sendEventAsync(event); // Non-blocking
    return "User update initiated";
   }

Missing Event Versioning

Events without version information become impossible to evolve safely.

   // Anti-pattern: No version information
   {
     "type": "UserCreated",
     "userId": "12345",
     "name": "John Doe"
   }

Tight Coupling Through Events

Events that contain implementation details or are designed for specific consumers reintroduce coupling.

   // Anti-pattern: Implementation-specific event
   {
     "type": "OrderCreated",
     "orderId": "12345",
     "forInventoryService": {
       "warehouseId": "W123",
       "inventoryAdjustments": [...]
     },
     "forBillingService": {
       "paymentMethod": "...",
       "invoiceDetails": [...]
     }
   }

Why Choose EDA Over Traditional Architectures?

1. Loose Coupling for Better Maintainability

Services don't need to know about each other.
Each service can evolve independently without breaking the system.
In the Ad Export Service, the NestJS service doesn't need to know how the Lambda processes the export—it just pushes data to SQS, and the system reacts accordingly.

2. Scalability for High-Throughput Systems

Events can be processed asynchronously, allowing horizontal scaling.
Ideal for high-load applications where multiple services work independently.
In the Ad Export Service, we handle thousands of exports without bottlenecks because:
- SQS queues requests instead of overwhelming the Lambda.
- BullMQ manages processing efficiently, preventing overload.
- The system scales effortlessly by adding more workers.

3. Resilience & Fault Tolerance

If a consumer service fails, events can be retried or stored for later processing.
No single point of failure compared to direct synchronous calls.
In the Ad Export Service:
- If the Lambda processing fails, SQS ensures retries.
- If BullMQ fails to process an export, it retains the job until the NestJS listener successfully updates the database.
- Failures are isolated, preventing system-wide crashes.

4. Real-Time Processing

Immediate reaction to changes (e.g., stock price updates, IoT sensor readings).
Used in financial trading systems, fraud detection, and monitoring dashboards.
In the Ad Export Service:
- Once an export is generated, the system instantly pushes metadata to BullMQ.
- The NestJS listener picks up the event and updates the database in real-time.
- This ensures that users get instant feedback when their ad export is ready, improving the UX.

EDA vs. Other Architectural Styles: In-Depth Comparison

Understanding when to choose EDA requires comparing it against other popular architectural approaches.

REST vs. EDA vs. GraphQL vs. gRPC

Aspect	REST	Event-Driven	GraphQL	gRPC
Communication Model	Request-response	Publish-subscribe	Query-based	Request-response, streaming
Coupling	Tight	Loose	Medium	Medium-tight
Data Format	JSON/XML	Any (typically JSON)	JSON	Protocol Buffers
State Transfer	Full resources	Events/state changes	Specific fields	Defined messages
Real-time Capabilities	Poor (polling required)	Excellent	Poor (subscriptions help)	Good (bidirectional streaming)
Backward Compatibility	Challenging	Good (with schema evolution)	Excellent	Good (with careful design)
Learning Curve	Low	High	Medium	High
Ideal Use Cases	CRUD operations, simple domain	Complex workflows, real-time systems	Data aggregation, flexible clients	Microservices, high-performance needs

Implementation Complexity

Let's compare a simple user registration flow across architectures:

REST Implementation

// Client-side
async function registerUser(userData) {
    const response = await fetch("/api/users", {
        method: "POST",
        body: JSON.stringify(userData),
    });

    if (response.ok) {
        // Make additional API calls for related operations
        await fetch("/api/notifications", { method: "POST" /* ... */ });
        await fetch("/api/analytics", { method: "POST" /* ... */ });
    }

    return response.json();
}

// Server-side (Express.js)
app.post("/api/users", async (req, res) => {
    try {
        const user = await db.users.create(req.body);
        res.status(201).json(user);
    } catch (error) {
        res.status(400).json({ error: error.message });
    }
});

EDA Implementation

// Producer (NestJS service)
@Injectable()
class UserService {
  constructor(private eventBus: EventBus) {}

  async registerUser(userData) {
    const user = await this.db.users.create(userData);

    // Publish event for other services to consume
    this.eventBus.publish(new UserRegisteredEvent({
      userId: user.id,
      email: user.email,
      registeredAt: new Date()
    }));

    return user;
  }
}

// Consumer (Notification service)
@EventsHandler(UserRegisteredEvent)
class SendWelcomeEmailHandler {
  async handle(event: UserRegisteredEvent) {
    await this.emailService.sendWelcomeEmail(event.email);
  }
}

// Consumer (Analytics service)
@EventsHandler(UserRegisteredEvent)
class TrackUserRegistrationHandler {
  async handle(event: UserRegisteredEvent) {
    await this.analytics.track('user_registered', {
      userId: event.userId,
      timestamp: event.registeredAt
    });
  }
}

Role of Microservices in EDA

EDA aligns perfectly with microservices, enabling services to communicate without tight coupling and ensuring better scalability and resilience.

How EDA Enhances Microservices

Independent Scaling

Each service scales based on its own workload. For example, if the Ad Export Service experiences high demand, additional instances of the Lambda function or BullMQ workers can be deployed without affecting other services.

Asynchronous Processing

Eliminates blocking operations. The frontend triggers the export without waiting for immediate completion, allowing the system to generate ads in the background while the user continues other tasks.

Event Replay & Extensibility

If a new service (e.g., Analytics Tracking Service) is introduced later, it can replay past export events from the queue to analyze trends without requiring changes to the existing architecture.

Comparison: EDA vs REST in Microservices

Coupling:
- REST: Tight coupling
- EDA: Loose coupling
Scalability:
- REST: Limited to synchronous requests
- EDA: High scalability via async events
Fault Tolerance:
- REST: Service failures cause downtime
- EDA: Services operate independently
Real-time Capabilities:
- REST: Limited by request latency
- EDA: Instant event-driven reactions
Debugging:
- REST: Easier (linear execution)
- EDA: Harder (event tracing needed)

Challenges of Event-Driven Architecture

While EDA offers scalability and flexibility, it introduces certain trade-offs that must be carefully managed.

1. Increased Complexity

Debugging asynchronous workflows is more challenging than tracking a linear REST request-response cycle.
Requires additional infrastructure like event brokers (Kafka, RabbitMQ, BullMQ, AWS SQS), increasing operational overhead.
In our Ad Export Service, multiple queues (SQS, BullMQ) and event-driven triggers make end-to-end tracing essential for debugging.

2. Eventual Consistency

Unlike synchronous systems, updates do not happen instantly across all services.
The database might reflect partial updates until all events are processed.
In our Ad Export Service, the database isn't updated immediately after S3 uploads—BullMQ handles this asynchronously, ensuring consistency.

3. Debugging & Observability

Since services don't communicate directly, understanding the flow of an event requires specialized tools like OpenTelemetry, Jaeger, or AWS X-Ray.
Distributed tracing helps track events from the frontend API call → SQS → Lambda → BullMQ → DB update.

4. Handling Duplicate or Lost Events

Due to network retries and failures, duplicate messages are common.
Consumers must implement idempotency (e.g., checking if an event was already processed before making changes).
In our Ad Export Service, ensuring that an ad isn't exported multiple times due to retries is handled by unique job identifiers in BullMQ.

When Should You Choose EDA?

The decision to use Event-Driven Architecture (EDA) depends on the need for scalability, real-time processing, and system decoupling.

✅ Choose EDA When:

Your system generates distinct events such as AdExportRequested, AdGenerated, or ExportCompleted.
You need asynchronous processing, like triggering background tasks (e.g., background tasks, real-time updates, large-scale data processing).
Your system must scale dynamically to handle bursts in traffic, ensuring smooth operation even with high request loads.
You require loose coupling, allowing services like ad generation, storage, and database updates to operate independently.

❌ Avoid EDA If:

Your application is small and doesn't require asynchronous processing (e.g., a simple CRUD system).
You need strong consistency (e.g., financial transactions, where each step must be instantly reflected across all services).
Debugging must be simple, and your team is not equipped to handle distributed tracing across multiple services.
Real-time processing isn't necessary, and a traditional request-response model suffices.

Examples Where EDA Excels:

E-commerce Order Processing – An order event triggers payment processing, inventory updates, and notifications independently.
Streaming Platforms – Video uploads trigger encoding, thumbnail generation, and metadata updates without blocking user actions.
IoT & Smart Devices – Sensor data streams trigger automated responses, such as alerting maintenance teams in case of anomalies.
Fraud Detection in Banking – Real-time transaction events trigger fraud analysis engines to detect suspicious activities instantly.

We chose EDA for our Ad Export Service because:

Exporting ads is an asynchronous process that shouldn't block user actions.
The workload varies, requiring scalability (e.g., batch exports during peak hours).
Decoupling ensures that Lambda functions, SQS queues, and BullMQ consumers can work independently, improving reliability.

Final Thoughts

Event-Driven Architecture offers immense scalability, flexibility, and fault tolerance, making it a great choice for microservices and real-time systems. However, it requires careful event modeling, proper event storage, and observability tools to manage complexity effectively.

If you're building highly scalable, resilient, and reactive systems, EDA is worth considering! 🚀

For further reading, check out:

Run GitHub Actions Locally with Act: A Developer's Guide 🛠️

Tejas Nikhar — Fri, 07 Mar 2025 02:30:00 +0000

As someone who has been writing GitHub Actions for a long time, I’ve come to appreciate the value of the Act tool. It’s been a game-changer for me, allowing me to:

1. Run actions locally and avoid the dreaded failed workflows showing up in the GitHub Actions tab 😅.
2. Catch errors early, especially for workflows involving tasks like pushing code, Docker images, or deploying branches.
3. Save time and resources by testing actions locally before pushing to GitHub.

Getting Started with Act

The main dependency for Act is Docker, so make sure you have it installed on your system. Once Docker is ready, follow these steps:

Step 1: Install Act

Install Act using one of the following methods:

Using Homebrew (macOS/Linux):

  brew install act

Using Scoop (Windows):

  scoop install act

Using Shell Script:

  curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

For other installation methods, check the official Act documentation.

Step 2: Configure Act

Once installed, run the following command to set up Act:

act

You’ll be prompted to choose a default image for running your workflows:

Large size image: ~17GB download and ~75GB disk space required. Mirrors GitHub-hosted runners.
Medium size image: ~500MB. Includes essential tools for most workflows.
Micro size image: <200MB. Contains only Node.js. Not compatible with all workflows.

Choose the image that best fits your requirements. For most use cases, the medium image is a good balance between size and functionality.

Step 3: Start Using Act

Here are some common use cases for Act:

To see all available workflows in your repository, use:

   act -l

Example: The following output showcases the use of the act -l command, which lists all available workflows in your repository. This provides a clear view of the workflows, jobs, and the events that trigger them

    act -l
    INFO[0000] Using docker host 'unix:///var/run/docker.sock', and daemon socket 'unix:///var/run/docker.sock'
    Stage  Job ID          Job name               Workflow name                   Workflow file       Events
    0      build-and-push  Build and Push Images  Build and Publish Docker Image  docker-image.yml    push
    0      lint            Linting Go Code        Lint                            lint.yml            pull_request
    0      security_audit  security_audit         Security Audit                  security-audit.yml  pull_request
    0      unit_tests      unit_tests             Unit Tests                      unit-test.yml       workflow_dispatch,pull_request

Run a specific workflow by specifying the event that triggers it. For example:

   act push

You can run a specific job within a workflow using:

   act -j <job_name>

Example: Below is a trimmed output for the unit_tests job. Note that a lot of logs have been omitted for brevity, as the job produces extensive output

    act -j unit_tests

    [Unit Tests/unit_tests] ⭐ Run Main Install Dependencies
    [Unit Tests/unit_tests]   🐳  docker exec cmd=[bash -e /var/run/act/workflow/2] user= workdir=
    | go: downloading github.com/fatih/color v1.18.0
    | go: downloading golang.org/x/sys v0.25.0
    | go: downloading github.com/mattn/go-colorable v0.1.13
    | go: downloading github.com/mattn/go-isatty v0.0.20
    [Unit Tests/unit_tests]   ✅  Success - Main Install Dependencies

    [Unit Tests/unit_tests] ⭐ Run Main Run Unit Tests
    [Unit Tests/unit_tests]   🐳  docker exec cmd=[bash -e /var/run/act/workflow/3] user= workdir=
    | ?     github.com/tejastn10/argus      [no test files]
    | === RUN   TestLoggingToFile
    | --- PASS: TestLoggingToFile (0.00s)
    | PASS
    | ok    github.com/tejastn10/argus/logs 0.001s
    | === RUN   TestMonitorURLTable
    | === RUN   TestMonitorURLTable/Valid_URL
    | === RUN   TestMonitorURLTable/Invalid_URL
    | --- PASS: TestMonitorURLTable (0.83s)
    |     --- PASS: TestMonitorURLTable/Valid_URL (0.83s)
    |     --- PASS: TestMonitorURLTable/Invalid_URL (0.00s)
    | PASS
    | ok    github.com/tejastn10/argus/monitor      0.827s
    [Unit Tests/unit_tests]   ✅  Success - Main Run Unit Tests

To use a specific workflow file, run:

   act -W .github/workflows/<workflow_file>.yml

Act supports loading environment variables from a .env file. Create a .env file with your variables and run:

   act --env-file .env

Same is true for secrets file too. Create a .secrets file with your secrets and run:

   act --secret-file=.secrets

Key Features and Limitations

Features

Test Locally: Run workflows without pushing changes to GitHub.
Environment Variable Support: Load .env files directly for configuration.
Workflow Debugging: Quickly debug issues in your workflows.
Granular Control: Run specific workflows, jobs, or tasks.

Limitations

Some features of GitHub Actions are not fully supported (e.g., workflow_dispatch inputs).
Requires Docker, so make sure your system meets the requirements.

This tool has been a lifesaver for me when developing workflows. If you’re tired of failed actions cluttering your GitHub Actions tab or want to ensure your workflows run smoothly before pushing to GitHub, Act is definitely worth a try. Happy coding!

Managing Docker Logs and Preventing Log Overflows on Servers 🐳

Tejas Nikhar — Tue, 25 Feb 2025 02:30:00 +0000

In containerized environments like Docker, log management can become a significant issue, especially when logs grow uncontrollably. Docker containers often generate logs for various events, such as errors, warnings, status messages, and application-specific logs. If not properly managed, these logs can fill up disk space quickly, leading to performance issues or even server crashes.

This article discusses how to prevent such log overflows on a Docker server, focusing on controlling the log storage size using the systemd journal configuration.

Docker Logging and Its Impact on Disk Space

By default, Docker logs container activity using the json-file logging driver. This driver stores logs in JSON format in a container's log file, typically located in the /var/lib/docker/containers/<container-id>/ directory.

While these logs provide valuable insights into the container's operation, they can accumulate over time, especially in high-traffic applications or those generating verbose logs. Some factors contributing to excessive log growth include:

Verbose Application Logs: Applications running inside Docker containers may log a lot of information, especially in development or debug modes.
Docker Daemon Logs: The Docker daemon itself logs events such as container starts, stops, and restarts.
Log Rotation Configuration: If log rotation is not configured, logs can grow indefinitely, filling up the disk space.

This unchecked growth can lead to a situation where logs fill up the disk, slowing down the system or even causing crashes.

Preventing Log Floods Using `systemd` Configuration

On many Linux systems, systemd is responsible for managing system services, including logging through journald. journald is a system service that collects and stores logs. By default, journald can store logs in a ring buffer (in-memory) or persist them to disk.

If your Docker logs are flooding the disk, one way to control this is by configuring systemd’s journaling settings. Specifically, the SystemMaxUse option in the /etc/systemd/journald.conf file can limit the maximum disk space allocated for logs, preventing them from growing beyond a set size.

Steps to Limit `journald` Logs:

Check Disk Usage: Use the df -h command to check the current disk usage, especially focusing on directories like /var where logs might be stored.
Modify journald Configuration: Edit the journald.conf file, which controls the logging behavior of systemd. This file is usually located at /etc/systemd/journald.conf. You can adjust the following parameters:

SystemMaxUse: This sets the maximum disk space that systemd logs can occupy. If the logs exceed this size, older logs are deleted automatically.
SystemKeepFree: You can specify the amount of disk space to keep free on the system.
SystemMaxFileSize: This controls the maximum size of individual log files.
SystemMaxFiles: This controls how many rotated log files to keep.

For example, to limit the logs to 50MB, set:

   [Journal]
   SystemMaxUse=50M

Restart systemd-journald Service: After modifying the configuration, restart the systemd-journald service to apply the changes:

   sudo systemctl restart systemd-journald.service

Verify Log Changes: You can verify the changes using the journalctl command or by checking the disk usage again with df -h to see if the logs are now limited.

Docker Compose Logging Configuration

In addition to configuring systemd logging, Docker Compose provides a way to manage logging for each container in your application. By configuring the logging driver in the docker-compose.yml file, you
can set limits on the log file size and the number of rotated log files.

Here’s an example of how to configure logging in a Docker Compose file:

services:
  app:
    image: your-app-image
    logging:
      driver: "json-file"
      options:
        max-size: "50m" # Maximum log file size before rotation
        max-file: "3" # Number of log files to keep

Explanation:

driver: "json-file": This specifies that Docker should use the default json-file logging driver. You can also use other drivers like syslog or fluentd if you prefer.
max-size: Defines the maximum size of each log file. In this case, when the log file reaches 50MB, it will rotate.
max-file: Limits the number of rotated log files to retain. For example, with max-file: 3, Docker will keep 3 log files, and older ones will be deleted as new logs are created.

This configuration ensures that your application container does not use an excessive amount of disk space for logs, and the logs will be rotated automatically when they exceed the specified size.

Make sure to restart your Docker Compose stack to apply these changes:

docker-compose down
docker-compose up -d

Same can be done when running the containers without the compose file. Docker allows you to configure log rotation for containers directly through the --log-opt flag when running containers.
For example, setting max-size to limit the size of each log file and max-file to limit the number of log files can help prevent log overflow.

Example command to limit Docker container logs:

docker run --log-driver json-file --log-opt max-size=50m --log-opt max-file=3 <image>

Why Logs Can Flood the Server

Docker logs can flood a server when:

Excessive Logging by Containers: If a container generates large amounts of logs (e.g., error logs, debugging logs), they can grow rapidly.
Container Restart Loops: Containers that frequently restart due to errors can generate multiple logs per second, quickly consuming available disk space.
Lack of Log Rotation: Without configuring log rotation or size limits, Docker logs can accumulate indefinitely, which is particularly problematic for long-running containers.

By configuring systemd to limit the logs, we ensure that logs do not consume excessive disk space, preventing potential system slowdowns or crashes.

Additional Recommendations

Centralized Logging Solutions: Consider using centralized logging solutions like ELK Stack (Elasticsearch, Logstash, Kibana), Fluentd, or Graylog. These tools allow you to aggregate logs from multiple containers, set up retention policies, and avoid filling up local storage.
Monitoring Disk Usage: Regularly monitor disk usage and logs to catch any potential issues before they flood the server. Tools like docker system df can provide insights into Docker’s disk consumption.

Conclusion

Managing logs in Docker is critical to ensure system health and avoid running into disk space issues. By configuring systemd’s journald logging system and implementing Docker’s own log rotation mechanisms, you can effectively limit log growth. This ensures that your Docker containers provide the necessary insights without flooding your server's disk space.

Mastering Redux-Saga: Advanced Concepts and Use Cases 🌪️

Tejas Nikhar — Thu, 13 Feb 2025 05:00:00 +0000

While implementing the feature for creating project versions at my organization, I leveraged Redux-Saga's channel feature to schedule a recurring version creation action every 15 minutes. The way Redux-Saga manages channels and encapsulates complex logic for developers fascinated me. Despite its powerful capabilities, Redux-Saga is surprisingly underrated in the React community.

This article explores key Redux-Saga concepts and why they can be invaluable for React developers using middleware.

Introduction

Redux-Saga is a powerful middleware for handling side effects in Redux applications. While many developers are familiar with basic effects like takeLatest and call, the library offers advanced utilities that make it an underrated powerhouse for managing complex async flows.

In this article, we'll cover:

Essential Redux-Saga effects: put, call, fork, all, take, takeLatest, takeEvery,delay
Managing concurrent tasks with race
Leveraging actionChannel for queued processing
Using Redux-Saga channels for more controlled event handling
Practical examples and best practices

Understanding Key Redux-Saga Effects

`put`

Dispatches an action to the Redux store.

import { put } from "redux-saga/effects";

yield put({ type: "FETCH_SUCCESS", payload: data });

`call`

Calls a function (usually an API request) and waits for its response.

import { call } from "redux-saga/effects";

yield call(api.fetchUser, userId);

`fork`

Spawns a non-blocking task.

import { fork } from "redux-saga/effects";

yield fork(watchUserLogin);

`all`

Runs multiple sagas in parallel.

import { all, call } from "redux-saga/effects";

yield all([call(fetchUsers), call(fetchPosts)]);

`take`

Waits for a specific action before proceeding.

import { take } from "redux-saga/effects";

yield take("LOGIN_REQUEST");

`takeLatest`

Only the latest invocation of the saga will be executed, canceling previous ones.

import { takeLatest } from "redux-saga/effects";

yield takeLatest("FETCH_USER", fetchUserSaga);

`takeEvery`

Runs a saga for every action occurrence without canceling previous executions.

import { takeEvery } from "redux-saga/effects";

yield takeEvery("ADD_ITEM", addItemSaga);

`delay`

Delays execution for a specified time.

import { delay } from "redux-saga/effects";

yield delay(2000); // 2 seconds delay

Sign-Up Example: Combining Multiple Redux-Saga Effects

import { Action } from "@reduxjs/toolkit";
import {
  CallEffect,
  PutEffect,
  call,
  put,
  takeLatest,
} from "redux-saga/effects";
import { AxiosError, AxiosResponse } from "axios";
import { signUpRequest, signUpSuccess, signUpError } from "../actions";
import { SignUpRequest, SignUpSuccess, SignUpError } from "../../types/store";
import { signUpUser } from "../../api/signUp";
import { handleErrors } from "../../utils/error.handler";

function* signUp(
  action: Action & { payload: SignUpRequest; type: string }
): Generator<
  | CallEffect<AxiosResponse<void> | AxiosError<unknown>>
  | PutEffect<{ payload: SignUpSuccess | SignUpError; type: string }>
  | unknown,
  void,
  AxiosResponse<void>
> {
  try {
    if (signUpRequest.match(action)) {
      const response: AxiosResponse<void> = yield call(
        signUpUser,
        action.payload
      );
      if (response.status !== 201) {
        throw new Error("SignUp failed!");
      }
      yield put(
        signUpSuccess({
          error: null,
          success: true,
          feedbackMessage: "User Sign Up Successful",
        })
      );
    }
  } catch (error) {
    yield* handleErrors(error, signUpError);
  }
}

function* watchSignUpRequest(): Generator {
  yield takeLatest(signUpRequest.type, signUp);
}

export { watchSignUpRequest };

Leveraging Redux-Saga Channels for Auto Version Creation

Initial Implementation Using `take` and `delay`

The initial implementation used a simple while (true) loop with delay. Every AUTOSAVE_TIMEOUT milliseconds, a new autosave request was dispatched.

const autoCreateCanvasVersion = function* (params: CreateVersionRequest) {
  while (true) {
    yield put(createCanvasVersionRequest(params));
    yield delay(AUTOSAVE_TIMEOUT);
  }
};

While this approach works, it has several drawbacks:

Lack of Event Control: The loop runs indefinitely, making it difficult to stop the autosave process dynamically.
Inefficient Resource Usage: It keeps running even if the autosave feature is disabled, leading to unnecessary function executions.

To address these issues, we introduce eventChannel in the improved implementation.

Improved Implementation Using Channels

In the improved version, we use eventChannel to emit events at an interval, allowing external control over when autosave occurs. Instead of manually handling delays, Redux-Saga now reacts to incoming events efficiently.

import { eventChannel, buffers } from "redux-saga";
import {
  take,
  put,
  call,
  fork,
  select,
  takeEvery,
  cancel,
} from "redux-saga/effects";

// Creates an event channel that emits an autosave trigger at a fixed interval
const createAutoSaveChannel = () =>
  eventChannel((emit) => {
    const interval = setInterval(() => {
      emit(true);
    }, AUTOSAVE_TIMEOUT);

    return () => clearInterval(interval);
  }, buffers.sliding(1));

function* autoCreateCanvasVersion(params: CreateVersionRequest) {
  // Check version history flag once at the start
  const versionHistoryEnabled = yield select(selectVersionHistoryEnabled);
  if (!versionHistoryEnabled) return;

  const channel = yield call(createAutoSaveChannel);

  try {
    while (true) {
      yield take(channel);
      yield put(createCanvasVersionRequest(params));
    }
  } finally {
    channel.close();
  }
}

function* watchAutoCreateCanvasVersion() {
  yield takeEvery(startAutoCreate.type, function* (action) {
    const params: CreateVersionRequest = action.payload;
    const task = yield fork(autoCreateCanvasVersion, params);

    yield take(stopAutoCreate.type);
    yield cancel(task);
  });
}

Improvements Using Channels

Event-Driven Autosaving:

Instead of an infinite loop using delay, we now use an eventChannel that emits at fixed intervals. This prevents blocking issues and ensures that autosave events are managed externally.
Sliding Buffer Optimization:

We use a sliding(1) buffer so that if multiple autosave events are triggered while a previous one is still running, only the latest one is kept, avoiding unnecessary queuing of outdated save requests.
Efficient Stopping Mechanism:
- We check versionHistoryEnabled only once at saga startup and avoid unnecessary Redux state checks.
- Instead of relying on Redux state updates, we stop autosaving when stopAutoCreate is dispatched by cancelling the task.
- The finally block ensures that the event channel is closed when the saga exits, preventing memory leaks.

Conclusion

Redux-Saga offers an incredibly powerful way to manage side effects in Redux applications. With features like actionChannel and eventChannel, developers can gain fine-grained control over asynchronous processes.

If you’re interested in exploring more, check out the official Redux-Saga documentation: Redux-Saga Homepage.

Mastering GitHub Actions Strategy Matrix: Deploy Smarter, Not Harder ⚙️

Tejas Nikhar — Sat, 01 Feb 2025 02:30:00 +0000

Automating deployments is a crucial part of modern software development. Recently, while working on setting up GitHub Actions to deploy Docker-based AWS Lambdas, I came across the strategy matrix
feature in GitHub Actions. This feature amazed me because it drastically reduces repetitive configurations when deploying multiple services or Lambdas.

The Power of Strategy Matrix in GitHub Actions

GitHub Actions provides a strategy matrix, a feature that allows developers to define multiple configurations for their jobs and execute them concurrently. This significantly reduces deployment
times and improves efficiency, particularly when deploying multiple services or lambda functions.

Using a matrix, you can dynamically define configurations like operating systems, Node.js versions, services, or lambda configurations and run jobs simultaneously. This eliminates repetitive code and manual overhead.

Example: Deploying Multiple Docker-Based Lambdas

Here’s how you can set up a GitHub Actions workflow to deploy multiple Docker-based AWS Lambda functions. The strategy matrix enables us to define each lambda’s details (e.g., name, Dockerfile
path, and ECR repository) in a concise, reusable way.

name: Deploy Docker-Based Lambdas
on:
  workflow_dispatch:
    inputs:
      alias:
        description: "Select the alias for the Lambda function"
        required: true
        type: choice
        options:
          - DEV
          - STAGING
          - PRE-PROD

jobs:
  deploy-lambdas:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        lambda:
          - name: dockerLambda1
            dockerfile: dockerfile
            context: ./lambda/dockerLambda1
            tag: dockerLambda1
            ecr_repo: dockerLambda1
            function_name: dockerLambda1
          - name: dockerLambda2
            dockerfile: dockerfile
            context: ./lambda/dockerLambda2
            tag: dockerLambda2
            ecr_repo: dockerLambda2
            function_name: dockerLambda2
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      # Rest of the code: AWS configuration, Docker build, ECR push, and Lambda deployment

In this workflow:

matrix.lambda defines configurations for each Lambda.
GitHub Actions runs a job for each matrix entry, reducing manual duplication.
You can dynamically set environment variables like aliases based on branches.

Example: Deploying Multiple Docker Images to Google Cloud Run

Similarly, the strategy matrix can be used for deploying multiple services to Google Cloud Run. Here's how the setup looks:

name: Release all services
on:
  push:
    branches:
      - master

jobs:
  deploy:
    strategy:
      matrix:
        service: ["proctor", "screenshot", "stitch", "canvas-snap", "canvas-fuse"]
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      # Rest of the code: Google authentication, Docker build, push, and deployment

The matrix here dynamically configures each service, allowing seamless deployment.

Advanced Strategy Matrix Features

Fail-Fast Behavior

By default, GitHub Actions cancels all running jobs in a matrix if any job fails. This is helpful for detecting issues early and saving resources. However, you can disable this behavior if you need all jobs to complete, regardless of failures.

strategy:
  fail-fast: false
  matrix:
      version: [16, 18, 20]
steps:
  - uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.version }}

Setting fail-fast: false ensures all jobs complete, which is particularly useful for collecting a complete set of test results.

Max Parallel Jobs

For resource management, you can limit the number of matrix jobs running concurrently using the max-parallel key. This is especially useful with self-hosted runners or large matrices.

strategy:
  max-parallel: 2
  matrix:
      version: [16, 18, 20]
steps:
  - uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.version }}

In this configuration, no more than two jobs will run simultaneously, even if more runners are available.

Note: Avoid using max-parallel with runs-on self-hosted runners, as it may lead to
suboptimal behavior.

Using the Matrix Context and Job Index

The matrix context and strategy.job-index variable allow you to dynamically reference the current matrix configuration and job index. This is useful for identifying jobs or splitting tasks evenly.

jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node: [18, 20]
    runs-on: ${{ matrix.os }}
    steps:
      - name: Display matrix and index
        run: |
          echo "Running on ${{ matrix.os }} with Node.js ${{ matrix.node }}"
          echo "This is matrix job #${{ strategy.job-index }}"

Each job outputs its configuration (e.g., OS, Node.js version) and its zero-based index.

Key Takeaways

Simplify Repetitive Work: Use the strategy matrix to define multiple configurations for jobs, reducing redundancy.
Optimize Resource Use: Leverage fail-fast, max-parallel, and job indexing to balance efficiency and resource consumption.
Powerful for Deployments: Strategy matrix makes deploying multiple services or lambdas seamless, whether to AWS, Google Cloud, or other platforms.

By combining these advanced features, you can set up efficient and scalable workflows for a variety of CI/CD needs. For further reading, check the official GitHub documentation on the strategy matrix.

Understanding CORS and Setting it up with NestJS + Fastify 🚀

Tejas Nikhar — Thu, 16 Jan 2025 00:44:43 +0000

CORS, or Cross-Origin Resource Sharing, is a mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. Without CORS, modern browsers would block cross-origin requests for security reasons, preventing malicious behavior.

Why is CORS Necessary?

When building modern web applications, the frontend and backend often run on different domains or ports, especially during development. For example:

Frontend: http://localhost:3000
Backend: http://localhost:5000

By default, browsers block requests from the frontend to the backend due to the Same-Origin Policy. This is where CORS comes in—it acts as a controlled way to bypass the same-origin restriction, enabling secure communication.

A typical CORS scenario involves the frontend making an API call to the backend, and the backend explicitly allowing such requests by including certain headers in its response.

Configuring CORS in NestJS with Fastify

While enabling CORS in a NestJS application using Express is straightforward, using Fastify requires a slightly different approach. When I was working on a project, I decided to switch from Vite’s proxy server to enabling CORS on my Fastify server, both as a learning opportunity and for better alignment with production setups. However, I found the documentation and available articles on enabling CORS for Fastify in NestJS to be sparse.

Here’s how I tackled it.

Step 1: Define CORS Options

To keep things clean and reusable, I created a dedicated cors.options.ts file for my CORS configuration. Here's what it looks like:

import { type CorsOptions } from "@nestjs/common/interfaces/external/cors-options.interface";

const CorsOptions: CorsOptions = {
    origin: [
        // ? Development environment
        "http://localhost:3000",
        // * Add Production and Staging URLs here
    ],
    methods: "GET,HEAD,PUT,PATCH,POST,DELETE",
    allowedHeaders: "Content-Type, Authorization",
    credentials: true,
    maxAge: 86400,
};

export { CorsOptions };

Step 2: Use CORS Options in the Main Application

In the main.ts file, I configured the Fastify server to use these options:

import { NestFactory } from "@nestjs/core";
import { FastifyAdapter, NestFastifyApplication } from "@nestjs/platform-fastify";
import helmet from "@fastify/helmet";

import { CorsOptions } from "./options/cors.options";
import { AppModule } from "./app.module";

const bootstrap = async (): Promise<void> => {
    const FastifyModule = new FastifyAdapter();

    // Enabling things for Fastify server
    FastifyModule.register(helmet); // Secure headers
    FastifyModule.enableCors(CorsOptions); // Enable CORS with custom options

    const app = await NestFactory.create<NestFastifyApplication>(AppModule, FastifyModule);

    // Start the application
    const PORT = 5000;
    await app.listen(PORT, () => {
        console.log(`Server is running on http://localhost:${PORT}`);
    });
};

bootstrap();

Key Points to Note

Origins: I specified the allowed origins explicitly, such as http://localhost:3000 for development. Add production or staging URLs as needed.
Methods: Only specific HTTP methods like GET, POST, and DELETE are allowed.
Credentials: By setting credentials: true, the server allows cookies or authentication tokens to be sent with requests.
Modular Approach: Placing the CORS options in a separate file helps maintain modularity and makes it easier to modify configurations in the future.

Axios Configuration for the Frontend

Here is my axiosConfig.ts file, showing how I have configured Axios for the frontend:

import axios, { AxiosRequestConfig } from "axios";

import { ContentType, ResponseType, ResponseEncoding } from "../config/requestConfig";

const baseURL = (import.meta.env.VITE_API_BASE_URL as string) ?? "http://localhost:5000";

const axiosRequestConfig: AxiosRequestConfig = {
    baseURL,
    headers: {
        "Content-Type": ContentType.JSON,
    },
    timeout: 330000,
    withCredentials: true,
    responseType: ResponseType.JSON,
    responseEncoding: ResponseEncoding.UTF8,
    maxContentLength: 50000,
    validateStatus(status) {
        return status >= 200 && status < 300;
    },
    maxRedirects: 5,
};

const AxiosInstance = axios.create(axiosRequestConfig);

export { axiosRequestConfig, AxiosInstance };

Learnings and Final Thoughts

While configuring CORS for Fastify in NestJS, I initially used Express-specific solutions, which felt incorrect and hacky. After thorough research, I found the proper way to enable it using the
enableCors method of the Fastify adapter.

If you’re using my Verdant turborepo template, you can find an example of this CORS configuration there. The repo also demonstrates how to structure a modern monorepo using tools like TurboRepo and Vite.

If you want to learn more about CORS, check out this MDN article, which does a fantastic job of explaining the concept in detail.

CORS can seem tricky initially, but with the right approach, it’s straightforward to configure and ensures secure communication between your frontend and backend.

Setup Development Environment with Docker for Monorepo 🐳

Tejas Nikhar — Sun, 18 Apr 2021 07:16:09 +0000

Docker is a set of the platform as service products that use OS-level virtualization to deliver software in packages called containers. Containers are isolated from one another and bundle their own software, libraries, and configuration files; they can communicate with each other through well-defined channels.

In version control systems, a monorepo is a software development strategy where code for many projects is stored in the same repository.

Why set up a Development Environment?

While developing a Full-Stack app we come across many things which we have to configure and are necessary for building that application. Moreover, we might be working in a team or it may be an Open-Source Project which has many contributors. As we consider these things we can definitely see, the old excuse "It was working fine on my machine...". One can also implement the development setup on their portfolio projects to showcase that they can implement their knowledge about Docker and also familiarizing themselves with it.

Most of us know that we want a fast development and build process to tackle this. We set up a development environment for our project using Docker to develop seamlessly without any OS-level errors.

The practice here is one way you can implement Docker. There might be many ways that might suit your scenario, so try to research more and try implementing them with the trial and error method, and remember implementing them would definitely help in the long term.

Step 1: Know your Project

For the demo, we are using my own Project which consists of React frontend and Nodejs Backend.

Link to repo → https://github.com/tejastn10/ShoeShoppee

Step 2: Add dev Dockerfiles to the project

💡 NOTE: If you're using Vs-Code it provides so much help in creating and managing Dockerfiles for your environment. I'll provide a link showcasing how you can utilize Vs-Code to its full abilities and add docker configuration for your platform. Vs-Code adds all that is required such as dockerignore files and even debug configuration if specified.

Link to video → Supercharge Your Docker Development with VS Code

Frontend Dockerfile
The frontend Dockerfile is located in the frontend/web folder.

FROM node:alpine

WORKDIR "/app"

RUN yarn global add typescript
RUN yarn global add less

COPY ./package.json ./
COPY ./yarn.lock ./

RUN yarn install

COPY . .

RUN lessc --js ./src/styles/theme.less ./src/styles/theme.css

CMD [ "yarn", "start" ]

Backend Dockerfile
The backend Dockerfile is located in backend folder.

FROM node:alpine

WORKDIR "/app"

RUN yarn global add typescript

COPY ./package.json ./
COPY ./yarn.lock ./

RUN yarn install

COPY . .

CMD [ "yarn", "server" ]

Nginx Dockerfile

The nginx Dockerfile is located in nginx folder.

FROM nginx

COPY ./default.conf /etc/nginx/conf.d/default.conf

These files are named Dockerfile.dev for specifying that these are for development purposes only.

Step 3: Add dev Docker-compose file to the project

The root folder contains the compose file adding all the services specified in the respective Docker files. In my project, the development docker-compose file is docker-compose.debug.yml

version: "3.4"

services:
  nginx:
    restart: always
    build:
      dockerfile: Dockerfile.dev
      context: ./nginx
    ports:
      - 3000:80
  backend:
    build:
      dockerfile: Dockerfile.dev
      context: ./backend
    volumes:
      - /app/node_modules
      - ./backend:/app
    environment:
      - NODE_ENV=development
      - PORT=5000
      - JWT_SECRET=clocked
      - MONGO_URI
  frontend:
    build:
      dockerfile: Dockerfile.dev
      context: ./frontend/web
    volumes:
      - /app/node_modules
      - /app/src/styles
      - ./frontend/web:/app
    environment:
      - NODE_ENV=development
      - REACT_APP_DEVELOPMENT_API_ENDPOINT=/devURL

Step 4: Starting the project with docker-compose up

Now all that remains is to build and run the compose file and voila your setup is complete.

docker-compose -f ./docker-compose.debug.yml up --build

This article assumes prior knowledge about Docker, not much but familiarity with the tech is sufficient. Do tell me how you would implement yours and also provide me where I can improve my configuration.

Making Terminal Awesome!!✨🤩

Tejas Nikhar — Sun, 07 Feb 2021 09:24:49 +0000

I started using Linux almost a year ago as my main OS which provided a great experience. The terminal provided a lot more freedom from windows cmd or power-shell, which prompted me to do some digging about the terminal so that I can use it to its full extent.

Then I stumbled upon ZSH (Z-shell) which is based on BASH and has the same features as BASH plus some interesting plugins and theme options.

So here's my setup for ZSH.

Installing ZSH

Make sure that you have curl and git installed if not then just install them.

sudo apt-get install curl git

Later install ZSH

sudo apt-get install zsh

Adding OhMyZSH

You can search for it or enter the following command.

sh -c "$(curl -fsSL [https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh](https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh))"

This will add OhMyZSH.

There will be a prompt asking to make it default terminal press enter there.

Making it the way you want...

So the default ZSH theme is good but I know most of them used agnoster as their theme.

Moreover, it requires some special fonts to work properly. So let's install them.

sudo apt-get install fonts-powerline

Later add the theme to the zshrc file.

nano ~/.zshrc

ZSH_THEME="agnoster"

Then save the file and close the editor and source the file

source ~/.zshrc

And Voila! the theme and fonts should be applied to the terminal now.

NOTE: If the fonts are not yet seen then try logging out and back in or better restart your PC. I did face issues with it too.

You can even set it to random which will show you various themes every time you close and open a new terminal and the one you like you can just set it as your default.

Plugins

The plugins offered by OhMyZSH are great in helping as they provide wonderful aliases.

NOTE: If adding a lot of plugins they do slow the startup of the shell. But there's a fix for that too called instant prompt

You can find all the plugins at the link below:

https://github.com/ohmyzsh/ohmyzsh/wiki/Plugins

My two favorite are these:

zsh-autosuggestions
zsh-syntax-highlighting

You can install them with these or referring to the documentation.

sudo git clone [https://github.com/zsh-users/zsh-autosuggestions](https://github.com/zsh-users/zsh-autosuggestions) ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

sudo git clone [https://github.com/zsh-users/zsh-syntax-highlighting.git](https://github.com/zsh-users/zsh-syntax-highlighting.git) ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

and then adding it to the zshrc file

plugins=(
# Git
git
# ZSH
zsh-autosuggestions
zsh-syntax-highlighting
)

and sourcing it.

As it has been a year I have tweaked it much more.

Now I use the powerlevel10k theme which is super cool. you can check it out too they have an initial setup that shows all the customization they have provided so go ahead and experiment and choose whichever you like. Moreover, WSL too supports it.

So this is my current terminal and I 😉 want to see yours too.

Setting up Express Server 📡 with TypeScript

Tejas Nikhar — Sat, 30 Jan 2021 07:32:59 +0000

Express.js is a web application framework that is built on top of Node.js. It provides a minimal interface with all the tools required to build a web application. Express.js adds flexibility to an application with a huge range of modules available on npm that you can directly plug into Express as per requirement.

Step 1: Create a .gitignore file

Add node_modules/ and .env in it as we don't want node modules to be pushed to GitHub and also our secret keys to be publicly available.

node_modules/
.env

Step 2: Add dependencies

You may use yarn or npm (I am using yarn here).

yarn add for dependencies

yarn add -D for dev dependencies

NOTE: We might add more later on... and discuss them as we move along. Also, the version may be newer for you or some of the packages may be deprecated in the future. Also as we are using typescript we require type-definitions (@types) of all dependencies we have added

The dependencies shown below are the basic ones I think are required for the server to be up and running.

"dependencies": {
    "colors": "^1.4.0",
    "cors": "^2.8.5",
    "dotenv": "^8.2.0",
    "express": "^4.17.1",
  },
  "devDependencies": {
    "@types/cors": "^2.8.9",
    "@types/express": "^4.17.9",
    "concurrently": "^5.3.0",
    "nodemon": "^2.0.6"
  }

Step 3: Create tsconfig.json file and add the following

Configuring TypeScript

You might want to look at the official documentation providing more insights for configuring TypeScript and study more parameters available and use according to your needs.

{
  "compilerOptions": {
    /* Basic Options */
    "target": "es6" /* Specify ECMAScript target version. */,
    "module": "commonjs" /* Specify module code generation. */,
    "sourceMap": false /* Generates corresponding '.map' file. */,
    "outDir": "./dist" /* Redirect output structure to the directory. */,
    "rootDir": "./src" /* Specify the root directory of input files. */,

    /* Strict Type-Checking Options */
    "strict": true /* Enable all strict type-checking options. */,

    /* Module Resolution Options */
    "moduleResolution": "node" /* Specify module resolution strategy. */,
    "baseUrl": "./" /* Base directory to resolve non-absolute module names. */,
    "paths": {
      "*": ["node_modules/", "src/types/*"]
    } ,
    "esModuleInterop": true ,

    /* Advanced Options */
    "skipLibCheck": true /* Skip type checking of declaration files. */,
    "forceConsistentCasingInFileNames": true 
  },
  "include": ["src/**/*"],
"exclude": ["src/types/*.ts", "node_modules", ".vscode"]
}

Step 4: Create the main file

Create an src folder in your directory and add an app.ts file with the following contents to get your express server up and running.

Relative Path: src/app.ts

import express, { Application, json, Request, Response } from "express";
import "colors";
import cors from "cors";
import { config } from "dotenv";

config();

const app: Application = express();

app.use(cors());
app.use(json());

const PORT: string | number = process.env.PORT || 5000;
const ENV: string = process.env.NODE_ENV || "development";

app.get("/", (_req: Request, res: Response) => {
  return res.send("API Running...");
});

app.listen(PORT, () =>
  console.log(
    ` 📡 Backend server: `.inverse.yellow.bold +
      ` Running in ${ENV} mode on port ${PORT}`
  )
);

Step 5: Setting up running scripts

Add the following to the package.json file

"scripts": {
    "watch-ts": "tsc -w",
    "server": "nodemon dist/app.js",
    "dev": "concurrently -k -p \"[{name}]\" -n \"Typescript,Node\" -c \"blue.bold,yellow.bold\" \"yarn run watch-ts\" \"yarn run server\" "
  }

Now run "yarn run dev " to start our server and voila we have our server up and running.

You should see this as your output in the terminal and dist/ directory should appear in your project containing all the JavaScript code with ES6 syntax.

Also, there's a ts-node package that runs node server using TypeScript files without any need to generate any JavaScript files.

Forem: Tejas Nikhar

Understanding DNS Record Types: A Practical Deep Dive 🌍

What is DNS and Why Does It Matter?

How DNS Resolution Actually Works

Common DNS Record Types and Their Uses

1. A Record (Address Record)

2. AAAA Record (IPv6 Address Record)

3. CNAME Record (Canonical Name Record)

4. MX Record (Mail Exchange Record)

5. TXT Record (Text Record)

6. SRV Record (Service Record)

7. NS Record (Name Server Record)

8. PTR Record (Pointer Record)

9. SOA Record (Start of Authority Record)

Understanding TTL and DNS Propagation

DNS Security: Protecting the Internet's Directory

DNSSEC (DNS Security Extensions)

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Troubleshooting DNS Issues: Tools I've Found Helpful

How DNS Records Impact SSL Certificate Management

1. DNS-01 Challenge for Certificate Renewal

2. CNAME Updates and Propagation Delays

Advanced DNS Strategies

Round-Robin DNS

Subdomain Delegation

Key Takeaways

Mastering React Events: Understanding, Debugging, and Optimizing Event Handling 🚀

The Curious Case of the Disappearing Tooltip

Understanding React's Synthetic Event System

Why Synthetic Events?

How Synthetic Events Work

The Evolution of Event Pooling

Common React Events and Their Use Cases

1. Mouse Events

2. Keyboard Events

3. Form & Input Events

4. Clipboard Events

5. Drag & Drop Events

6. Touch Events (Mobile)

7. Focus Events

8. Composition Events (IME input handling)

9. Wheel Events

10. Media Events

Event Propagation: Bubbling, Capturing, and Stopping Events

Understanding the Event Flow

Handling Events Like a Pro: Custom Wrappers

Debouncing and Throttling Events

Throttling for Scroll and Resize Events

React Hooks and Event Handling

Using useCallback for Event Handlers

Adding Global Event Listeners with useEffect

Common Event Handling Patterns

Controlled Forms

Event Delegation in Lists

React 18 Event Handling Considerations

Automatic Batching

useTransition for Non-Urgent Updates

Performance Optimization Tips

Avoid Creating Functions in Render

When to Use Inline Functions

Conclusion

Deep Dive into NestJS Decorators: Internals, Usage, and Custom Implementations 🛠️

Introduction

1. Understanding TypeScript Decorators

What Are Decorators?

The Current State of Decorators in JavaScript

How TypeScript Implements Decorators

Different Types of Decorators

What Happens During Compilation?

2. How NestJS Uses Decorators Internally

NestJS Decorators & reflect-metadata

What Exactly is reflect-metadata?

Example: Using reflect-metadata in NestJS

How NestJS Uses reflect-metadata Under the Hood

3. Deep Dive: How NestJS Executes Decorators Internally

The NestJS Bootstrapping Process

Step-by-Step Execution of a Decorator

Real-World Example: How @Injectable() Works

4. Custom Decorators in NestJS

Example: Creating a @Permissions Decorator

NestJS Decorators & `reflect-metadata`

What Exactly is `reflect-metadata`?

Example: Using `reflect-metadata` in NestJS

How NestJS Uses `reflect-metadata` Under the Hood

Real-World Example: How `@Injectable()` Works

Example: Creating a `@Permissions` Decorator

Preventing Log Floods Using `systemd` Configuration

Steps to Limit `journald` Logs:

`put`

`call`