Coder Legion - Recent posts tagged nest

Thinking auth in producation systems a dive on the backend

Sat, 07 Feb 2026 15:07:52 +0000

When building an application, authentication is unavoidable. You can outsource it to services like Clerk or Better Auth and be productive fast, but that convenience often comes with trade-offs: third-party lock-in, limited control over flows, and opaque behavior when things go wrong.

In production systems, authentication is not just about logging users in. It shapes your security model, influences your database design, and quietly dictates how scalable and debuggable your system will be.

In this article, I’ll walk through how I designed and implemented authentication for a real production project, the decisions I had to make, and the compromises that came with them. Since all systems have different auth requirements, it might vary from your version.

Requirements for my project

For this project, authentication needs to be intentionally simple:
email + password–based registration and login, with Google OAuth as an alternative for both signup and sign-in.

If a user registers using email and password, the email must be verified via a verification link. Once the email is verified, the user is automatically logged in. The frontend receives the required tokens and user context without forcing an additional login step.

Strategy

For this project, I’m using a JWT-based authentication approach with short-lived access tokens and refresh tokens, with refresh token rotation enabled.

private async generateTokens(
    userId: string,
    email: string,
    role: number,
    deviceId: string,
  ) {
    const accessTokenSecret =
      this.configService.get<string>('JWT_ACCESS_SECRET');

    const refreshTokenSecret = this.configService.get<string>(
      'JWT_REFRESH_TOKEN_SECRET',
    );

    const accessTokenExpiryRaw = this.configService.get<string>(
      'JWT_ACCESS_TOKEN_EXPIRE_TIME',
      '1h',
    );
    const refreshTokenExpiryRaw = this.configService.get<string>(
      'JWT_REFRESH_TOKEN_EXPIRE_TIME',
      '7d',
    );

    const accessTokenTtlMs = ms(accessTokenExpiryRaw);
    const refreshTokenTtlMs = ms(refreshTokenExpiryRaw);

    const [accessToken, refreshToken] = await Promise.all([
      this.jwtService.signAsync(
        { sub: userId, email, role },
        {
          secret: accessTokenSecret,
          expiresIn: Math.ceil(accessTokenTtlMs / 1000),
        },
      ),
      this.jwtService.signAsync(
        { sub: userId, email, role },
        {
          secret: refreshTokenSecret,
          expiresIn: Math.ceil(refreshTokenTtlMs / 1000),
        },
      ),
    ]);

    // Extract the signature part of the JWT
    const accessTokenSignature = accessToken.split('.')[2];

    // Keyv expects TTL in ms - cache key includes deviceId for device-specific validation
    await this.cacheManager.set(
      `${CacheKey.ACCESS_KEY}:${userId}:${deviceId}`,
      { tokenSignature: accessTokenSignature, deviceId },
      accessTokenTtlMs,
    );

    return { accessToken, refreshToken };
  }

To minimize authentication lookup latency, access tokens are cached in Redis, mapped to the corresponding user_id and device_id. This allows the system to validate active sessions without hitting the primary database on every authenticated request.

Device Identification
Each client device is assigned a unique deviceId, generated on the backend.

My first approach was to derive this identifier from the IP address and user agent. From a security perspective, this worked well. Tokens were tightly bound to their original context, and replaying them from elsewhere was difficult.

In practice, though, IP addresses change far more often than you’d expect, especially for mobile users. The result was unnecessary session invalidation and a poor user experience.

After weighing those trade-offs, I switched to deriving the deviceId from the user ID and user agent instead.

The goal of the deviceId is simple:

Avoid duplicate session entries in Redis when a user logs in multiple times from the same device
Make session tracking and revocation possible on a per-device basis
Add an extra check during token validation beyond signature and expiry
By anchoring sessions to a deterministic deviceIdRedis maintains a single active access-token entry per device rather than accumulating redundant session data.

In practice, access and refresh tokens are validated not just by their cryptographic signature and expiration, but also by the reason the deviceId they were issued for. This means that even if a token is leaked, it can’t be trivially replayed from a completely different device context unless the attacker also replicates the same user agent.

  private generateDeviceFingerprint(userId: string, userAgent: string): string {
    const raw = `${userId}|${userAgent}`;
    return crypto
      .createHash('sha256')
      .update(raw)
      .digest('hex')
      .substring(0, 32);
  }

User agents aren’t secret, and this is not meant to be a perfect defense. What it does provide is a meaningful reduction in the blast radius of token leakage and protection against a large class of naive replay attacks.

This approach intentionally trades stronger environmental binding for stability and usability. For this system, that trade-off is acceptable. The deviceId isn’t a cryptographic fingerprint; it’s a pragmatic mechanism to keep sessions predictable, revocable, and reasonably safe in production.

Schema design

For authentication, the core requirements can be met with just two tables: one to represent the user, and another to track login sessions via refresh tokens.

Table users {
  id        uuid PK        // uuidv7
  name      string
  email     string UNIQUE NOT NULL
  password  string null // hashed password
  role      int NOT NULL   // 0 = user, 1 = admin, 2 = super_admin
  created_at timestamp
  updated_at timestamp
}
Table user_login_tokens {
  id                     uuid PK
  user_id                uuid FK -> users.id
  device_id              string
  refresh_token_signature string NOT NULL
  user_agent             string
  ip_address             string
  expires_at             timestamp NOT NULL
  revoked_at             timestamp
  created_at             timestamp
}

Rate Limiting & Abuse Protection
Authentication endpoints are a natural target for abuse, so basic rate limiting is enforced at the infrastructure level using Redis.

Rather than applying a single global limit, rate limiting is scoped by action and tracked independently by IP address and email. This allows the system to respond differently to suspicious behavior without punishing legitimate users.

The following flows are protected:

Login attempts.
Registration attempts
Forgot password requests
Each flow has its own threshold, time window, and temporary block duration.

How It Works

For every request, the system checks whether the IP address or email is currently blocked for the given action. If either is blocked, the request is rejected immediately.

On failed attempts, counters are incremented in Redis with a short TTL. Once the configured threshold is exceeded, a temporary block is applied, and the counter is cleared. Successful authentication clears any existing attempt counters.

This keeps rate limiting fast, stateless, and independent of the primary database.

Here’s an example:

this.loginConfig = {
  maxAttempts: this.configService.get<number>('AUTH_LOGIN_MAX_ATTEMPTS', 5),
  windowMs: this.configService.get<number>('AUTH_LOGIN_WINDOW_MS', 60000),
  blockDurationMs: this.configService.get<number>('AUTH_LOGIN_BLOCK_MS',
    60000,
  ),
};

// Registration: 3 attempts per 5 minutes, blocked for 5 minutes
this.registerConfig = {
  maxAttempts: this.configService.get<number>(
    'AUTH_REGISTER_MAX_ATTEMPTS',
    3,
  ),
  windowMs: this.configService.get<number>(
      'AUTH_REGISTER_WINDOW_MS',
      300000,
  ),
  blockDurationMs: this.configService.get<number>(
      'AUTH_REGISTER_BLOCK_MS',
      300000,
    ),
};

// Forgot Password: 3 attempts per 5 minutes, blocked for 5 minutes
this.forgotPasswordConfig = {
   maxAttempts: this.configService.get<number>(
      'AUTH_FORGOT_MAX_ATTEMPTS',
      3,
   ),
   windowMs: this.configService.get<number>('AUTH_FORGOT_WINDOW_MS', 300000),
   blockDurationMs: this.configService.get<number>(
     'AUTH_FORGOT_BLOCK_MS',
     300000,
   ),
}

Token Lifecycle & Rotation
Access tokens in this system are intentionally short-lived. Any long-running session relies on refresh tokens, which makes the refresh flow a critical security boundary.

To handle this safely, refresh tokens are rotated on every use.

Refresh Flow

When a client requests a new access token using a refresh token, the system performs the following steps inside a database transaction:

Revoke the existing refresh token
The refresh token used for the request is immediately marked as revoked. This ensures that a refresh token can only be used once.
Re-evaluate the device context
The request’s device information is re-derived on the backend, ensuring that the new tokens are bound to the correct deviceId.
Issue a new token pair
A fresh access token and refresh token are generated and returned to the client.
Persist the new refresh token
The new refresh token is stored in the database, replacing any existing token for the same user-device combination.
This entire flow is executed atomically. Either all steps succeed, or none do.

Why Rotation Matters

Refresh token rotation prevents an entire class of replay attacks.

If a refresh token is leaked and reused:

The first request succeeds and rotates the token
Any subsequent reuse of the old token fails because it has already been revoked
This ensures that a compromised refresh token has a very limited window of usefulness.

Failure Behavior

If a refresh token is revoked, expired, or does not match the stored signature for the given device, the refresh request is rejected. At that point, the client must re-authenticate.

This makes refresh token misuse noisy, detectable, and self-limiting.

Design Trade-off

This approach slightly increases complexity compared to static refresh tokens, but it dramatically improves security and debuggability.

Token rotation turns refresh tokens from long-lived secrets into single-use credentials, which aligns much better with production threat models.

logout and token revocations
Logout is handled server-side.

When a user logs out:

The refresh token for the current session is revoked in the database
The cached access token for the corresponding userId and deviceId is removed from Redis
After this, the session cannot be refreshed, and any in-flight access tokens are rejected.

Logout is scoped to the current device. Other active sessions remain unaffected unless explicitly revoked.

async logout(userId: string, refreshToken: string, request: Request) {
    return await this.sequelize.transaction(async (t) => {
      const dbOptions = { transaction: t };
      // Revoke refresh token in database
      await this.tokenRepository.revokeRefreshToken(
        userId,
        refreshToken,
        dbOptions,
      );

      // Clear access token from cache
      // Extract device info and clear specific device cache

      const { deviceId } = this.extractDeviceInfo(request, userId);
      deleteFromCache(userId, deviceId)

      return null;
    });
  }

Email Verification Token Handling

On events like registration, or forgot password, or a verification token is created, which is sent through email to the user. where the web passes that token along with the other information, i.e., the new password field, to change the password.

These tokens live shortly in Redis; on successful request processing, these tokens are deleted, and the database is updated properly.

Password reset tokens are intentionally not bound to a device. These flows are designed to work across devices and browsers, and binding them to a device context would introduce unnecessary friction without meaningful security benefits.

// a generic implementation without rate limiting, since it's getting long
 async resetPassword(email: string, token: string, newPassword: string) {
    let payload: any;
    try {
      payload = await this.jwtService.verifyAsync(token, {
        secret: this.configService.get<string>('JWT_VERIFICATION_SECRET'),
      });
    } catch {
      throwBadRequest('auth.INVALID_OR_EXPIRED_TOKEN');
    }
    if (payload.email !== email || payload.type !== 'password_reset') {
      throwBadRequest('auth.INVALID_CREDENTIALS');
    }
    const tokenSignature = token.split('.')[2];
    const cacheKey = `reset_password_token:${tokenSignature}`;
    const userId = await this.cacheManager.get<string>(cacheKey);
    if (!userId) {
      throwBadRequest('auth.INVALID_OR_EXPIRED_TOKEN');
    }
    const hashedPassword = this.hashPassword(newPassword);
    await this.usersService.updateById(userId, { password: hashedPassword });
    await this.cacheManager.del(cacheKey);
    return null;
  }

Closing thoughts
This authentication system is built around clear trade-offs rather than generic patterns. Short-lived access tokens, refresh token rotation, per-device sessions, explicit revocation, and targeted rate limiting together provide predictable behavior and reasonable security without unnecessary complexity.

Follow me on X (formerly known as Twitter): https://x.com/Itstheanurag

False Alerts in Crypto: Why Manual Verification Still Matters In today’s crypto ecosystem

Sat, 27 Dec 2025 17:57:28 +0000

False Alerts in Crypto: Why Manual Verification Still Matters

In today’s crypto ecosystem, automated security and risk-detection systems are everywhere.
Wallets, exchanges, and block explorers use AI and algorithms to protect users from scams.
This is a good thing — but it is not perfect.
Recently, our project experienced a false security alert triggered during a normal transaction.
The system flagged it as “high risk,” even though all funds, addresses, and contracts were legitimate and verifiable on-chain.
This is not a rare case.
It happens when systems rely on pattern-matching instead of real blockchain context.
Why false alerts happen
Most crypto security engines work like this:
They look for similar behavior to known scams
They check address history
They analyze transaction patterns
But they do not understand project structure, multisig wallets, locked liquidity, or DAO-style treasury movement.
So when a project:
Uses multisignature wallets
Moves liquidity
Executes token burns
Or interacts with bridges
…the system can mistakenly flag it as risky.
️ Why manual verification is essential
Blockchain is transparent by design.
Anyone can verify:
Contract ownership
Burn addresses
Liquidity locks
Multisig treasuries
On-chain transaction history
A warning is only a signal, not proof.
Real verification requires:
Checking the contract on BscScan / Etherscan
Reviewing DxLock or liquidity lockers
Checking multisig wallets
Reviewing GitHub, website, and docs
This is what serious investors do.
What this means for investors
A smart investor should:
Never trust an alert blindly
Never trust a project blindly
Always verify on-chain
Security systems are useful,
but blockchain truth is stronger.
What this means for serious crypto projects
Transparent projects should:
Lock liquidity
Use multisig wallets
Publish on-chain proof
Maintain public documentation
When this is done, no automated alert can damage the truth.

Why NestJS is the Future of Scalable Backend Development and Why Angular Developers Love NestJS

Sat, 27 Sep 2025 08:23:15 +0000

When it comes to backend frameworks in the Node.js ecosystem, developers often debate between Express, Fastify, or rolling their own custom setup. But if you’re looking for scalability, maintainability, and developer productivity, my money’s on NestJS!

What Makes NestJS Stand Out?

NestJS combines the raw performance of Express or Fastify with the structure of TypeScript decorators and dependency injection. This unique blend makes it incredibly powerful for building large-scale, enterprise-ready applications.

Key Features

TypeScript-first: Strong typing and modern language features out of the box.
Dependency Injection (DI): Clean, testable code with reduced boilerplate.
Angular-inspired design: Perfect for developers coming from Angular since it shares similar patterns like modules, services, and decorators.
Modular Architecture: Split your app into feature modules, making it easier to scale and maintain.
GraphQL, REST, and Microservices support: Build APIs and distributed systems without heavy lifting.

Why Angular Developers Love NestJS

If you’ve worked with Angular, NestJS will feel like home. Concepts like @Injectable(), @Module(), and @Controller() provide a familiar experience. This consistency lowers the learning curve and makes frontend and backend teams more aligned.

Example of a simple controller:

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

@Controller('users')
export class UsersController {
  @Get()
  findAll() {
    return ['John Doe', 'Jane Doe'];
  }
}

Minimal code, maximum clarity.

Real-World Use Cases

Enterprise APIs: Companies building scalable SaaS products use NestJS to manage complex user flows and high traffic.
Microservices: Native support for message brokers like Kafka, RabbitMQ, and NATS makes it ideal for distributed systems.
GraphQL Gateways: With @nestjs/graphql, you can quickly spin up a fully typed GraphQL API.
Fintech & Healthcare Apps: The strict architecture and modularity make it easier to meet compliance and security standards.

Performance Considerations

NestJS allows you to choose between Express (widely adopted) and Fastify (faster, lightweight) as the underlying HTTP engine. This flexibility lets teams balance between ecosystem maturity and raw performance.

Developer Experience

CLI Tools: Quickly scaffold controllers, services, and modules.
Testing: Built-in utilities for unit and e2e testing.
Ecosystem: Rich integrations with databases (TypeORM, Prisma, Mongoose), authentication libraries, and cloud services.

Final Thoughts

NestJS isn’t just another framework—it’s a complete development platform for Node.js. Its Angular-like structure, modular architecture, and multi-protocol support make it the go-to choice for building robust backends.

If you’re a developer looking to scale your skills and applications, NestJS is where you should place your bet.

Why Jest with Angular?

Wed, 04 Jun 2025 08:51:42 +0000

To use Jest with an Angular project (instead of the default Karma + Jasmine setup), follow this structured guide to configure it properly.

Benefits

Faster test execution (especially with --runInBand and --watch).

Easier debugging (rich error messages).

Snapshot testing support.

Widely used in React and Node.js ecosystems

setup jest

> npm install -D jest jest-preset-angular @types/jest

>npm remove @types/jasmine jasmine-core karma karma-chrome-launcher karma-coverage karma-jasmine karma-jasmine-html-reporter

Create 2 jest setup files

jest.config.js(javascript file)

In your project root, create /jest.config.js (.js javascript file) with the following contents.
(NOTE: The file name is reserved by jest, and jest looks up this file for configuration.)

module.exports = {
  preset: 'jest-preset-angular',
  setupFilesAfterEnv: ['<rootDir>/setup-jest.ts'],
};

setup-jest.ts

In your project root, create /setup-jest.ts with the following contents.
(INFO: You may change the filename with your preference as long as the file name is matched in the jest.config.js)

import 'jest-preset-angular/setup-jest';

Update files

tsconfig.spec.json (Original file created by 'ng new' command.)

(1) Change types from “jasmine” to “jest”.
(2) Remove files.

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": ["jasmine"]
  },
  "files": ["src/test.ts", "src/polyfills.ts"],
  "include": ["src/**/*.spec.ts", "src/**/*.d.ts"]
}

The following is after the changes.

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": ["jest"]
  },
  "include": ["src/**/*.spec.ts", "src/**/*.d.ts"]
}

tsconfig.json

Add “esModuleInterop”: true in the CompilorOptions to remove a warning message. (See the warning message in Appendix)

{
  "compileOnSave": false,
  "compilerOptions": {
    "baseUrl": "./",
    "outDir": "./dist/out-tsc",
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "sourceMap": true,
    "declaration": false,
    "downlevelIteration": true,
    "experimentalDecorators": true,
    "moduleResolution": "node",
    "importHelpers": true,
    "target": "es2017",
    "module": "es2020",
    "lib": ["es2018", "dom"],
    "esModuleInterop": true
  },
  "angularCompilerOptions": {
    "enableI18nLegacyMessageIdFormat": false,
    "strictInjectionParameters": true,
    "strictInputAccessModifiers": true,
    "strictTemplates": true
  },
  "types": ["jest"]
}

package.json

Change the test script from ng test to jest

"scripts": {
  "test": "ng test"
},==>"scripts": {
  "test": "jest --coverage"
},

Remove 2 files

Remove “/src/test.ts” and “/karma.config.js”.

Run jest with coverage option

Run npm run test, which invokes the script “jest --coverage”

Remove test object from angular.json file

Another option to create jest config files

npx jest — init

"test": "jest --verbose",
"test:coverage": "jest --coverage",
"test:watch": "jest --watch"

The Hidden Truth About Booleans in .env Files: Why 'false' Is Still Truthy in JavaScript

Sun, 11 May 2025 15:49:03 +0000

Understanding Environment Variables in Node.js

In Node.js (and frameworks like NestJS), environment variables, typically managed through .env files and accessed using process.env, are always strings. This subtle fact can introduce unexpected bugs, especially when you're expecting a boolean (true or false) but get a string ("true" or "false").

Real-World Example in a Node.js/NestJS Project

Suppose you have a .env file like this:

DB_SYNCHRONIZE=false
DB_LOGGING=true

And in your configuration code:

database: {
  synchronize: process.env.DB_SYNCHRONIZE,
  logging: process.env.DB_LOGGING,
}

You expect synchronize to be false and logging to be true.
But in reality, both will be truthy because they are non-empty strings!

The Bug in Action
Why is this a problem?

console.log(process.env.DB_SYNCHRONIZE); // "false" (string)
if (process.env.DB_SYNCHRONIZE) {
  console.log("This runs!"); // This will run, even though you set it to "false"
}

This is because in JavaScript:

"false" (string) is truthy
Only "", 0, null, undefined, and false (boolean) are falsy

Boolean("false"); // true
Boolean("true");  // true
Boolean("")       // false

So, if you pass process.env.DB_SYNCHRONIZE directly to a library expecting a boolean, it will act as true!

So "false" (a non-empty string) is truthy, and the if block runs, even though logically you set it to false!

This behavior can lead to critical misconfigurations in production environments. For example, enabling logging, enabling DB synchronization (which drops and recreates tables in some ORMs), or accidentally exposing debug features.

Always convert environment variable strings to booleans explicitly.

The Correct Approach: Explicit Type Conversion

Boolean Conversion Pattern

Always parse environment variables to their expected types before use.

const synchronize = process.env.DB_SYNCHRONIZE === 'true';
const logging = process.env.DB_LOGGING === 'true';

This way:

'true' === 'true' → true
'false' === 'true' → false

You now get predictable, safe boolean values.

Optional Utility Function

For larger projects, it's wise to create a helper:

function toBool(value: string | undefined): boolean {
  return value?.toLowerCase() === 'true';
}

const synchronize = toBool(process.env.DB_SYNCHRONIZE);
const logging = toBool(process.env.DB_LOGGING);

Pro Tip: Use a Config Validation Library

Frameworks like NestJS recommend using a validation layer (e.g., with Joi or zod) to validate and transform config values at startup.

Example using Joi:

const configSchema = Joi.object({
  DB_SYNCHRONIZE: Joi.boolean().default(false),
  DB_LOGGING: Joi.boolean().default(false),
});

Real-Life Pitfall: When "false" Isn’t Really False

This isn’t just theory, I ran into this issue myself while working on a NestJS project using TypeORM.

I had this in my .env:

DB_SYNCHRONIZE=false

And my config looked like:

synchronize: process.env.DB_SYNCHRONIZE,

I assumed this would disable TypeORM’s automatic schema synchronization, since I planned to use migrations instead.

But when I started the app, the tables were still being created. Then, when I tried to generate a migration:

typeorm migration:generate -n AddNewFields

I kept seeing:

No changes in database schema were found - cannot generate a migration.

It was confusing, until I logged the value of process.env.DB_SYNCHRONIZE and saw:

console.log(typeof process.env.DB_SYNCHRONIZE); // string
console.log(process.env.DB_SYNCHRONIZE);        // "false"

That string "false" is truthy, so synchronize: "false" is effectively treated as true in JavaScript. TypeORM was happily syncing the schema on every run, and by the time I tried to run the migration generator, there were no changes left to detect.

Final Thoughts

Misinterpreting environment variables is one of those bugs that can sneak into production unnoticed until something critical misbehaves. In systems where flags control behavior like syncing databases, enabling debug logs, or toggling features, treating "false" as a boolean without conversion can be dangerous.

Always treat process.env values as untrusted strings and explicitly cast them to the types your logic expects. Doing this upfront helps you avoid fragile assumptions and keeps your config layer predictable.

Grasping the different Solana clusters—Devnet, Testnet, and Mainnet—is essential for efficient development.

Tue, 11 Feb 2025 22:12:27 +0000

What Are Solana Clusters, and How to Work with Devnet, Testnet, and Mainnet?

Solana is a high-performance blockchain known for its fast transaction speeds and scalability. One of the core concepts developers need to understand when working with Solana is the cluster. Solana clusters are distinct environments that provide different functionalities for developing, testing, and deploying blockchain applications. In this article, we’ll dive into what Solana clusters are, how they differ from each other, and how developers can leverage Devnet, Testnet, and Mainnet to create robust applications.

What Are Solana Clusters?

A cluster in Solana refers to a network of validators working together to validate transactions and maintain the integrity of the blockchain. There are three main clusters in Solana: Devnet, Testnet, and Mainnet. Each cluster is designed for a specific stage in the development lifecycle.

Key Cluster Types in Solana

Devnet: A testing environment where developers can experiment freely without real consequences.
Testnet: A staging environment designed to simulate real-world conditions, closer to the Mainnet.
Mainnet: The live Solana blockchain where real transactions happen and real-world value is at stake.

Understanding Each Solana Cluster

Devnet: The Developer Playground

Devnet is Solana's sandbox where developers can test their applications, smart contracts, and blockchain interactions without using real tokens or risking any assets.

Purpose: Devnet is used for early-stage development and experimentation. Developers can test smart contracts, deploy decentralized apps (dApps), and learn Solana’s programming environment without fear of financial loss.
Token Supply: Devnet provides free tokens (often called dev tokens) that can be used for testing but hold no real-world value.
Key Features:
- No transaction costs
- Free tokens for testing
- Ideal for quick testing and prototyping

Example Command:
To switch to Devnet, use the Solana CLI:

```bash
solana config set --url devnet
```

Testnet: Simulating Real-World Scenarios

Testnet is a more realistic environment that mimics Mainnet conditions. It’s used for thorough testing, ensuring that your applications can scale and perform under conditions similar to the production environment.

Purpose: Testnet is used to simulate the real world and identify any issues before deploying your code to Mainnet. While it’s not a live environment, Testnet closely mirrors the actual blockchain conditions.
Token Supply: Like Devnet, Testnet uses tokens that are free but do not hold any real value.
Key Features:
- Simulates real-world usage
- Tests how applications will scale in production
- Available for testing interactions with other projects in the Solana ecosystem

Example Command:
Switch to Testnet with the following command:

```bash
solana config set --url testnet
```

Mainnet: Live Blockchain for Real-World Use

The Mainnet is the live blockchain network. This is where real transactions occur, and developers deploy their finalized, production-ready applications. Any transactions on Mainnet involve actual assets with real-world value.

Purpose: Mainnet is used for deploying applications after they have been thoroughly tested on Devnet and Testnet. Once your application is ready for public use, it’s deployed here.
Token Supply: Mainnet uses SOL tokens, which have real monetary value and are used for paying transaction fees and staking.
Key Features:
- Real transactions with actual SOL tokens
- Deploy production-ready applications
- Live usage by end users

Example Command:
Switch to Mainnet with this command:

```bash
solana config set --url mainnet
```

How to Work with Different Solana Clusters Effectively

1. Start with Devnet:

Begin your development on Devnet to experiment with Solana’s features without worrying about costs or real consequences. It’s the best place to develop new smart contracts and dApps.

2. Move to Testnet for Testing:

Once your application is stable on Devnet, deploy it to Testnet. Testnet helps you simulate real-world conditions and identify any performance or scalability issues.

3. Deploy to Mainnet:

After testing your app in Devnet and Testnet, you’re ready for Mainnet. This is the live environment where your users will interact with your application.

Conclusion

In Solana, understanding and utilizing the different clusters—Devnet, Testnet, and Mainnet—is crucial for ensuring the success of your blockchain project. Devnet is where you begin development, Testnet allows you to simulate real-world scenarios, and Mainnet is where your final, production-ready application goes live. By following the right progression and using each environment to its strengths, you can avoid costly mistakes and ensure that your application performs well under real-world conditions.

By following best practices and leveraging Solana’s clusters effectively, developers can streamline their workflow, ensuring smoother transitions from development to production.

Feel free to leave a comment or share your thoughts below – we'd love to hear how you’re using Solana clusters in your projects!

References:

Advanced Strategies: How to Implement the Strategy Pattern in Your NestJS Projects

Wed, 29 Jan 2025 10:14:17 +0000

One of the design patterns that caught my attention the most when learning TypeScript was the Strategy Pattern. Although it's not exclusive to TypeScript, this pattern significantly enriches the code by promoting reusability and decoupling.

What does the pattern consist of?

The Strategy Pattern allows a class to modify the algorithm or behavior it uses during execution. This is achieved by defining a series of algorithms, each encapsulated in its own class and following a common interface. This way, behaviors can be easily interchanged without the need to alter the class that implements them.

A real-life example

Imagine an application that sends notifications to users, with variable notification methods, such as email, SMS, or push notifications. Instead of coding a single sending method, your application can adopt different notification strategies according to the needs of the moment. This is achieved by implementing a common interface for notification strategies, ensuring that your application knows how to send them, regardless of the chosen method. This approach allows you to easily change notification methods without affecting the overall functioning of the application. At first it sounds a bit confusing, so let's better go to an example with code.

Code where the Strategy Pattern is not being used

In the context of the previous example and using NestJS, let's consider the NotificationService. This service is responsible for sending different types of notifications, selecting the appropriate method based on an argument passed to the notify method. The selection of the notification method is done through conditionals, determining whether to send an email, SMS, or push notification depending on the case:

import { Injectable } from '@nestjs/common';

@Injectable()
export class NotificationService {
  async notify(user: User, message: string, method: string): Promise<void> {
    if (method === 'email') {
      console.log(`Sending email to ${user.email}: ${message}`);
      // Logic to send email
    } else if (method === 'sms') {
      console.log(`Sending SMS to ${user.phone}: ${message}`);
      // Logic to send sms
    } else if (method === 'push') {
      console.log(`Sending push notification: ${message}`);
      // Logic ton send push notification
    } else {
      throw new Error('Invalid notification method');
    }
  }
}

The following code fragment demonstrates how we would use the NotificationService to send two notifications, one by email and another by SMS. In this scenario, the notification method is decided at runtime, which shows the flexibility of our service to adapt to different notification requirements:

export class AppService {
  constructor(private readonly notificationService: NotificationService) {}

  async sendNotification() {
    const user = { email: '*Emails are not allowed*', phone: '+1234567890' };
    const message = 'This is a test message.';

    // Choose the method in execution time
    await this.notificationService.notify(user, message, 'email');
    await this.notificationService.notify(user, message, 'sms');
  }
}

This approach reveals several significant disadvantages that deserve attention:

High Coupling: The selection and execution of notification methods are tightly integrated within a single class or function, complicating code management and expansion. This high degree of coupling reduces flexibility and increases maintenance complexity.
Violation of the Open/Closed Principle (OCP): Incorporating a new notification method involves directly modifying the NotificationService class, adding more conditions. This contravenes the OCP principle, according to which software entities should allow their extension without the need to modify their existing content, thus promoting greater scalability and maintainability.
Testing Complexity: Verifying the correct functioning of NotificationService becomes more arduous. Each condition needs to be tested individually to confirm its operability, increasing the effort and complexity of testing.

Refactoring the code

To apply the Strategy pattern in our refactoring of NotificationService, we'll remove the conditionals from the class. Instead, we'll modify the class to accept an object through its constructor. This object must adhere to a specific interface that includes a send method. This method will be responsible for executing the sending logic for the corresponding notification type, thus allowing NotificationService to delegate the responsibility of sending the notification, decoupling the service from the specific implementation details of each sending method. In this way, NotificationService acts merely as a context for sending notifications, without being tied to any particular sending method.

We'll start by defining the common interface that all objects intended to be used as notification strategies must fulfill. This interface ensures that any notification strategy provides an implementation of the send method, which is responsible for executing the specific notification sending logic.

// notification.strategy.interface.ts
export interface NotificationStrategy {
  send(user: User, message: string): Promise<void>;
}

After defining the NotificationStrategy interface, we proceed to integrate it into our NotificationService. This change involves adjusting the NotificationService constructor to accept an object that implements NotificationStrategy. By doing this, we eliminate the need for conditionals within the service, delegating the responsibility of the sending logic to the send method of the injected strategy object. The service's notify function is therefore significantly simplified, limiting itself to invoking send on the provided strategy.

// notification.service.ts
import { Injectable } from '@nestjs/common';
import { NotificationStrategy } from './notification.strategy.interface';

@Injectable()
export class NotificationService {

  constructor(private strategy: NotificationStrategy) {}

  async notify(user: User, message: string): Promise<void> {
    await this.strategy.send(user, message);
  }
}

Finally, to complete our implementation of the strategy pattern, we create different types of notification strategies that NotificationService can use. Specifically, we will develop EmailNotificationStrategy and SmsNotificationStrategy, each with its respective send method. These concrete strategies encapsulate the specific logic for sending notifications via email and SMS, respectively.

// email.notification.strategy.ts
import { NotificationStrategy } from './notification.strategy.interface';
import { Injectable } from '@nestjs/common';

@Injectable()
export class EmailNotificationStrategy implements NotificationStrategy {
  async send(user: User, message: string): Promise<void> {
    console.log(`Sending email to ${user.email}: ${message}`);
    // here the logic to send email
  }
}

// sms.notification.strategy.ts
import { NotificationStrategy } from './notification.strategy.interface';
import { Injectable } from '@nestjs/common';

@Injectable()
export class SmsNotificationStrategy implements NotificationStrategy {
  async send(user: User, message: string): Promise<void> {
    console.log(`Sending SMS to ${user.phone}: ${message}`);
    // here the logic to send SMS
  }
}

To maximize the flexibility of NotificationService and allow it to change its notification strategy at runtime, we introduce a setter method, setStrategy. This method allows updating the notification strategy used by NotificationService, facilitating adaptation to different needs without compromising the current instance of the service.

// notification.service.ts
import { Injectable } from '@nestjs/common';
import { NotificationStrategy } from './notification.strategy.interface';

@Injectable()
export class NotificationService {

  constructor(private strategy: NotificationStrategy) {}

  setStrategy(strategy: NotificationStrategy) {
    this.strategy = strategy;
  }

  async notify(user: User, message: string): Promise<void> {
    await this.strategy.send(user, message);
  }
}

With the implementation of the strategy pattern in our notification system, we have demonstrated how code flexibility and maintainability can be significantly increased. The following example illustrates how AppService can dynamically change the notification strategy from EmailNotificationStrategy to SmsNotificationStrategy, adapting to different notification needs at runtime:

// app.service.ts
import { Injectable } from '@nestjs/common';
import { NotificationService } from './notification.service';
import { EmailNotificationStrategy } from './email.notification.strategy';
import { SmsNotificationStrategy } from './sms.notification.strategy';

@Injectable()
export class AppService {
  constructor(
    private readonly notificationService: NotificationService,
    private readonly emailStrategy: EmailNotificationStrategy,
    private readonly smsStrategy: SmsNotificationStrategy,
  ) {}

  async sendNotification() {
    const user = { email: '*Emails are not allowed*', phone: '+1234567890' };
    const message = 'This is a test message.';

    // Cambiar estrategia según el contexto
    this.notificationService.setStrategy(this.emailStrategy);
    await this.notificationService.notify(user, message);

    // Cambiar a SMS
    this.notificationService.setStrategy(this.smsStrategy);
    await this.notificationService.notify(user, message);
  }
}

This approach not only validates the versatility of the strategy pattern but also underlines its value in creating modular and extensible applications. By separating notification logic into concrete and interchangeable strategies, we facilitate the addition of new notification methods and improve the system's testability. Furthermore, we adhere to the open/closed principle, allowing our system to evolve with minimal changes to existing code.

In summary, the application of the strategy pattern in notification management in TypeScript with NestJS demonstrates how software design principles can be put into practice to build robust, flexible, and maintainable systems. The ability to change strategies at runtime not only enriches our application with operational flexibility but also highlights the importance of forward-thinking software design.

Why NestJS Is The New Gold Standard For Node Backend Development

Tue, 14 Jan 2025 12:39:58 +0000

As a Node.js developer who has tried every Node framework under the sun, here’s why I believe NestJS must be the new gold standard for Node.js backend development. At first, the framework seemed like too much—the learning curve was steep, and I found it hard to understand coming from Express. Why all this complexity? But with time, I came to admire every aspect of this framework.

1. Why OOP is the Best for Backend Development

Object-Oriented Programming (OOP) is not just a paradigm; it's a methodology that addresses the core challenges of backend development. At its heart, OOP allows you to model real-world problems in a way that makes systems easier to design, implement, and maintain. NestJS utilizes OOP through its class-based approach, enabling you to organize logic into cohesive, reusable components.

For instance, consider the concept of services in NestJS. A service class encapsulates business logic, promoting separation of concerns. This encapsulation not only makes your codebase easier to navigate but also simplifies testing. Using decorators like @Injectable(), NestJS takes dependency injection a step further, allowing seamless integration of service dependencies without manual wiring.

Code Example

import { Injectable } from '@nestjs/common';

@Injectable()
export class UserService {
  private users = [];

  createUser(name: string) {
    const user = { id: Date.now(), name };
    this.users.push(user);
    return user;
  }

  getUsers() {
    return this.users;
  }
}

Moreover, inheritance in OOP allows developers to extend and reuse functionality without duplicating code. Polymorphism, another cornerstone of OOP, lets you define common interfaces for varying implementations. In a NestJS context, this could be seen in abstract classes for database repositories, where specific implementations handle details for MongoDB, PostgreSQL, or other data stores.

So as your codebase grows larger, you can maintain a well-structured codebase within every module.

2. NestJS is Future-Proof

NestJS positions itself as a framework built to withstand the test of time. Its adoption of TypeScript ensures that your code is reliable and maintainable.

NestJS also uses decorators extensively, aligning with modern JavaScript standards such as ES6+ and ECMAScript proposals. These decorators, like @Controller(), @Get(), and @Post(), provide declarative syntax that makes code intuitive and reduces boilerplate.

Code Example

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

@Controller('users')
export class UserController {
  @Get()
  findAll() {
    return 'This action returns all users';
  }
}

3. Ideal for Microservices and Enterprise Applications

NestJS shines in environments where modularity and scalability are non-negotiable. For microservices, NestJS provides native support for distributed systems using patterns like message brokers and event-driven communication. The framework includes modules for integration with RabbitMQ, Kafka, and Redis, making it easy to design resilient and decoupled systems.

Code Example

import { Controller } from '@nestjs/common';
import { MessagePattern } from '@nestjs/microservices';

@Controller()
export class AppController {
  @MessagePattern('notifications')
  handleNotification(data: any) {
    console.log('Received notification:', data);
  }
}

For enterprise-grade applications, NestJS's modular architecture allows teams to work on isolated modules without stepping on each other’s toes. Features like DynamicModule allow you to configure modules dynamically, simplifying the management of multi-tenant systems or applications with environment-specific configurations.

4. Built-in Support for Everything

NestJS eliminates the need for cobbling together third-party libraries by offering built-in support for a wide array of features. Need WebSocket support for real-time applications? NestJS provides an out-of-the-box module for that. Building a GraphQL API? NestJS's GraphQL module integrates seamlessly with decorators for schema-first or code-first approaches.

Code Example

Integrating JWT authentication using Passport.js:

import { Injectable } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { Strategy, ExtractJwt } from 'passport-jwt';

@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor() {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      secretOrKey: 'secretKey',
    });
  }

  validate(payload: any) {
    return { userId: payload.sub, username: payload.username };
  }
}

For authentication, the @nestjs/passport library integrates Passport.js directly into your project, providing strategies for OAuth, JWT, and local authentication. NestJS also simplifies database interaction with its @nestjs/typeorm and @nestjs/mongoose modules, providing tight integration with popular ORMs like TypeORM and Mongoose.

This all-inclusive approach reduces decision fatigue and ensures consistency across your application, allowing you to focus on solving business problems rather than configuring your stack.

5. Modular Architecture That Scales

NestJS’s modular system is a game-changer for large-scale applications. By encapsulating features into dedicated modules, it allows developers to maintain clean boundaries between different parts of the application. Each module in NestJS acts as a self-contained unit, bundling together controllers, services, and other components.

Code Example

Creating a user module:

import { Module } from '@nestjs/common';
import { UserController } from './user.controller';
import { UserService } from './user.service';

@Module({
  controllers: [UserController],
  providers: [UserService],
})
export class UserModule {}

The modular design allows you to separate concerns and easily scale your application by adding new modules.

NestJS also supports lazy loading of modules, a crucial feature for microservices or applications with large, complex dependencies. This ensures that your application starts faster and consumes fewer resources.

6. Very Hard to Mess Up in NestJS

NestJS offers guardrails that make it difficult to write bad code. Its opinionated structure enforces best practices, such as the separation of concerns, dependency injection, and modular design. The framework's CLI (@nestjs/cli) helps scaffold components with a consistent folder structure, eliminating the guesswork in organizing your codebase.

Code Example

Using guards for role-based access control:

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';

@Injectable()
export class RolesGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    const user = request.user;
    return user && user.roles.includes('admin');
  }
}

Additionally, NestJS makes full use of TypeScript to catch errors during development, reducing runtime bugs. Features like guards (@CanActivate), interceptors (@Interceptor()), and pipes (@PipeTransform) provide clear patterns for handling concerns like validation, transformation, and access control. This layered approach ensures that even junior developers can contribute effectively while adhering to established conventions.

Even error handling is simplified. By extending the built-in HttpException, you can create custom exceptions with ease, ensuring your APIs remain consistent and predictable. NestJS takes care of the rest, including sending the appropriate HTTP response codes and error messages.

Final Thoughts

NestJS isn’t just another Node.js framework; it’s a paradigm shift in backend development. It’s an ideal choice, offering everything you need to succeed. From my experience, I believe this framework strikes the perfect balance between rapid delivery and long-term maintainability. It represents the ultimate evolution of Node.js backend development, setting a new standard for scalability and efficiency.
For more in-depth insights, check out the book Scalable Application Development with NestJS, available here.