I was happy with Prisma, until I had to integrate with a Supabase Postgres database. After a week fighting the client generation workflow, I gave Drizzle a shot. The integration felt boring in the best way: it was as smooth as working with native Postgres.

Then I plugged it into NestJS, and the experience changed. Supabase felt easy. Nest introduced friction—because the real problem isn’t Drizzle or Nest. It’s the glue code in between.

In this post, we’ll make Drizzle feel Nest-native using providers.

The real problem: your DB client becomes a hidden dependency

Drizzle is minimal by design. NestJS is modular by design. The friction starts the moment you try to make “minimal” fit inside a DI container.

It usually begins innocently: one file creates the client, another reads DATABASE_URL, and a service imports a singleton from some db.ts file in a random folder.

It works. Until it doesn’t.

Soon the database client becomes a hidden dependency. Tests that should be pure unit tests suddenly require wiring. A simple refactor turns into a scavenger hunt for imports.

We’ll get there with a few small building blocks:

• Injection tokens (stable DI keys).

• A Postgres provider (creates and owns the connection).

• A Drizzle provider (builds the typed DB instance).

• A thin DatabaseModule (Nest wiring only).

The plan: a thin DatabaseModule

Here’s the blueprint we’re aiming for. If we do this right, two things become true:

• No service imports a database singleton from a file.

• All database access goes through one DI token.

We’ll get there with one module boundary and two providers, each with a single responsibility:

1. PostgresProvider

   • Input: validated database.url from ConfigService.

   • Output: a single Postgres client wrapper that owns shutdown.

2. DrizzleProvider

   • Input: the Postgres client and app env.

   • Output: the Drizzle DB instance bound to one DI token.

3. DatabaseModule (Nest wiring)

   • Guarantee: modules and services only depend on DI tokens, not on a file path.

That separation keeps Nest concerns (modules, DI, lifecycle) out of your Drizzle initialization logic.

Next, we’ll build it in five steps.

Step 1: Create dedicated injection tokens

Before we write any modules, we need stable injection tokens. These tokens are the only thing services should ever inject.

First, install Drizzle and the postgres driver:

pnpm add drizzle-orm@beta postgres

Now define a symbol token in a single place, and don’t redefine it anywhere else:

// database/database.constants.ts
export const DRIZZLE = Symbol('DRIZZLE');
export const POSTGRES_CLIENT = Symbol('POSTGRES_CLIENT');

With tokens in place, we can implement the Postgres and Drizzle providers.

Step 2: Implement postgres provider

// database/providers/postgres.provider.ts
import { Logger, OnApplicationShutdown } from '@nestjs/common';
import postgres from 'postgres';
import { POSTGRES_CLIENT } from '../constants/database.constants';
import { ConfigService } from '@nestjs/config';
import { DatabaseConfig } from '@app/config/types/database-config.type';

export class PostgresClientProvider implements OnApplicationShutdown {
  private readonly logger = new Logger(PostgresClientProvider.name);

  constructor(public readonly client: postgres.Sql) {}

  async onApplicationShutdown(signal?: string) {
    this.logger.log(`Closing database connection (signal: ${signal})`);
    await this.client.end();
  }
}

export const PostgresProvider = {
  provide: POSTGRES_CLIENT,
  inject: [ConfigService],
  useFactory: (
    configService: ConfigService<{ database: DatabaseConfig }>,
  ): PostgresClientProvider => {
    const { url } = configService.get<DatabaseConfig>('database', {
      infer: true,
    }) as DatabaseConfig;

    const client = postgres(url, { prepare: false });
    return new PostgresClientProvider(client);
  },
};

Step 3: Implement Drizzle provider

// database/providers/drizzle.provider.ts
import { ConfigService } from '@nestjs/config';
import { drizzle } from 'drizzle-orm/postgres-js';

import { DRIZZLE, POSTGRES_CLIENT } from '../constants/database.constants';
import { DrizzleDB } from '../types/database.type';
import { PostgresClientProvider } from './postgres.provider';
import { AppConfig } from '@app/config/types/app-config.types';

import * as schema from '../schema';

export const DrizzleProvider = {
  provide: DRIZZLE,
  inject: [POSTGRES_CLIENT, ConfigService],
  useFactory: (
    postgresProvider: PostgresClientProvider,
    configService: ConfigService<{ app: AppConfig }>,
  ): DrizzleDB => {
    const { nodeEnv } = configService.get<AppConfig>('app', {
      infer: true,
    }) as AppConfig;

    return drizzle({
      client: postgresProvider.client,
      schema,
      logger: nodeEnv === 'development',
    });
  },
};

In the next steps we’ll define a single DrizzleDB type (derived from your schema) and reuse it everywhere.

Step 4: Wire it up in DatabaseModule (Nest-only concerns)

This is where Nest becomes useful. We register both providers and export one token that the rest of the app can inject.

A few rules to keep it boring:

• The module wires providers that read config.

• The module creates the Drizzle instance once.

• Services only inject DRIZZLE.

// database/database.module.ts
import { Global, Module } from '@nestjs/common';
import { DRIZZLE } from './constants/database.constants';
import { DrizzleProvider } from './providers/drizzle.provider';
import { PostgresProvider } from './providers/postgres.provider';

@Global()
@Module({
  providers: [PostgresProvider, DrizzleProvider],
  exports: [DRIZZLE],
})
export class DatabaseModule {}

At this point, your database client is no longer a hidden dependency. It’s a first-class provider with a stable token.

Next, we’ll inject it from any module without importing “random files”.

Step 5: Inject Drizzle anywhere (no imports from “random files”)

Now the payoff: modules import a module, and services inject a token.

First, define a single strongly typed DB type derived from your schema:

// database/types/database.type.ts
import { PostgresJsDatabase } from 'drizzle-orm/postgres-js';
import * as schema from '../schema';

export type DrizzleDB = PostgresJsDatabase<typeof schema>;

Then use that type anywhere you inject DRIZZLE:

// any.module.ts
import { Module } from '@nestjs/common';
import { DatabaseModule } from '@database/database.module';

@Module({
  imports: [DatabaseModule],
})
export class AnyModule {}

// example.service.ts
import { Inject, Injectable } from '@nestjs/common';
import { DRIZZLE } from '@database/database.constants';
import { DrizzleDB } from '@database/types/database.type';

@Injectable()
export class ExampleService {
  constructor(@Inject(DRIZZLE) private readonly db: DrizzleDB) {}
}

Because the provider was created with schema, DrizzleDB stays in sync with your tables and queries.

Takeaway: keep database initialization boring and isolated

If you treat your database client as infrastructure and give it a dedicated module boundary, three things happen:

• Config stays centralized (and validated).

• Services stay clean (they inject a token, not a file import).

• Future work gets easier (schema, migrations, and tests build on a stable foundation).

The goal is not cleverness. The goal is a database client that feels boring to use.

🔗 Code so far: https://github.com/RubenOAlvarado/finance-api/tree/v0.3.0

If you read process.env directly everywhere, the codebase becomes fragile fast:

• One typo silently breaks your connection.

• One missing variable makes the app crash at runtime.

• You end up debugging configuration instead of shipping.

What if there's a better, cleaner, and more professional way to handle this mess? In this post, we'll build a small, type-safe, validated Config Module that will serve as the foundation for the rest of this series.

Why a custom Config Module?

Nest already provides @nestjs/config, and it’s great. The issue is that most tutorials stop at “install it and call it a day”.

For a production-grade API, we want a little more:

• One place to load and validate environment variables

• Clear namespaces like app, and db (for now)

• Type inference so configuration access is safe and discoverable

• Fail fast validations (before the app starts)

This is especially important in our Personal Finance API because our next steps depend on stable configuration:

• Drizzle needs a valid Postgres connection string

• Local and production environments must behave predictably

Creating the module

We’ll create a module that is global and acts as the single source of truth for configuration.

Generate a config module (choose your own path):

nest g mo config

Now set up the module using Nest’s ConfigModule, but keep it wrapped behind your own module.

Here’s the baseline:

// config/config.module.ts
import { Global, Module } from '@nestjs/common';
import { ConfigModule as NestConfigModule } from '@nestjs/config';

@Global()
@Module({
  imports: [
    NestConfigModule.forRoot({
      isGlobal: true,
      cache: true,
      envFilePath: [`.env.${process.env.NODE_ENV}`, '.env'],
    }),
  ],
  exports: [NestConfigModule],
})
export class ConfigModule {}

This already gives us:

• Global config (no need to import it everywhere)

• Environment-specific .env loading

• Caching for performance

Defining configuration namespaces (app, db)

Instead of scattering variable names throughout the codebase, we’ll create configuration “namespaces”. This keeps things organized and makes future posts easier to follow.

Example: app config. You can do the same for db.

// config/configurations/app.config.ts
import { registerAs } from '@nestjs/config';

export default registerAs(
  'app',
  (): AppConfig => ({
    port: parseInt(process.env.PORT || '3000', 10),
    nodeEnv: (process.env.NODE_ENV || 'development') as AppConfig['nodeEnv'],
  }),
);

// config/types/app-config.types.ts
export type AppConfig = {
  port: number;
  nodeEnv: 'development' | 'production' | 'test' | 'staging';
};

For this series, the important part is that by the time we connect Drizzle, we can read something like:

• db.connectionString

Validating environment variables with Joi

Type safety is nice, but validation is what prevents bad configuration from reaching production. We’ll use Joi to validate env variables before the app boots.

Install Joi:

pnpm i joi

Create a validation schema:

// config/validations/env.validation.ts
import * as Joi from 'joi';

export const envValidationSchema = Joi.object({
  PORT: Joi.number().default(3000),
  NODE_ENV: Joi.string()
    .valid('development', 'production', 'test', 'staging')
    .default('development'),
});

Now wire everything together:

// config/config.module.ts
import { Global, Module } from '@nestjs/common';
import { ConfigModule as NestConfigModule } from '@nestjs/config';

import appConfig from './configurations/app.config';
import { envValidationSchema } from './validations/env.validation';

@Global()
@Module({
  imports: [
    NestConfigModule.forRoot({
      isGlobal: true,
      cache: true,
      envFilePath: [`.env.${process.env.NODE_ENV}`, '.env'],
      load: [appConfig],
      validationSchema: envValidationSchema,
    }),
  ],
  exports: [NestConfigModule],
})
export class ConfigModule {}

Testing it quickly

Create a .env file with the variables you defined and boot the app. If any variable is missing or invalid, Nest will fail fast and tell you exactly what's wrong. That's the whole point.

If you see Nest application successfully started in the console, you nailed it.

Wrapping Up

At this point, you’ve built a configuration layer that is:

• Centralized (one module)

• Type-safe (structured config objects)

• Validated (Joi schema)

• Ready for the next steps (Drizzle + Supabase integration)

In the next post, we'll use this module to initialize Drizzle with the Supabase Postgres connection string and start defining our schema. But to be ready, we'll need the database config—so that's your homework. See you in the next one!

🔗 Code: https://github.com/RubenOAlvarado/finance-api/tree/v0.2.0

In the vibe coding era, tools like Supabase and Firebase are winning because they solve this exact problem. They let you ship fast without wrestling with infrastructure.

But here's where it gets interesting: when you combine Supabase with your own NestJS backend, you're not sacrificing control for speed—you get both. Full control over your database logic, custom business rules, your own auth flow, and the ability to scale exactly how you want. No vendor lock-in, no "this feature isn't supported" roadblocks.

In this post, I'll show you how to set up Supabase as the foundation for a NestJS API that gives you the best of both worlds.

Understanding Postgres + Auth

Here's what makes Supabase special: you're not just getting a database and auth as separate tools. You're getting a database that knows who your users are.

Postgres Database

Supabase gives you a production-grade PostgreSQL database with three ways to access it:

• Direct connection: Connect with any Postgres client using the connection string (this is what we'll use with Drizzle)

• REST API: PostgREST automatically generates a RESTful API for your tables—no backend needed

• Realtime subscriptions: Listen to database changes in real-time (think collaborative docs, live dashboards)

Why does this matter? Flexibility. Start with direct connection for your NestJS API, but if you need to prototype a quick feature, you can hit the REST API directly from your frontend. Need live updates? Turn on realtime subscriptions. Same database, multiple access patterns.

Authentication System

Supabase Auth handles everything you'd expect:

• Email/password and magic links

• OAuth providers (Google, GitHub, etc.)

• JWT token generation and validation

• User management and sessions

Imagine you have a transactions table. Normally, you'd write backend logic to ensure users can only see their own transactions. With RLS, you write that rule once at the database level:

But here's where it gets powerful: Row Level Security (RLS).

CREATE POLICY "Users can only see their own transactions"
ON transactions FOR SELECT
USING (auth.uid() = user_id);

Now your database automatically enforces this. Whether you access it via your NestJS API, the REST API, or directly—users can only see their own data. No leaked queries, no forgotten permission checks in your code.

And because Supabase stores auth data in the auth schema of the same database, you can join auth tables in your queries, extend user profiles, or add custom claims—all in Postgres.

Creating Your Supabase Project

Alright, let's get your hands dirty. Head over to supabase.com and spin up a new project. The process takes about 5 minutes total, and here's what you need to do:

1. Sign in and start a new project

• Sign in to your Supabase account (or create one if you haven't)

• Click "New Project"

• Choose your organization or create a new one

2. Configure your project

• Name your project (e.g., "Finance-API")

• Set a database password: Click the "Generate a password" button. This is your Postgres database password, so save it somewhere safe (password manager, .env file, wherever you keep secrets). You'll need it later.

• Select your region: Choose the one closest to your users. This affects latency—a project in us-east-1 will be noticeably slower for users in Europe or Asia. If you're not sure, pick the region closest to you for now.

3. Wait for provisioning

Click "Create new project" and wait 2-3 minutes. Supabase is spinning up your Postgres instance, setting up auth, and configuring everything behind the scenes.

Once it's ready, you'll see your project dashboard with all your connection details, API keys, and database info. Before we connect anything, though, we need to understand how Supabase's API keys work—because using the wrong one can create security issues.

A Quick Note on API Keys

Before we move forward, you might notice that Supabase provides two API keys in your dashboard: a publishable key and a secret key. Here's the thing: we won't be using either of them for this project.

We're connecting to Supabase using the direct Postgres connection string with Drizzle. This gives us full control over our database queries and lets us use Drizzle's type-safe ORM instead of Supabase's client libraries.

So why mention the API keys at all? Because they're still useful to understand:

Publishable Key (anon key)

• Safe to expose in client-side code (React, Vue, mobile apps)

• Respects Row Level Security policies

• Perfect if you want your frontend to talk directly to Supabase

Secret Key (service_role key)

• Bypasses ALL security policies—treats you as admin

• Backend-only, never expose this

• Useful for migrations, admin scripts, or background jobs

Alright, with that cleared up, let's talk about what we actually covered in this post.

Wrapping Up

At this point, you've got a production-ready Supabase project with Postgres and Auth configured. Here's what you now understand:

• Why Supabase + NestJS is powerful: You get the speed of a BaaS with the control of your own backend

• How Postgres and Auth integrate: Row Level Security lets your database enforce permissions automatically, eliminating entire classes of security bugs

• Your connection options: Direct connection (what we'll use), REST API, or Realtime—each serving different use cases

• The foundation is ready: Your Supabase project is live and waiting for a connection

The next step? We need to connect our NestJS app to this Supabase instance using Drizzle. That means setting up a config module to handle our database credentials securely.

See you there! 🚀

What We're Building

We're building a Personal Finance API from scratch. This series will guide you through creating a production-ready REST API to manage income, expenses,and accounts types—everything you need to track your money with confidence.

Each post is a 3–4 minute read focusing on one specific aspect of the application. By the end, you'll have a fully functional API that you can extend or integrate with any frontend.

Architecture Overview

Our API will follow a modular, scalable architecture:

• NestJS as our backend framework (TypeScript, dependency injection, decorators)

• Supabase for PostgreSQL database hosting and authentication

• Drizzle ORM for type-safe database queries and migrations

• REST architecture with clear resource modeling

The application will be organized into feature modules:

• auth: User authentication and authorization

• accounts: account types: cash, debit, and credit

• transactions: Income and expense tracking

• categories: Transaction categorization

We'll use semantic versioning throughout this series. For example, by the end of this post we'll have v0.1.0. Minor changes like adding a constraint will bump to v0.1.1, and so on until we reach v1.0.0—a production-ready API.

This approach helps you break down large problems into manageable steps, making planning and execution much easier.

Setting Up the Project

Let's bootstrap our NestJS application:

# Install the Nest CLI globally
npm i -g @nestjs/cli

# Create a new project
nest new finance-api

# Choose your preferred package manager (npm, yarn, or pnpm)

The CLI will generate a clean project structure with:

• TypeScript configuration

• Basic module, controller, and service

• Testing setup with Jest

• ESLint and Prettier configurations

Project Structure

After setup, we'll organize our code following NestJS best practices:

src/
├── auth/             # Authentication module
├── accounts/         # Accounts module
├── transactions/     # Transactions module
├── categories/       # Categories module
├── common/           # Shared utilities, decorators, guards
│   ├── decorators/
│   ├── guards/
│   ├── interceptors/
│   └── filters/
├── config/           # Configuration module
├── database/         # Database connection and Drizzle setup
│   ├── migrations/
│   └── schema/
│   └── seeds/
├── app.module.ts
└── main.ts

Technical Decisions

Why Supabase?

Supabase provides:

• Managed PostgreSQL database with automatic backups

• Built-in authentication (email/password, OAuth, magic links)

• Real-time subscriptions (optional for future features)

• Auto-generated REST API (though we'll build our own)

• Free tier perfect for development

Why Drizzle ORM?

Drizzle offers:

• Full TypeScript type safety without decorators

• Lightweight and performant (faster than TypeORM)

• SQL-like syntax that's easy to learn

• Migration system that's version-control friendly

• Perfect integration with NestJS's modular architecture

Alternative considered: Prisma (great, but Drizzle gives us more control over queries and has better performance for complex relations).

We'll discuss each of these tools in detail in their own posts. For now, this is a high-level overview of the project we're building. At the end, you can use it as a guide and choose your preferred option.

Final thoughts

Here's what you now have:

✅ A clean NestJS project ready for development

✅ Understanding of the overall architecture

✅ A clear folder structure to keep code organized

✅ Knowledge of why we chose Supabase and Drizzle

I know this post is simple, but we're taking small steps to build gradually rather than rushing ahead. I hope this series serves as a guide for your future projects and gives you a framework for accomplishing those big goals.

Review the code so far at the link below:

🔗 Code: [GitHub repository]

One of the most frequently used solutions is recursion—a core concept in computer science. Whether you're learning computer science, preparing for your next interview, or simply reinforcing old concepts, join me in writing a Fibonacci sequence using recursion with Go.

What is recursion?

Recursion means breaking a problem into smaller subproblems. Sometimes you'll add or remove something f(n), or you'll need to adjust the solution f(n - 1). In some cases, you might solve the problem for half of the dataset.

In the Fibonacci sequence, the function calls itself with smaller inputs. Each recursive call works toward the base case.

Problem Statement

Given n calculate the nth Fibonacci number.

The Fibonacci sequence is a series of numbers where each number is the sum of the two preceding ones, starting with 0 and 1. The sequence begins as follows: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, ...

Breaking it down:

• Input: an integer where the series will stop.

• Output: the sequence from 0 to n.

Now that we've identified the input, output, and approach, it's time to implement it.

Algorithm

First, since the function calls itself, I need to prevent infinite loops. To do this, I define a base case—a condition that tells the function when to stop.

if n <= 1 {
    return n
}

Every recursive function consists of two parts: the base case (when to stop) and the recursive case (when to call itself). I've already defined the base case. Now it's time to declare the recursive case. For Fibonacci, I need to call the function twice with smaller inputs—specifically n - 1 and n - 2.

return fibonacci(n-1) + fibonacci(n-2)

You might be asking: "Why does it call itself twice?" Good question. Each number is the sum of the two preceding ones.

The Fibonacci function is mathematically defined as: F(n) = F(n-1) + F(n-2) for n > 1. 1

So to compute F(4), you need:

• F(3) (which needs F(2) and F(1))

• F(2) (which needs F(1) and F(0))

Easy, right? And there you have it—you've solved the Fibonacci sequence using recursion. But I'm afraid to say it's the worst solution.

Visual example

Why learn something that's a bad solution? Well, because it's the core concept for complex solutions like dynamic programming or memoization. If you're a React programmer, you've used memoization plenty of times with the useMemo or useCallback hooks. So that's why you need to learn recursion first.

An example will make this clearer. Let's find the Fibonacci sequence for the number 4.

Let's trace through the recursion step by step:

1. F(4) calls F(3) and F(2)

2. F(3) calls F(2) and F(1)

   • F(2) calls F(1) and F(0)

   • F(1) returns 1 (base case)

   • F(0) returns 0 (base case)

   • So F(2) = 1 + 0 = 1

   • F(1) returns 1 (base case)

   • So F(3) = 1 + 1 = 2

3. F(2) calls F(1) and F(0)

   • F(1) returns 1 (base case)

   • F(0) returns 0 (base case)

   • So F(2) = 1 + 0 = 1

4. Final result: F(4) = 2 + 1 = 3

Notice how F(2) is calculated twice and F(1) is calculated three times. This redundancy is why the naive recursive solution is inefficient—it has exponential time complexity of O(2ⁿ). For larger values of n, the same calculations are repeated thousands or even millions of times.

This is exactly why we need optimization techniques like memoization or dynamic programming, which store previously calculated values to avoid redundant work.

Final Thougths

Recursion is best used when it makes the solution clearer. When you call a function from another function, the calling function pauses in a partially completed state. Imagine what this does to memory.

Despite its drawbacks, recursion powers many important algorithms, so it's worth understanding how it works.

If you want to dive deeper or practice, try other exercises like factorial or the Tower of Hanoi. Happy coding, and I'll see you in the next one!

In Go, this problem becomes a great opportunity: the language gives you clean syntax and multiple assignment, so you can write an in-place solution that is both efficient and easy to read.

In this post I’ll walk you through my approach to reversing a slice in place using start and end indices, without any extra memory. Think of it as a pattern you can reuse in many other algorithms—not just a one-off interview trick.

Let’s start by formalizing the problem we’re trying to solve.

Problem Statement

Given an array of integers, a start index, and an end index, write a function that reverses the integers in-place without using extra memory.

More formally:

• Input: an array of integers, an integer for the starting index and another integer for the ending index.

• Output: the same array modified in place, with the elements start and end reversed.

Now that we know exactly what goes in and what should come out, we can focus on defining a simple, safe algorithm to get there.

Algorithm

Before touching the array, I need to make sure the indices are safe. If start or end are out of range, or if start is not strictly less than end, there is nothing to do and I can just return the original array.

if start >= end || start < 0 || end >= len(arr) {
    return arr
}

Once the input is valid, the idea is simple: swap elements from the edges of the range towards the center. I only need to visit half of the elements between start and end. For each position i from the left, I swap it with its counterpart from the right:

• left index: start + i

• right index: end - i

That is why the loop runs up to half the length of the range:

for i := 0; i < (end-start+1)/2; i++ {}

The expression (end - start + 1) is the number of elements in the range [start, end]. Dividing it by 2 gives the number of swaps we need to perform.

To see this in action, take the array [1, 2, 3] and reverse the whole range:

• First iteration (i = 0): swap arr[0] and arr[2] → [3, 2, 1].

• There is no second iteration, because we already reached the middle.

Thanks to Go's multiple assignment, the swap stays readable and we keep the space complexity at O(1). When the loop finishes, the original slice has been modified in place, using the same underlying memory.

arr[start+i], arr[end-i] = arr[end-i], arr[start+i]

When the loop ends, my original array has been modified while keeping the same memory range. To ensure this is true, I’m going to make a simple test.

Being my Own QA

Now that the algorithm is in place, I want to prove that it actually does what it says. I'll start with a simple test case and let Go’s testing package be my QA.

In this example, I reverse the entire array [1, 2, 3, 4] by using start = 0 and end = 3:

func TestReverseArray(t *testing.T) {
    arr := []int{1, 2, 3, 4}
    start := 0
    end := 3

    result := ReverseInPlace(arr, start, end)

    expected := []int{4, 3, 2, 1}

    for i := range expected {
        if result[i] != expected[i] {
            t.Errorf("Expected %v, but got %v", expected[i], result[i])
            break
        }
    }

    if &arr[0] != &result[0] {
        t.Error("Expected array to be modified in place, but got a different array reference")
    }
}

This test checks two things:

• The values are correct: [1, 2, 3, 4] becomes [4, 3, 2, 1].

• The memory is the same: comparing &arr[0] and &result[0] ensures that we did not create a new array behind the scenes, we modified the original one in place.

You can add more test cases to cover edge scenarios, for example:

• A subrange in the middle of the array.

• A range of length 1.

• Invalid ranges, such as start > end or end out of bounds, where the function should simply return the original array.

Final Thoughts

Reversing an array in place isn’t just a classic interview question. It is a nice way to practice things you use all the time: indexes, boundaries, and how memory works in Go.

The goal is not to memorize this exact solution, but to keep the pattern: move from the ends toward the middle, touch only half of the range, and stay at O(1) space. From there you can play with variations like subranges, rotations, or different data types.

If you want more exercises like this, check out my algorithms repo: github.com/RubenOAlvarado/algorithms

Pick a problem, try your own solution, then compare it with mine. That kind of practice is what really adds up over time.

Happy coding and I’ll see you in the next one!

After several years working with NestJS, I've collected capabilities I want to share. One is creating a custom config module where you can declare, load, and validate environment variables. After reading this post, you'll build more robust, production-ready applications.

Setting up the project

First, I'll install the Nest CLI globally to access the framework's capabilities. I like using the CLI to boost my productivity when working with Nest.

npm install -g @nestjs/cli

With the CLI installed, I can create a new Nest project using the command nest new. I prefer working with pnpm as my package manager, but you can choose whichever works best for you. I'll name my project config-module-example.

nest new config-module-example

Now I'll install the config service from Nest.

pnpm i @nestjs/config

With the project set up, it's time to start building. I'll begin by creating a new module.

Creating the Module

As a best practice, I create a common folder for configurations, database schemas, definitions, validations, and other non-business logic utilities. Let's start there.

Using the CLI, I'll run this command:

nest g mo common/config

This command creates a config module inside the common folder and a config.module.ts file where I'll define my custom configuration module—don't confuse it with the built-in one.

To make my module global, I'll add the @Global decorator so I can use it throughout the entire application. I also need to import the @nestjs/config package but rename it as NestConfigModule to avoid confusion with my own config module.

import { ConfigModule as NestConfigModule } from '@nestjs/config';

Now I'll configure how the module behaves. Since I'm working with .env files, I need to tell the Nest container where to find them and enable caching. I also need to export this module so it can be used as a provider.

With these configurations in place, my module looks like this:

@Global()
@Module({
  imports: [
    NestConfigModule.forRoot({
      isGlobal: true,
      envFilePath: [
        `.env${process.env.NODE_ENV ? `.${process.env.NODE_ENV}` : ''}`,
      ],
      cache: true,
    }),
  ],
  exports: [NestConfigModule],
})
export class ConfigModule {}

Pay attention to the envFilePath property—this tells the module to use the environment-specific .env file if NODE_ENV is present, or the default one if not. With my config module defined, I'll now define the types for working.

Defining Configuration Types

For this example, I'll declare some basic environment variables. You can extend them as needed.

Under the common folder, I'll create a types folder with a file called app.types.ts. Here I'll define the AppConfig type:

export type AppConfig = {
  port: number;
  nodeEnv: 'development' | 'production' | 'test' | 'staging';
};

With the types defined, I can now set up the application's configuration.

Working with Configurations

With the types defined, I'll now create the configuration file. Inside the config folder, I'll create a configurations folder and add a file called app.config.ts. I need to import the registerAs function from @nestjs/config. This function registers a configuration namespace that I can reference later. Here's how it looks:

export default registerAs(
  'app',
  (): AppConfig => ({
    port: parseInt(process.env.PORT || '3000', 10),
    nodeEnv: (process.env.NODE_ENV || 'development') as
      | 'development'
      | 'production'
      | 'test'
      | 'staging',
  }),
);

I'm using registerAs with two arguments: the namespace token 'app' and a factory function that returns the AppConfig object. This maps my environment variables to a type-safe configuration. But what happens if someone loads a corrupt .env file with invalid variables? To prevent this, the next step is to define and validate a schema.

Validating Schemas with Joi

With the configuration in place, I need to ensure the .env file doesn't have corrupt or invalid variables. To do this, I'll create a schema with validations using Joi.

First, I'll install Joi:

pnpm i joi

Next, I'll create a validations folder under my config module to hold my schemas. Using Joi, I'll define the validation schema:

export const appValidationSchema = Joi.object({
  PORT: Joi.number().default(3000),
  NODE_ENV: Joi.string()
    .valid('development', 'production', 'test')
    .default('development'),
});

The schema validates that PORT is a number and NODE_ENV is one of the allowed environment values, with sensible defaults for both. With all the pieces ready, it's time to wire everything together and make this configuration work.

Wiring It All Together

Now I'll connect all the pieces. I'll return to the config.module.ts file and add the configuration loader and validation schema:

@Global()
@Module({
  imports: [
    NestConfigModule.forRoot({
      isGlobal: true,
      load: [appConfig],
      validationSchema: appValidationSchema,
      envFilePath: [
        `.env${process.env.NODE_ENV ? `.${process.env.NODE_ENV}` : ''}`,
      ],
      cache: true,
    }),
  ],
  exports: [NestConfigModule],
})
export class ConfigModule {}

The load property tells the module which configuration files to load, and validationSchema ensures the environment variables are valid before the app starts. With the module complete, let's test that it works.

Testing the Configuration works

To test the configuration, I'll log the port and environment at startup. In my main.ts file, I'll inject the ConfigService and retrieve the configuration values:

const configService = app.get(ConfigService);

const port = configService.get<number>('app.port', { infer: true }) as number;

const nodeEnv = configService.get<string>('app.nodeEnv', { infer: true }) as string;

if (nodeEnv === 'development') {

    console.log(`Application is running in ${nodeEnv} mode`);

    console.log(`Listening on port ${port}`);

}

Before running the application, I'll create a .env file with the environment variables:

PORT=3000

NODE_ENV=development

Now I'll run pnpm run start:dev. If everything is configured correctly, the application will start and display the development logs.

Final Thoughts

Creating a custom configuration module in NestJS is essential for building robust, maintainable applications. In this article, I've shown you how to structure environment variables, validate them with Joi schemas, and organize them in a way that scales with your project.

This setup prevents the configuration mistakes I made early in my NestJS journey. Type-safe configurations with validation catch errors before they reach production, making your applications more reliable and easier to maintain.

You can find the complete code in my Github repository: https://github.com/RubenOAlvarado/config-module-example

Happy coding—see you in the next one!

Today, I'm going to show you my battle-tested algorithm for chunking arrays in Go—one that handles all those edge cases cleanly.

Problem Statement

Write a function that takes an array and a chunk size as input. The function should return a new array where the original array is split into chunk of the specific size.

I like to start by breaking down the problem into three parts: input, process, and expected output. This way, I can identify the steps to go from A (the input) to B (the output).

Input: The array to be split and an integer that indicates the chunk size.

Output: An array of arrays.

With this identified, I can start with my solution. The expected array is formed by smaller arrays, where each one is a chunk from the original array with the specified size. Now, I can plan an algorithm to obtain these chunks.

Algorithm to Solve it

The first step for splitting the array into chunks is validating the size. My first code block is an if statement that checks whether the input is less than or equal to zero. If it is, I return nil since the array can't be split into chunks of zero length.

if size <= 0 {
        return nil
}

Next, I initialize a new array to hold the chunks.

var chunks [][]int

Then, I loop through the original array in increments of the chunk size. I start at index zero, and in each iteration, I increment my index by the chunk size value. For example, if the chunk size is 2, in the first iteration i = 0, in the second i = 2, in the third i = 4, and so on.

for i := 0; i < len(arr); i += size {}

For each iteration, I need to determine the end position of the chunk. My i variable marks where the chunk starts, so I use the min built-in function to find where it should end.

end := min(i+size, len(arr))

Finally, I append the chunks array with the portion of the original array, using a slice with my two variables i and end.

chunks = append(chunks, arr[i:end])

Once I've looped through the entire original array, I have all the chunks stored in the new array. I get my expected output—now I just need to return it.

return chunks

Final Thoughts

As you can see, my approach is simple but effective. I like to keep things simple—I prefer understanding the problem over chasing fancy solutions.

If you want to see the code for this and other algorithms, check out my GitHub repository: https://github.com/RubenOAlvarado/algorithms

Remember, this is my algorithm—you can define your own. Use this as a guide if you're stuck or have questions about the topic. After all, the best artists steal, and coding is an art.

What other chunking strategies have you used in production? Or better yet—try extending this to handle 2D arrays and share your solution on GitHub. Keep coding, and I'll see you in the next one.

In this tutorial, I'll teach you how to build your own custom decorator to prevent these scenarios.

Setting Up the Project

Let's start with a base project. I have a template repository with a RESTful API using NestJS as the framework, PostgreSQL as the database, and Drizzle as the ORM—but you can create your own.

This is the repo I'm using: https://github.com/RubenOAlvarado/nestjs-drizzle-template This also includes Swagger integration and a Docker Compose file for your own use.

With the repository set up and the API running, the next natural step is to model our data.

UserSchema

Let's start with the simplest model in our application. For the user, we have these properties: id, name, and email. You can skip the timestamps if you want—I like to include them as good practice. And since we're working with Postgres, we need to import from the pg-core package from Drizzle.

export const users = pgTable('users', {
  id: integer('id').primaryKey().generatedByDefaultAsIdentity(),
  name: text('name').notNull(),
  email: text('email').notNull().unique(),
  createdAt: timestamp('created_at').defaultNow().notNull(),
  updatedAt: timestamp('updated_at').defaultNow().notNull(),
});

export type User = typeof users.$inferSelect;
export type NewUser = typeof users.$inferInsert;

As you can see, we're defining the ID as identity. We're also creating types from the schema—this is a bonus we don't need for this tutorial, but it's a helpful tip for your future projects. This schema defines the pattern we'll follow throughout this application.

TaskSchema

Now let's model our tasks, which are related to users through a foreign key to enable compound queries.

A task has these properties: id, title, and description. The user field references the users schema using the ID field with on delete cascade.

export const tasks = pgTable('tasks', {
  id: integer('id').primaryKey().generatedByDefaultAsIdentity(),
  title: text('title').notNull(),
  description: text('description').notNull(),
  userId: integer('user_id')
    .notNull()
    .references(() => users.id, { onDelete: 'cascade' }),
  createdAt: timestamp('created_at').defaultNow().notNull(),
  updatedAt: timestamp('updated_at').defaultNow().notNull(),
});

export type Task = typeof tasks.$inferSelect;
export type NewTask = typeof tasks.$inferInsert;

With both schemas defined, we can now declare relations to unlock readable queries with Drizzle.

SQL-like or Not SQL-like?

There's ongoing debate about whether SQL-like syntax or ORM-style syntax is better. Drizzle offers both. I prefer the SQL-like functionality, but for this tutorial we're using the Queries API to keep things simple. To make this work, we need to define relations: a task has one user, and a user has many tasks.

export const tasksRelations = relations(tasks, ({ one }) => ({
  user: one(users, {
    fields: [tasks.userId],
    references: [users.id],
    relationName: 'user_tasks',
  }),
}));

export const userRelations = relations(users, ({ many }) => ({
  tasks: many(tasks, { relationName: 'user_tasks' }),
}));

With the schemas and relations defined, we can now work on our endpoints. But first, generate and run your migration—this will connect your database to your application. If you're using my template, you're all set. If not, read the Drizzle documentation to fully set up your database connection and migrations.

Working with Controllers

Since tasks belong to users, our API design will follow this structure. This creates a semantic hierarchy showing that tasks belong to the users resource. If you want to dive deeper into RESTful API design, read this excellent article from Microsoft: https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design. And for God's sake, never return a 200 status code with an empty array or an error message.

If you've been working with NestJS, you already know how to generate resources with the CLI. Let's generate resources for our two modules: users and tasks.

nest g res users
nest g res tasks

For the transport layer, select REST API and enter y when prompted to generate CRUD endpoints.

With both modules created, open the tasks.controller.ts file and update the controller definition from tasks to users/:userId/tasks.

@Controller('users/:userId/tasks')
export class TasksController {}

Next, define a GET method to fetch all tasks belonging to a specific user.

@Get()
findAll(@Param() { userId }: UserIdParamDto) {
    return this.tasksService.findAllByUserId(userId);
}

Since our route depends on the userId, we need to validate this path parameter to prevent errors before they reach the service layer.

Creating the Param DTO

We'll define a param DTO that transforms and validates the userId from the path. This DTO has these key elements: the ApiProperty decorator tells Swagger how to present this attribute and its metadata. The IsNotEmpty decorator marks it as required. The Type decorator from class-transformer converts the ID to a number—all URL params and query fields come through as strings.

Once transformed, we use the IsInt and Min decorators together to ensure the ID is an integer greater than or equal to 1. Since we don't have an ID 0 (or at least we shouldn't), this validation keeps our data clean. Our DTO definition looks like this:

export class UserIdParamDto {
  @ApiProperty({
    description: 'Unique identifier of the user',
    example: 1,
    type: Number,
  })
  @IsNotEmpty({ message: 'User ID must be provided' })
  @Type(() => Number)
  @Transform(({ value }) => parseInt(String(value), 10))
  @IsInt({ message: 'User ID must be a valid number' })
  @Min(1, { message: 'User ID must be a positive number' })
  userId: number;
}

These checks cover type and range, but they don’t verify existence in the database. Let’s add an async constraint.

Creating the findOne Method

Open your UsersService file and leave the class empty:

@Injectable()
export class UsersService {}

If you're using my template, you have an injectable DrizzleClient; if not, you'll figure it out later. In the constructor, inject the DrizzleClient.

constructor(@Inject(DRIZZLE) private readonly drizzle: DrizzleClient) {}

Now, define the findOne method. This will use the Queries API from Drizzle, returning the first occurrence where the retrieved ID equals the user ID. To verify this equality, import the eq utility from the Drizzle package. This leaves our method looking like this:

findOne(id: number) {
    return this.drizzle.query.users.findFirst({ where: eq(users.id, id) });
}

With the TasksService, follow the same approach—but this time, return all tasks found and include the user.

@Injectable()
export class TasksService {
  constructor(@Inject(DRIZZLE) private readonly drizzle: DrizzleClient) {}

  findAllByUserId(userId: number) {
    return this.drizzle.query.tasks.findMany({
      where: eq(tasks.userId, userId),
      with: { user: true },
    });
  }
}

Make sure to export both services in their module classes. With our service layer defined, we can create our constraint that injects it.

Creating our Constraint

We'll create an async constraint that uses the UsersService to verify whether the user exists.

Create a class called UserExistConstraint that implements the ValidatorConstraintInterface from class-validator. Use the ValidatorConstraint decorator to mark this as an async validator—we're connecting to the database. You can also optionally provide a name for the constraint. Make it Injectable so Nest recognizes it as a provider. Here's what our code looks like so far:

@ValidatorConstraint({ async: true, name: 'UserExist' })
@Injectable()
export class UserExistConstraint implements ValidatorConstraintInterface {}

Implement the validate method from the interface. This method receives a userId number as a parameter. Call the findOne method from UsersService to retrieve the user with that ID. Return !!user for true if exists and false otherwise.

Finally, define a defaultMessage in case you don't specify one when using the decorator. That's it—your constraint is ready.

@ValidatorConstraint({ async: true, name: 'UserExist' })
@Injectable()
export class UserExistConstraint implements ValidatorConstraintInterface {
  constructor(private readonly usersService: UsersService) {}

  async validate(userId: number) {
    const user = await this.usersService.findOne(userId);
    return !!user;
  }

  defaultMessage() {
    return 'User with the given ID does not exist.';
  }
}

To avoid sprinkling Validate everywhere, we’ll wrap the constraint in a reusable decorator.

Making it a Decorator

Let's wrap our constraint in a reusable decorator so we can apply it to any DTO using the decorator pattern. Register the decorator as UserExist with the registerDecorator utility. In the validator property, use the constraint we just defined: UserExistConstraint.

export function UserExist(validationOptions?: ValidationOptions) {
  return function (object: object, propertyName: string) {
    registerDecorator({
      target: object.constructor,
      async: true,
      propertyName,
      options: validationOptions,
      validator: UserExistConstraint,
    });
  };
}

And there you go—your userId will be validated each time you call the tasks endpoint. Or will it? Not yet. We need to integrate it into the Nest lifecycle.

The final spice in our Recipe

We need to tell Nest that this constraint is a provider and tell class-validator to use the Nest container to resolve dependencies.

First, add UserExistConstraint as a provider in the TasksModule. This way, Nest will allow TasksModule to inject this constraint. Don't forget to import the UsersModule so you can inject the UsersService.

@Module({
  imports: [UsersModule],
  controllers: [TasksController],
  providers: [TasksService, UserExistConstraint],
})
export class TasksModule {}

Finally, in the main.ts file, import the useContainer function from class-validator and configure it to use the Nest app (the Nest container) for dependency injection. And voilà! Your custom validator should now work.

useContainer(app.select(AppModule), { fallbackOnErrors: true });

With DI in place, we can verify runtime behavior with a quick request.

Integrations Tests… Kind of

Add some dummy data to your database using Drizzle Studio, Drizzle Seed, or directly in your database; for this example, I used Drizzle Seed. Now, test the tasks endpoint. If the ID exists, you should see a result similar to this:

[
  {
    "id": 3,
    "title": "ulcXZ7wJVwvLI6whPeg",
    "description": "cfMBXl9heU9w75Ijkpx",
    "userId": 4,
    "createdAt": "2025-07-23T03:18:12.712Z",
    "updatedAt": "2025-03-27T16:56:35.363Z",
    "user": {
      "id": 4,
      "name": "Shauna",
      "email": "inflatable_autum@web.de",
      "createdAt": "2023-10-24T10:58:31.664Z",
      "updatedAt": "2024-02-18T23:40:17.943Z"
    }
  }
]

If not, you should receive a 400 error with the message User with the given ID does not exist. You can also specify a custom message when using the decorator.

{"message":["User with the given ID does not exist."],"error":"Bad Request","statusCode":400}

This flow confirms that validation happens before executing business logic, reducing errors and coupling.

Final Thoughts

This pattern is easy to extend and customize when building custom decorators and getting the most from Drizzle ORM and the NestJS framework. As homework, try validating task existence by creating a find-one endpoint, or validate email uniqueness—your imagination or stakeholder requirements are the limit.

Let me know in the comments how you feel about this approach or if you want to dive deeper into any topic covered in this tutorial. You can check the complete code in this repository: https://github.com/RubenOAlvarado/custom-validations-example

I hope this helped you create better RESTful APIs with NestJS. I'll see you in the next one!

Problem Statement

Write a function that takes a string as input and returns the string with the first letter of each word capitalized. The words are separated by spaces.

Breaking down the problem statement: we have an input—a string of words separated by spaces. We need to process each word to capitalize its first letter. Finally, our output will be the same string, but processed.

Now it's time to define our algorithm to process the string and obtain the requested output.

Algorithm to Solve it

First, we need to split the whole string into words. This is where the string package comes to save the day—without it, we'd have to find each space in the string and split from there. Better to choose the correct tool.

words := strings.Fields(s)

Using the strings package and its Fields method, we split our string into a slice of words separated by spaces. Easy, right? Don't forget to import the strings package.

Now, using a for range loop, we'll iterate through our slice of words, obtaining both the index and the word itself.

for i, word := range words {}

For each string, we'll pick the first letter and replace it with the same character uppercased. To do this, we're going to use an external package called cases in combination with the language package.

This line tells Go that the word variable is a string that should be titled (capitalize its first letter) in English. The result is then reassigned to the word at the current index in the words slice.

words[i] = cases.Title(language.English).String(word)

Finally, once the entire slice has been processed, return it as a single string. Use the strings package again to join the slice elements with blank spaces between them.

return strings.Join(words, " ")

And there you have it! You've successfully capitalized the first letter of each word in the string using the right tools.

Final Thoughts

As you can see, leveraging Go's built-in and external packages leads to cleaner, more maintainable code. Rather than implementing complex string manipulation from scratch, we can rely on well-tested libraries that solve common problems efficiently.

With just a handful of lines, Go enables us to write elegant solutions that are both readable and performant. This approach not only saves development time but also reduces the potential for bugs.

Don't forget to declare your modules to use the cases and language packages—they aren't built-in ones. As always, you can find the complete code in my GitHub repo: https://github.com/RubenOAlvarado/algorithms

Keep learning, and I'll see you in the next one!

Then the next idea comes along and you feel that adrenaline rush again—"this time I'm going to finish this project. This one will work." But you're lying to yourself, because you said the same thing for the last three projects and none of them are completed yet.

Divide and Conquer

In Mexico, there's something called "misiles"—translated as missiles. They're huge glasses that hold around two or three liters of alcohol. Sometimes just beer, sometimes prepared beer, and sometimes a mix of different drinks.

Here's the thing: people try to drink it all in one go. The obvious result? They get an absurd level of alcohol in their body, getting fully drunk and even blacking out. The body can't process that much alcohol at once.

Wouldn't it be better to drink it in sips and enjoy the whole night? The same thing happens with side projects. People try to finish everything in a weekend, then get burned out and quit.

Clear your path setting goals

Why try to finish it all in one rush? Instead, plan and deliver part by part.

Set a plan before you even start coding. Define where you want to go and how you'll get there. Once you have the whole picture, you might realize your idea isn't as original as you thought, or not as easy as you thought, or even not what you thought.

You want to create the next Facebook? Start with the post creation flow. Once it's working and deployed, move on to user profiles. Then add photos, stories, reels, etc. You get the idea.

Avoid Overengineering

Please, please. For God's sake. YOU DON'T NEED NETFLIX ARCHITECTURE for your startup.

Forget about microservices, Kubernetes, and Kafka. You don't need them now.

Avoid complex code that builds itself from just an entity name—it only adds complexity and coupling. As I've been saying throughout this post: it's better to deliver something simple than nothing.

I'm not saying you should never think about scaling or that you won't need it. But not at the start, not right now.

Have you considered validating your idea before thinking about microservices?

Let me tell you a story:

Some friends and I got together with an idea for an app to break the system and be our own bosses. We started planning the architecture. I defined the backend with microservices in Node.js to ensure speed. The frontend guy proposed Flutter to compile for both iOS and Android. The infrastructure guy proposed using Gorilla and Kubernetes to keep microservices always available.

But do you know what the idea was? A Tinder for dogs… Yeah, I know. We were young, and at the time the idea sounded cool. But when we presented it to someone else, they looked at us like "what?"

Why did we need Kubernetes for something people wouldn't even use? You see my point?

Is not about motivation, it’s about discipline

Maybe you're thinking: "What a fraud—this guy won't tell me how to get things done." But I challenge you to name more than ten people who've created something through brute force alone.

We all have ideas. So why can't we turn them into something tangible? Because we lose motivation along the way.

So how can we keep motivation? Well, the secret isn't keeping motivation—it's building discipline.

As Uncle Bob said: "Dedication and professionalism are more about discipline than hours." Make sure you respect your time and energy. Paraphrasing Uncle Bob again: "The worst code I wrote was the code I wrote at 3 AM."

This brings us back to the beginning. You tried so hard to complete that side project or SaaS idea in a brute force rush, but when motivation fades, you abandon it.

Conclusion: Becoming Super Saiyan

Remember the Namek saga? Goku recovered from his battle with Vegeta and started training to join his friends on Namek.

His spaceship had gravity settings up to 300G. But he didn't start there—he began with 20G. Once he adapted, he moved up to 50G, and kept progressing gradually. If he had jumped straight to 300G, he would have gotten injured and failed. We'd never have seen the Super Saiyan transformation—one of the most iconic moments in anime culture.

So why do you keep trying to rush through a project or only work when you feel motivated? Take your time to think about it, and I'll see you in the next one.

We'll solve the first turn of a BlackJack game. In this exercise, we're covering Go fundamentals and the underestimated switch statement, which isn't used frequently—even in technical interviews.

Problem Statement

Simulate the first turn of a BlackJack game. You'll receive two cards and see the dealer's face-up card. All cards are represented as strings like "ace", "king", "two", etc.

The value of each card is:

Note: Commonly, aces can take the value of 1 or 11 but for simplicity we will assume that they can only take the value of 11.

Depending on your two cards and the card of the dealer, there is a strategy for the first turn of the game, in which you have the following options:

• Stand (S)

• Hit (H)

• Split (P)

• Automatically win (W)

Although not optimal yet, you will follow the strategy your friend Alex has been developing, which is as follows:

• If you have a pair of aces you must always split them.

• If you have a Blackjack (two cards that sum up to a value of 21), and the dealer does not have an ace, a face card (Jack/Queen/King) or a ten then you automatically win. If the dealer does have any of those cards then you'll have to stand and wait for the reveal of the other card.

• If your cards sum up to a value within the range [17, 20] you should always stand.

• If your cards sum up to a value within the range [12, 16] you should always stand unless the dealer has a 7 or higher, in which case you should always hit.

• If your cards sum up to 11 or lower you should always hit.

Breaking Down the Problem

At first glance, the problem looks complex because there are too many constraints and scenarios. But if you break it down as we've been doing throughout this series, you'll find it's not as hard as it looks.

Let's start by identifying our input. We'll receive three strings with card representations: two for our cards and one for the dealer.

Next, we need to determine each card's value—its number representation—so we can sum them up and decide our move.

Finally, the desired output is the first turn move based on Alex's strategy from the problem statement.

This algorithm consists of two crucial steps: convert the input strings to their number representations, and determine which move corresponds to them.

Parse Input Cards

The first step is converting input string cards into their number representation. While the exercism exercise focuses on learning how to work with switches, we're using maps to simplify this solution. In the next part, we'll use the switch statement as intended in the original exercise.

Let's define the ParseCard function using a map with string keys and int values:

func ParseCard(card string) int {
    return map[string]int{
        "ace": 11, "two": 2, "three": 3, "four": 4, "five": 5,
        "six": 6, "seven": 7, "eight": 8, "nine": 9, "ten": 10,
        "jack": 10, "queen": 10, "king": 10,
    }[card]
}

And voilà! You've solved the first part in just one line. There are other approaches for this function, but I think this is the most effective way to demonstrate the use of maps.

For example, you can use constants if you want to impress your interviewer:

const (
    Ace   = "ace"
    Two   = "two"
    Three = "three"
    // ... another values
)

var cardValues = map[string]int{
    Ace:   11,
    Two:   2,
    Three: 3,
    // ...other values
}

func ParseCard(card string) int {
    return cardValues[card] // default value is 0 for a int in Go
}

Algorithm to Solve the First Turn

Now that we've mapped each card name to its corresponding value, we need to determine our first move.

We'll create a simple switch statement with the different constraints from the problem statement.

First, we need to parse our input cards.

parsedCard1 := ParseCard(card1)
parsedCard2 := ParseCard(card2)
parsedDealerCard := ParseCard(dealerCard)

Now that we know how much each card is worth, we need to sum the values of our two cards to check if it's a blackjack.

sumCards := parsedCard1 + parsedCard2

Now, with the elegance and magic of Go's syntax, let's validate each scenario to determine our first move. The first constraint is if you have a pair of aces, you must split—this means if our cards sum to 22 (each ace values 11), then our first turn is a split and we should return the letter "P".

switch{
    case sumCards == 22:
        return "P"
}

The second constraint: if you have a Blackjack (21) and the dealer doesn't have an ace, face card (Jack/Queen/King), or ten, you automatically win. In other words, if you have 21 and the dealer's card is less than 10, you win.

case sumCards == 21 && parsedDealerCard < 10:
    return "W"

However, if you have 21 and the dealer has any of these cards (an ace or a face card), you must stand this turn.

case sumCards == 21 && parsedDealerCard >= 10:
    return "S"

Next, if your cards sum to a value within the range [17, 20], you should always stand.

case sumCards >= 17 && sumCards <= 20:
    return "S"

If your cards sum to a value between 12 and 16, you should always stand—unless the dealer has a 7 or higher, in which case you should hit.

The first condition looks like this:

case sumCards >= 12 && sumCards <= 16 && parsedDealerCard >= 7: //dealers card equal or higher than 7
    return "H"

The next condition handles when the dealer's card is less than 7:

case sumCards >= 12 && sumCards <= 16 && parsedDealerCard < 7:
    return "S"

If your cards sum to 11 or lower, you should always hit. This means any uncovered scenario equals a hit, since we've covered all possible scenarios. So our default is "H".

default:
    return "H"

And voilà! You've created an algorithm to calculate the first turn in a Blackjack game. You've also learned about maps, switch statements, and conditionals.

Final Thoughts

This exercise demonstrates how breaking down complex problems into smaller, manageable steps makes them much easier to solve. What initially seemed like a complicated set of rules turned into a straightforward algorithm by identifying the key components: parsing card values and evaluating conditions systematically.

The switch statement in Go proves to be incredibly powerful for handling multiple conditional branches in a clean, readable way. Combined with maps for value lookup, we created an elegant solution.

As you continue your Go journey, remember that most real-world problems can be tackled the same way—break them down, identify patterns, and leverage Go's simple yet powerful features.

Keep practicing, keep coding, and most importantly—have fun with it! If you enjoyed this exercise, explore more challenges on exercism to continue building your Go skills. As always, you can find the complete code in my GitHub repo: https://github.com/RubenOAlvarado/algorithms

Happy coding and see you in the next one!

This is a commonly asked question for entry-level positions as it covers Go basics like maps, runes, and string manipulation. We'll explore how to determine if all characters in a string are unique.

Problem Statement

As we have been doing, let's start by understanding the problem statement.

Implement an algorithm to determine if a string contains only unique characters.

Breaking down the problem statement, we have a string as input, we need to process each character in the string to determine if any are repeated, and finally return a boolean as output.

Now that we've established our input, process, and output, let's define our algorithm to solve it.

Algorithm to Solve it

The first step is to initialize a data structure to contain each character and track its occurrences. In Go, we have maps for this purpose. Using the make built-in function, let's declare our set of characters.

When used for maps, this function expects just one argument: the type for the map. Here, we're declaring a map of runes with bool values to keep track of each character's occurrence.

charMap := make(map[rune]bool)

Next, utilizing Go's elegant for-range loop syntax, we iterate through each character in the string.

for _, c := range s {} //s is the input string

Here's where the magic happens: if c is already in charMap, we return false because this character has appeared previously in the string.

if charMap[c] {
    return false
}

If the character isn't in the charMap yet, we add it to track it for future iterations.

charMap[c] = true

Finally, if the loop completes without finding any repetition, it means every character is unique, so we return true.

return true

And voilà! We've solved the unique character algorithm. Here are some test cases you can use to verify the solution:

• abcdef → returns true because it contains no repeated characters.

• hello → returns false because it contains a repeated letter l

Final Thoughts

We are gradually increasing the difficulty of algorithms in this series. As I've been emphasizing throughout, you must strengthen your fundamentals before tackling more complex challenges. There's a saying: "Learn to walk before you run."

So, keep practicing and remember me when you land that desired job. As usual, you can find this and other algorithms in Go and TypeScript in my algorithms GitHub repo: https://github.com/RubenOAlvarado/algorithms

Until the next one!

Join me as we solve the classic Sum Digits algorithm and land that dreamed job.

Problem Statement

Given an integer, return the sum of its digits. For example, if the input is 123 the output should be 6 (1+2+3).

Let's break down the problem statement: we have an integer as input, we need to process each of its digits, and return an integer as output.

Now that we've established our input, process, and output, let's define our algorithm to solve it.

Algorithm to Solve It

First, we need to check if our input is negative. If it is, we'll convert it to a positive value.

if n < 0 {
    n = -n
}

Initialize a variable sum to 0 to track our running total

sum := 0

Now, implement a loop that continues as long as n is not zero. In Go, this for loop works like a while loop, checking if n is greater than 0

for n != 0 {}

For each iteration, add the last digit of the number to the sum variable using the modulo operator.

sum += n % 10

Then, use the division assignment operator to remove the last digit from the number.

n /= 10

Finally, return the accumulated sum.

return sum

Complete Function Implementation

func sumDigits(n int) int {
    if n < 0 {
        n = -n
    }
    sum := 0
    for n != 0 {
        sum += n % 10
        n /= 10
    }
    return sum
}

Final Thoughts

Go is a beautiful language. This simple yet efficient function demonstrates the language's minimalist mindset. With the rapidly growing demand for Go developers, strengthening your fundamentals is essential to landing that desired job.

Remember, keep learning. Improvement is a marathon, not a sprint. As always, you can find the code for this and other examples in my GitHub repository: https://github.com/RubenOAlvarado/algorithms

Cover photo belongs to Bekky Bekks in Unsplash

Throughout my technical interview journey, I’ve observed a shortage of Go-based Data Structures and Algorithms (DSA) examples. As Go has become increasingly in-demand and I’ve been studying it extensively, I’ve decided to transition my DSA series from JavaScript/TypeScript to Go. The elegant syntax of Go makes this transition exciting — it feels like exploring a whole new world.

I’ll start with a super basic algorithm to warm up: The Sum of Natural Numbers. Join me as we explore this simple yet effective algorithm.

Disclaimer: This post assumes you have basic knowledge of Go and are preparing for job interviews.

Problem Statement

Given a positive integer n return the sum of all natural numbers from 1 to n .

Breaking down the problem statement, we have: an input (a positive integer), the required logic (sum all natural numbers), and an output (the resulting integer from the sum). Let’s use this structure to define our algorithm.

How to Solve it

If you’ve read my previous posts about DSA, you know I prefer a straightforward approach: explaining the problem statement first, then the algorithm to solve it, and finally the implementation.

Now, let’s continue. The first step is to handle the input. We need to validate if it’s a positive number since this is a constraint in the problem statement. This is a basic validation: if the input number (n) is less than 0, it means it's not positive, so we return 0.

if n < 0 {
    return 0
}

Now, declare a sum variable where we'll accumulate the value of every number.

sum := 0

Thanks to the elegance of Go, we can create a loop using the range syntax. When we declare a variable i that iterates through the range of n, we're creating a loop that runs from 0 to n-1.

for i := range n {}

Go is such a beautiful language. It’s important to note that this syntax only works with Go 1.22 or newer. With older versions, you’ll need to use a conventional for loop instead.

for i := 0; i < n; i++ {}

Next, add the value of the current iteration plus 1 to our sum variable, since our loop starts from 0.

sum += i + 1

Once the loop concludes, you simply return the accumulated sum.

return sum;

Complete Implementation

The complete implementation of our solution for summing natural numbers is presented below. When reviewing this implementation, notice how concise yet readable the Go syntax is:

func sumNaturalNumbers(n int) int {
    if n < 0 {
        return 0
    }
    sum := 0
    for i := range n {
        sum += i + 1
    }
    return sum
}

And voila! You’ve just completed your first technical interview question using Go. While we haven’t covered any data structures yet, this example serves as an excellent starting point for your Go DSA journey.

Final Thoughts

While this algorithm is simple, it effectively demonstrates Go’s capabilities as a programming language. The elegant syntax and performance characteristics make Go particularly attractive for technical interviews and real-world applications.

There’s a saying in the arts: “you need to know the rules to break them.” Similarly, to excel in technical interviews, you need strong fundamentals. The best approach combines a clear starting point (like this basic algorithm), a solid plan for tackling more complex problems, and consistent discipline in practice. I hope this example helps you in your next technical interview and assists you in landing your desired job.

You can find the code for this and other algorithms in my GitHub repository: https://github.com/RubenOAlvarado/algorithms

Keep learning, and I’ll see you in the next one!

When building an API, you often need to handle complex query parameters. If you’re just coding casually, this might not be a concern, but when building a real-world solution, pagination, filtering, and sorting are essential for creating a robust and scalable API.

In my current project with NestJs, I faced this challenge. Initially, I thought, “Easy, I just need to write the DTOs” — but it wasn’t that simple. Today, I’m going to show you how to implement complex filtering in a NestJs endpoint.

NestExpressApplication

First, we need to create a new Nest project. If you’ve already installed the CLI, this is a simple step. If not, I highly recommend installing it.

nest new complex-query-filters

Since we’ll need to validate and transform our DTOs, let’s install class-validator and class-transformer packages.

npm i class-validator class-transformer

There you have it — a minimal NestJs API. However, to handle complex queries, we need to make a small change in our project: declaring the app as a NestExpressApplication. You might ask, "Isn't it an Express app by definition?" And you're right, but explicitly declaring the app type gives us access to Express-specific utilities.

const app = await NestFactory.create<NestExpressApplication>(AppModule);

Now, we can define the query parser of our application, letting Nest know that our application is going to handle complex query parameters.

app.set('query parser', 'extended');

Validations, A Pragmatic Programer Always Include Validations

That’s it! Now your Nest app handles complex queries like: dateRange[lte]=2023-10-26T10:00:00.000Z&search=something. But what happens if someone sends a SQL injection or something that could crash your app? As software engineers, we need to ensure we're building robust applications.

To accomplish this, we’ll follow a simple structure by creating DTOs that tell our server which properties we want to receive. Let’s start with the search fields. Create a new file with a class called SearchFieldsDto that will define the valid properties clients can search by. I'll keep it simple by declaring just two properties.

export class SearchFieldsDto {
  @IsOptional()
  @IsString()
  @IsAlphanumeric()
  @MinLength(2)
  @MaxLength(30)
  category?: string;

  @IsOptional()
  @IsString()
  @IsAlphanumeric()
  @MinLength(2)
  @MaxLength(20)
  status?: string;
}

For a more detailed look at the validations we’re using, I highly recommend checking the class-validator docs. Now, let’s build our FiltersDto.

Building the FiltersDto

To keep this post concise, I’ll add some simple filters to demonstrate the approach. Let’s create our FiltersDto class with three properties: status, category, and dateRange. We’ll also create another class for the operators that can filter by date range.

export class DateRangeDto {
  @IsOptional()
  @IsDateString()
  gte?: Date;

  @IsOptional()
  @IsDateString()
  lte?: Date;
}

export class FiltersDto {
  @IsOptional()
  @IsEnum(['active', 'inactive', 'pending'], {
    message: 'Status must be one of: active, inactive, pending',
  })
  @IsString()
  status?: string;

  @IsOptional()
  @IsString()
  @IsEnum(['electronics', 'furniture', 'clothing'], {
    message: 'Category must be one of: electronics, furniture, clothing',
  })
  category?: string;

  @IsOptional()
  @IsObject()
  dateRange?: DateRangeDto;
}

With this structure, we’re telling our Nest application that it can handle requests with nested attributes, such as: dateRange[lte]=2023-10-26T10:00:00.000Z.

The QueryDto Class

Finally, let’s combine everything into a single QueryDto class. We'll add page and limit attributes, plus a sort property that specifies which fields we can sort by and in which direction. First, let's create the SortFieldsDto.

export class SortFieldsDto {
  @IsOptional()
  @IsString()
  @IsIn(['asc', 'desc'])
  category?: 'asc' | 'desc';
}

Now when someone sends the sort parameter, it can only sort by category and only accept the values “asc” or “desc” — something like this: sort[category]=asc. Let's combine everything into our QueryDto class, which will extend our FiltersDto.

export class QueryDto extends FiltersDto {
  @IsOptional()
  @IsObject()
  @ValidateNested()
  @Type(() => SearchFieldsDto)
  search?: SearchFieldsDto;

  @IsOptional()
  @IsInt()
  page?: number;

  @IsOptional()
  @IsInt()
  limit?: number;

  @IsOptional()
  @IsObject()
  @ValidateNested()
  @Type(() => SortFieldsDto)
  sort?: SortFieldsDto;
}

We could separate everything into its own DTO and group them with the Intersection utility, but I think this approach better demonstrates how to structure the DTO visually. So there you have it — your API is now validated and prevents SQL or RSQL injections… or does it? Well, not yet.

ValidationPipe Comes to the Rescue

If you send a request like dateRange[lt]=today&search[magumbos]=something with the current project setup, NestJS will accept it as valid because we haven't explicitly defined our validation and transformation rules yet. To fix this, let's go to the main.ts file and add the useGlobalPipes method before the app.listen line.

app.useGlobalPipes();

This method requires a ValidationPipe instance to function. The validation instance accepts an object containing key-value pairs that define our validation and transformation rules for the entire project. You can configure these rules at different levels (per module, controller, etc.), but that's a topic for another post.

new ValidationPipe({
    whitelist: true,
  transform: true,
  forbidNonWhitelisted: true,
  transformOptions: { enableImplicitConversion: true },
}),

With this configuration, we’re instructing our validation pipe that all properties should be whitelisted, transformed, and any non-whitelisted properties should be forbidden. We’re also enabling implicit object conversion. As a result, when you send a request like dateRange[lt]=today, you'll receive a bad request response indicating that the property lt should not be present.

If you send this request: http://localhost:3000/?dateRange[lte]=2023-10-26T10:00:00.000Z&search[status]=so&page=1&limit=10&sort[category]=asc, you'll get this result:

Hello World! Query: {"dateRange":{"lte":"2023-10-26T10:00:00.000Z"},"search":{"status":"so"},"page":1,"limit":10,"sort":{"category":"asc"}}

Final Thoughts

With this simple example, I’ve demonstrated the importance of being a software developer rather than relying entirely on AI tools. I spent several minutes asking ChatGPT, Claude, and DeepSeek how to handle this type of query in NestJS.

They all suggested complex solutions and approaches, when I just needed to read the documentation to realize it was a one-line change. The lesson here is that while it’s great to use new tools to help solve problems, there’s always a need to develop solutions on your own.

Keep learning, and I’ll see you in the next one. You can find all the code for this example in the following GitHub repository: https://github.com/RubenOAlvarado/complex-query-filters

Have you ever waited in line for an artist’s autograph? If so, you know what I’m talking about. You wake up early in the morning to be first in line and get your favorite record, poster, or book signed.

Well, that’s FIFO in action. And the data structure we’re going to review this week follows this principle. We are learning how to implement Queues.

First In First Out

Queues implement FIFO (First In First Out) ordering. This means items are removed from the queue in the same order that they are added.

Unlike the stack data structure, queue ordering works like waiting in line to meet your favorite idol. The position you get in line is the position in which you’ll get to shake those famous hands.

Hold the Line

This week we are going to implement a Queue. Like a stack, it can be implemented with a linked list, as they are essentially the same structure — just with items added and removed from opposite sides.

We’ll reuse the Node class we created earlier in the stack post:

export class Node<T> {
    value: T;
    next: Node<T> | null;

    constructor(value: T) {
        this.value = value;
        this.next = null;
    }
}

This Node class will store each item in the Queue, holding the actual value along with a reference to the next item.

Now for our Queue class, we’ll follow the same approach, taking advantage of TypeScript Generics. Unlike a stack, however, we’ll keep track of both the first and last items in our queue.

export class Queue<T> {
    first: Node<T> | null;
    last: Node<T> | null;
    size: number;
}

In our constructor, we need to initialize the first and last node references. This ensures that each time a new Queue is instantiated, we have default values for our first and last items in the Queue.

constructor(value: T) {
  this.first = new Node(value);
  this.last = this.first;
  this.size = 1;
}

Enqueueing an Item

The enqueue operation adds an item to the end of the queue. The first step is to create a new node.

const newNode = new Node(value);

Since this new node will become the last item in the queue (as it’s the newest to join), we need to check if the last variable is not null. If it has a value, we connect its next pointer to this new node.

if(this.last !== null) this.last.next = newNode;

Next, we update the last pointer to reference our newly created node.

this.last = newNode;

We also need to ensure that the first variable has a value. If it’s null, it means this new node is the first element in the queue.

if(this.first === null) this.first = this.last;

Finally, we increment the queue size. And voila! Our queue can now enqueue new items.

Dequeueing an Item

This operation removes the first item in the queue. The first step is to verify that the first variable is not null. If it is null, we simply return null because there are no items in the queue.

if(this.first === null) return null;

Now that we’ve verified the first variable has a value, we assign this value to a new constant called nodeToDequeue to keep track of the node we’ll remove.

const nodeToDequeue = this.first;

Next, we need to reassign the first variable to point to the next item (node) in the queue, as this will become our new first element.

this.first = this.first.next;

Next, we need to check if there are any nodes left in the queue. If the first pointer is now null, it means our queue is empty and we must also clear the last pointer.

if(this.first === null) this.last = null;

Finally, we decrement the queue size and return the value of the removed node.

this.size--;
return nodeToDequeue.value;

And voila! Our queue now has the capability to dequeue its elements. Simple, isn’t it?

Peeking the Top

This operation returns the first item in the queue while ensuring it has a value. It’s straightforward since we’ve already created our first variable — we simply return its value if it exists, or null if it doesn’t.

return this.first ? this.first.value : null;

As you can see, we resolved this with an elegant one-liner. This simple operation allows us to peek at the first item in our queue without removing it.

Is the Queue Empty?

This operation checks if our queue is empty by examining its size. If the size equals 0, it means there are no items in our queue, indicating it’s empty. The method simply returns this evaluation.

return this.size === 0;

Complete Typescript Implementation

export class Queue<T> {
    first: Node<T> | null;
    last: Node<T> | null;
    size: number;

    constructor(value: T) {
        this.first = new Node(value);
        this.last = this.first;
        this.size = 1;
    }

    enqueue(value: T): void {
        const newNode = new Node(value);
        if(this.last !== null) this.last.next = newNode;
        this.last = newNode;
        if(this.first === null) this.first = this.last;
        this.size++;
    }

    dequeue(): T | null {
        if(this.first === null) return null;
        const nodeToDequeue = this.first;
        this.first = this.first.next;
        if(this.first === null) this.last = null;
        this.size--;
        return nodeToDequeue.value;
    }

    peek(): T | null {
        return this.first ? this.first.value : null;
    }

    isEmpty(): boolean {
        return this.size === 0;
    }
}

Final Thoughts

In this post, we have explored the Queue data structure and its FIFO (First In, First Out) principle. We reviewed how to implement a Queue in TypeScript, using linked nodes similar to those we used in stacks, but with the crucial difference of adding elements to the end and removing them from the beginning.

We implemented four fundamental operations: enqueue to add elements, dequeue to remove them, peek to check the first element without removing it, and isEmpty to verify if the queue is empty. These operations allow us to manipulate the queue efficiently, always maintaining the order of arrival.

Queues are fundamental data structures that appear in numerous programming contexts and in everyday situations, like waiting in line for your favorite artist’s autograph. Understanding their operation and implementation gives us powerful tools to solve problems that require processing elements in the same order they were received.

As alway you can find the code in my Data Structures repository: https://github.com/RubenOAlvarado/data-structures

Until the next one!

It’s Friday night, and after a hard week, all you want is to play ranked matches in Street Fighter 6 for that dopamine rush from defeating novice players. But before that, you realize your dishes have gone unwashed for three days, and your wife is as furious as a Ken player who failed to trap you in the corner.

You need to tackle this stack of plates before you can even think about putting your hands on that controller. When you reach the last plate, you realize that you forgot to throw away the food remains, and now it’s an indescribable, amorphous thing staring directly at you. This plate was the first in and the last out — and now you regret not maintaining this basic habit.

LIFO in Action

This is a great example of the LIFO principle, this means that the last item to be added to the stack is going to be the first to be removed.

This has great usability in scenarios when you need to keep track of function calls, undo operations or manage resources in a controlled manner.

Stacks are there in our daily basis, so today we are going to implement our own custom stack in typescript.

All About Nodes

To store each item in the stack, we’ll create a Node class. We’ll take an approach similar to linked lists, where each node connects to the next one. This structure allows us to efficiently add or remove items from the same side of the stack.

export class Node<T> {
    value: T;
    next: Node<T> | null;

    constructor(value: T) {
        this.value = value;
        this.next = null;
    }
}

This is a simple yet effective implementation that serves two essential purposes: storing the actual value we want to keep in our stack and maintaining a reference to the next Node in the sequence. The Node class uses generics (represented by ) to allow for type flexibility, meaning our stack can store any data type — whether numbers, strings, objects, or custom types — while maintaining type safety throughout the application. When we instantiate a new Node, the next property is initially set to null, indicating it’s not connected to any other node yet.

Creating our Stack Class

Now, let’s proceed with creating our Stack class implementation using TypeScript generics. Generics allow us to build reusable components that can work with different data types while maintaining type safety throughout our application. By leveraging TypeScript’s type system, we’ll ensure our stack operates consistently regardless of what type of data it stores.

export class Stack {}

This class will have two properties: first, which stores the top item in our stack, and size, which keeps track of our stack's length.

first: Node | null;
size: number;

Then, in our constructor, when our stack is instantiated, we are going to initialize our stack with the necessary properties. This initialization process establishes the foundation of our data structure by setting up the first node and determining the initial size. The constructor takes a value parameter, which becomes the first element in our stack, ensuring that our stack begins with at least one item. This approach provides a clean starting point for stack operations and maintains type safety throughout the implementation.

constructor(value: T){
    const newNode = new Node(value);
    this.first = newNode;
    this.size = 1;
}

Popping Up

This method removes the top node from our stack. First, we need to check our first variable to ensure the stack isn't empty.

if(this.first === null) {
    return null; // Stack is empty
}

Now that we’ve ensured our stack isn’t empty, we retrieve the top node’s value in a temporary variable called poppedNode. Then we set our first pointer to the next node in line, making it the new top of our stack.

const poppedNode = this.first;
this.first = this.first.next;

Finally, we decrement our size property to reflect the removal and return the value of the poppedNode.

this.size--;
return poppedNode.value;

And there you go, our pop method is now fully implemented and ready to efficiently remove items from the top of our stack. This implementation follows the LIFO principle we discussed earlier, ensuring that only the most recently added element can be removed.

Pushing a New Item

This method adds a new node to the top of our stack. Similar to the pop method, we first check if our stack is empty. If it is, this new node becomes the first one in our stack.

if(this.first === null) {
    this.first = new Node(value);
    this.size = 1;
    return;
}

If the stack is not empty, we need to add the new node to the top. First, we create a new Node instance. Then we link our existing first node as the next value of our new node and reassign the first pointer to this new node. Finally, we increment the size of our stack.

const newNode = new Node(value);
newNode.next = this.first;
this.first = newNode;
this.size++;

And there you go, our stack implementation now has the ability to efficiently push new nodes to the top of the stack. This method adheres to the LIFO principle by ensuring that newly added elements become immediately accessible at the top of the stack, ready to be the first ones removed when a pop operation is performed.

Peeking the Top Node

This method allows us to examine the top node of our stack without removing it, providing a valuable way to inspect the most recently added element. When implementing the peek operation, we first need to perform a crucial validation to verify that our stack contains at least one element.

if(this.first === null) {
    return null; // Stack is empty
}

Once we confirm the stack isn’t empty, we can simply return the value of the top node. Since we’ve already stored this in the first variable, we just need to return the value property of this node.

return this.first.value;

And there you have it. Our stack implementation now allows us to peek at the top node without removing it.

The Stack is Empty?

This method will check if our stack has nodes in it. It serves as a useful utility function that allows us to determine whether our stack contains any elements or if it’s completely empty. To determine this, we simply check whether the size property equals zero.

return this.size === 0;

Complete Typescript Implementation

Node class:

export class Node<T> {
    value: T;
    next: Node<T> | null;

    constructor(value: T) {
        this.value = value;
        this.next = null;
    }
}

Stack class:

export class Stack<T> {
    first: Node<T> | null;
    size: number;

    constructor(value: T){
        const newNode = new Node(value);
        this.first = newNode;
        this.size = 1;
    }

    push(value: T): void {
        if(this.first === null) {
          this.first = new Node(value);
        this.size = 1;
        return;
      }
      const newNode = new Node(value);
      newNode.next = this.first;
      this.first = newNode;
      this.size++;
    }

    pop(): T | null {
        if(this.first === null) {
            return null;
          }
          const poppedNode = this.first;
          this.first = this.first.next;
          this.size--;
          return poppedNode.value;
    }

    peek(): T | null {
        if(this.first === null) {
            return null;
          }
          return this.first.value;
        }

        isEmpty(): boolean {
            return this.size === 0;
        }
}

Final Thoughts

Stacks play a crucial role in recursive algorithms, offering an elegant solution for managing function calls and tracking execution states. Implementing a stack from scratch, as we’ve done here, provides valuable insight into the inner workings of this fundamental data structure. It serves as an excellent exercise for strengthening your understanding of both data structures and TypeScript’s type system, while also developing practical skills that can be applied to solve complex programming challenges in real-world applications.

As usual, you can find this code and other Data Structures implementations in my GitHub repository: https://github.com/RubenOAlvarado/data-structures

Continue your learning journey and stay persistent with DSA challenges. See you in the next article!

Welcome back, algorithm enthusiasts! I hope you are enjoying this series revisiting the most frequently asked algorithms and data structures in technical interviews.

Throughout this series, we’ve covered a wide range of topics — from implementing custom Arrays and Hash Tables to solving common coding challenges like reversing strings, finding the maximum character in a string, and validating palindromes.

Today we are moving forward in difficulty and we are going to implement another one at the top of the notch. The balanced string also now as valid parenthesis problem.

Understanding the Problem

The problem statement for this challenge is as follows:

Given a string s containing just the characters ‘(‘, ‘)’, ‘{‘, ‘}’, ‘[‘ and ‘]’, determine if the input string is valid.

Now, let’s consider the constraints we need to follow when solving this problem:

• Open brackets must be closed by the same type of brackets.

• Open brackets must be closed in the correct order.

• Every close bracket has a corresponding open bracket of the same type.

This is interesting — we have specific constraints to follow. Let’s analyze the problem statement: we have an input string containing only certain bracket characters, and we need to return a boolean indicating whether the input is valid according to the given rules.

“How do I solve this?” you might be asking yourself. The first time I faced this problem, I brute-forced it with numerous if statements and for loops. I even tried creating a map to count each character’s appearances, then dividing and checking modular results to ensure each bracket pair balanced to zero.

I know, I know. Like Plato’s cave allegory, I was blinded by my limited knowledge. After studying data structures and algorithms more thoroughly, I realized there’s a simple and efficient way to solve this challenge using a common structure known as a stack.

Last In First Out

It’s Friday night, and after a hard week, all you want is to play ranked matches in Street Fighter 6 for that dopamine rush from defeating novice players. But before that, you realize your dishes have gone unwashed for three days, and your wife is as furious as a Ken player who failed to trap you in the corner.

You need to tackle this stack of plates before you can even think about putting your hands on that controller. When you reach the last plate, you realize that you forgot to throw away the food remains, and now it’s an indescribable, amorphous thing staring directly at you. This plate was the first in and the last out — and now you regret not maintaining this basic habit.

Stack of Plates

With the plates analogy, we’ve revealed the core concept of stacks: the first item to be stacked will be the last one to be retrieved. This principle is known as LIFO (Last In First Out) and explains how stacks work under the hood.

Now, imagine that instead of a pile of plates, there are brackets. This is the first step to solving this problem.

Before diving into the code, I need to clarify something first. To solve this exercise, we’ll use a JavaScript array that functions as a stack. The array class has built-in methods that work perfectly for stack operations: push(), pop(), etc. We'll discuss stacks in more detail in the next post, but for now, I wanted to explain this so you won't be confused when you see an array named "stack."

Algorithm to Solve It

• First, declare an empty array called stack where we'll store our characters.

const stack: string[] = [];

• Next, let’s create a map-like object to match opening and closing brackets. We'll use a simple object since we have a specific number of characters to map and need to reduce space complexity. Alternatively, we could use a Map object.

const pairs: Record<string, string> = {'(': ')','{': '}','[': ']',};

• Now that we’ve set up our variables, it’s time to loop through our input string with a good old for…of loop.

for (let char of str) {}

• In each iteration, we check for possible scenarios. If the character is a key in our pairs object, it means it’s an opening bracket. For example: char = "(" → pairs["("] exists and its value is ")", so we push it onto the stack.

if (pairs[char]) {
    stack.push(char);
}

• Otherwise, it must be a closing bracket. We need to verify it matches our last stacked opening bracket. We pop the last opening bracket from the stack and check if the current character is its corresponding closing bracket. If not, we return false because the string is not balanced.

else {
    const last = stack.pop();
    if (pairs[last!] !== char) {
        return false;
    }
}

• Finally, if the stack is empty, it means the string is balanced; otherwise, it means some opening brackets don't have matching closing brackets. We simply return this evaluation.

return stack.length === 0;

With this, we’ve solved the problem. Simple, right? You just need the right knowledge to tackle it effectively. Pay close attention to how the stack interacts with opening brackets to fully grasp the core functionality of this solution.

Complete Typescript Implementation

function balancedString(str: string): boolean {
    const stack: string[] = [];
    const pairs: Record<string, string> = {
            '(': ')',
          '{': '}',
          '[': ']',
        };

    for (let char of str) {
        if (pairs[char]) {
                    stack.push(char);
                } else {
            const last = stack.pop();
                      if (pairs[last!] !== char) {
                        return false;
                      }
        }
    }

    return stack.length === 0;
}

Final Thoughts

Stacks and Queues are fundamental data structures that appear frequently in coding interviews. In upcoming posts, I’ll explore these concepts in greater depth to equip you with the knowledge to tackle similar challenges. As this exercise demonstrates, understanding key Data Structures and Algorithms (DSA) principles enables you to craft elegant, efficient solutions rather than relying on brute force approaches.

As always, you can find this solution along with other algorithm implementations in my GitHub repository: https://github.com/RubenOAlvarado/algorithms
Until next time!

Last week, we began exploring Hash Tables, a crucial data structure for software engineers. Today we’ll continue our review by adding usability features to our custom Hash Table class.

Join me as we dive deeper into the magic of hash tables in this second installment.

Starting from where we left

Let’s make a quick recap of what we covered in our previous session: We began by constructing a custom hash table class that utilizes two generic types - one specifically for the key and another designated for the value. Subsequently, we established a table object designed to function as a container for our various buckets. Following this, we carefully defined a hash function implementing the well-known DJB2 algorithm to efficiently process our keys. This foundation provides us with the essential infrastructure to insert new buckets into our table structure and assign them a properly hashed key, ensuring optimal performance and data organization. These fundamental components form the backbone of our hash table implementation, allowing us to build more sophisticated features on top of this solid base. This leaves our class in the following state:

export class HashTable<K, V> {
  private table: Array<Array<[K, V]>>;

  constructor(private size: number) {
      this.table = new Array(size).fill(null).map(() => []);
  }

  private hash(key: K): number {
    let hash = 5381;
    const strKey = String(key);

    for (let i = 0; i < strKey.length; i++) {
        const char = strKey.charCodeAt(i);
        hash = (hash * 33) + char;
    }

    return Math.abs(hash) % this.size;
  }
}

Adding New Data

Let’s define our set function which will insert or update a new key-value pair in our table. It will receive two generic parameters: one of type K for the key and another of type V for the value. Since it won't return anything, the return type is void.

set(key: K, value: V): void {}

First, in the function body, we need to get the index by hashing the key. Once we have the index, we'll retrieve the corresponding bucket from our table. If no bucket exists at that index, our table initialization will have already created an empty array there.

const index = this.hash(key);
const bucket = this.table[index];

Inside the bucket, we need to find the key. Remember the apartments analogy from the previous post? We have the building and the floor, now we need to locate the specific apartment number.

const existing = bucket.find(([k]) => k === key);

If the apartment already has an occupant (data), we need to update it; if not, we will assign the value.

if (existing) {
    existing[1] = value;
} else {
    bucket.push([key, value])
}

Retrieving Data by Key

Next, let’s create our get method. This method accepts a key parameter of type K and returns a value of type V, giving us the following method signature:

get(key: K): V | undefined {}

Notice the return type declaration includes both V and undefined. This is because the requested key might not exist in our hash table.

Similar to our set method, we first need to find the index and the bucket for the given key. Then we check if the key exists in that bucket. This two-step process is crucial, we first locate the index using our hash function, then search for the specific key within that bucket.

Using our apartment analogy: we first identify the building, then the floor, and finally check if the specific apartment exists on that floor.

const index = this.hash(key);
const bucket = this.table[index];
const entry = bucket.find(([k]) => k === key);

Finally, if the key exists in the bucket, we return the associated value; otherwise, we return undefined. We can achieve this using a ternary operator.

return entry ? entry[1] : undefined;

Checking for Key Existence in Our Hash Table

Now let’s implement our has method, which checks whether a key exists in our hash table. This method operates similarly to the get method, but with one key difference. Let me walk you through it.

Here’s the method signature:

has(key: K): boolean {}

Similar to the get method, this will accept a key parameter of type K, but will return a boolean value that indicates whether the key exists in our hash table. Let's follow the same approach as our previous methods by first obtaining the index and the bucket for the key.

const index = this.hash(key);
const bucket = this.table[index];

Here’s where things get interesting. After obtaining the bucket, we need to check if any entry in it contains our key. This is a perfect use case for the JavaScript some method, which tests whether at least one element in an array passes a given condition.

return bucket.some(([k]) => k === key);

Eliminating Data by Key from our Hash Table

Finally, let’s implement our remove method. This method takes a key parameter of type K and returns a boolean indicating whether the key was successfully removed from the table.

remove(key: K): boolean {}

Next, as you would expect, we’ll retrieve the index and the bucket using the same logic as our previous methods. Once we have the bucket, we need to find the position of the entry with our key so we can remove it from the array. To accomplish this, we'll use the findIndex method to locate the entry and the splice method to remove it.

After finding the index for the key in the bucket (continuing our apartments analogy), we need to check if the entry exists. The findIndex method returns -1 if no match is found or the actual index position if the entry exists.

Let’s add a condition to check before removing the key.

if (entryIndex !== -1)

If it’s not equal to -1, it means the key was found, so we can splice our array and return true because our value was successfully removed from the table; otherwise, we simply return false.

if (entryIndex !== -1) {
    bucket.splice(entryIndex, 1);
    return true;
}
return false;

Optimizing Our Implementation: A DRY Approach

At this point, you might notice we’re repeating ourselves in each method, and a pragmatic programmer never repeats themselves. Let's create a private getBucket method to eliminate this redundancy, since retrieving the bucket is the first step in every operation we perform.

private getBucket(key: K): Array<[K, V]> {
    const index = this.hash(key);
    return this.table[index];
}

This is a private method because it’s only for internal use within our class. It receives the key as a parameter and returns the corresponding bucket from our table.

And there you have it — a complete implementation of a simple Hash Table in TypeScript.

Complete Hash Table Implementation with TypeScript

export class HashTable<K, V> {
    private table: Array<Array<[K, V]>>;

    constructor(private size: number) {
        this.table = new Array(size).fill(null).map(() => []);
    }

    private hash(key: K): number {
        let hash = 5381;
        const strKey = String(key);

        for (let i = 0; i < strKey.length; i++) {
            const char = strKey.charCodeAt(i);
            hash = (hash * 33) + char;
        }

        return Math.abs(hash) % this.size;
    }

    private getBucket(key: K): Array<[K, V]> {
        const index = this.hash(key);
        return this.table[index];
    }

    set(key: K, value: V): void {
        const bucket = this.getBucket(key);

        const existing = bucket.find(([k]) => k === key);
        if (existing) {
            existing[1] = value;
        } else {
            bucket.push([key, value])
        }
    }

    get(key: K): V | undefined {
        const bucket = this.getBucket(key);

        const entry = bucket.find(([k]) => k === key);
        return entry ? entry[1] : undefined;
    }

    has(key: K): boolean {
        const bucket = this.getBucket(key);

        return bucket.some(([k]) => k === key);
    }

    remove(key: K): boolean {
        const bucket = this.getBucket(key);

        const entryIndex = bucket.findIndex(([k]) => k === key);
        if (entryIndex !== -1) {
            bucket.splice(entryIndex, 1);
            return true;
        }
        return false;
    }
}

Final Thoughts

As you can see, Data Structures and Algorithms aren't rocket science once you grasp the core concepts. Creating your own implementations helps you understand why and how they work in practical applications.

Keep practicing — the only way to master something is through consistent practice and patience. As usual, you can review this and other Data Structures in my Github repository: https://github.com/RubenOAlvarado/data-structures.

See you next week!