DEV Community: Ruben Alvarado

Everybody Knows That Drizzle is the Word!

Ruben Alvarado — Mon, 23 Feb 2026 20:21:26 +0000

I’ve worked with plenty of ORMs and database tools over the years—JPA, Hibernate, Knex, Mongoose, Prisma. The list is long. There’s always a new “revolutionary” tool. So when I first heard about Drizzle, I was skeptical.

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:

PostgresProvider

- Input: validated `database.url` from `ConfigService`.
- Output: a single Postgres client wrapper that owns shutdown.

DrizzleProvider

- Input: the Postgres client and app env.        
- Output: the Drizzle DB instance bound to **one DI token**.

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

💡 Note: I’m using @beta here. If you prefer fewer breaking changes, pin a stable version instead.

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.

💡 Next post: Defining a typed Drizzle schema.

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

Developing a Tailored Config Module for NestJS Applications

Ruben Alvarado — Thu, 19 Feb 2026 00:23:08 +0000

Have you ever struggled with more environment variables than actual features? DATABASE_URL, SUPABASE_URL, JWT_SECRET, a couple of flags for local vs production, and maybe some “temporary” variables you promise you’ll clean up later.

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!

💡 Next post: Connecting Supabase Postgres to NestJS using Drizzle and our Config Module.

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

An Easy Recap of Supabase Essentials

Ruben Alvarado — Mon, 09 Feb 2026 19:30:40 +0000

Picture this: you're building your next project, and you know you need authentication, a database, and maybe storage. You could spend days configuring Postgres, setting up auth from scratch, and managing deployment—or you could have it all running in under 5 minutes.

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

💡
For this series: We're using the connection string for our NestJS backend. But if you later want to add a React frontend that reads data directly from Supabase, you'd use the publishable key there. Different tools for different 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.

💡
I'll cover that in the next post. We'll wire up the connection string, configure Drizzle, and get ready to start building our Finance API.

See you there! 🚀

Bootstrapping a NestJS API for Personal Finance

Ruben Alvarado — Tue, 03 Feb 2026 01:41:28 +0000

The majority of NestJS tutorials available online tend to stop at basic CRUD operations or simple TODO list applications. Let's move beyond these beginner examples and build something real and practical that you can actually use in production.

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]

💡 Next post: We'll set up Supabase

A Guide to Fibonacci Series and Recursion in Go Language

Ruben Alvarado — Tue, 27 Jan 2026 00:37:15 +0000

The Fibonacci sequence is one of the most common problems you'll solve throughout your software career. Its implementation can be as simple or complex as you want.

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:

F(4) calls F(3) and F(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`

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`

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!

Efficiently Reverse Arrays In-Place in Go Language

Ruben Alvarado — Mon, 19 Jan 2026 16:21:29 +0000

If you are preparing for technical interviews, sooner or later someone will ask you to reverse an array. At first glance it looks trivial, but it quietly tests how well you understand indexing, boundaries, and memory.

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!

Easy Steps to Generate a Config Module in NestJS

Ruben Alvarado — Tue, 02 Dec 2025 18:09:23 +0000

When I started with NestJS, I didn't understand modules, interceptors, guards, and other advanced techniques the framework offers. As a result, I built insecure applications with poor practices. Over time, I learned the hard way which patterns truly matter for production-grade applications.

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!

Learn Array Chunking in Go: A Comprehensive Algorithm Approach

Ruben Alvarado — Tue, 25 Nov 2025 00:20:34 +0000

Throughout my career, I've encountered array chunking in everything from pagination systems to batch processing jobs. What seems simple at first glance hides tricky edge cases that can silently corrupt your data—like out-of-bounds errors or inconsistent chunk sizes.

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.

Photo by American Heritage Chocolate on Unsplash

Step-by-Step: Implementing Custom Decorators in NestJs Using Class-Validator and Drizzle

Ruben Alvarado — Tue, 18 Nov 2025 00:40:53 +0000

When building APIs, you must validate your inputs and outputs. If your API accepts any data, failure is only a matter of time. Instead of adding more ifs, use declarative validation: NestJS + class-validator + class-transformer, an async constraint that queries your DB, and a custom decorator integrated with the container. Result: errors stopped before the service layer and reusable rules across all your DTOs, with less duplicated logic.

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!

Learn to Capitalize the First Letter of Each Word with Go

Ruben Alvarado — Tue, 04 Nov 2025 00:12:05 +0000

Hey, there! Golang enthusiastics. I hope you are putting effort in the Golang journey. This week we are improving the learning by using Go’s internal packages. We are using string package.

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!

Photo by Algebra Digital on Unsplash

Why Your Side Project Remains Unfinished: Burnout Explained

Ruben Alvarado — Mon, 27 Oct 2025 23:27:56 +0000

Photo by Eden Constantino on Unsplash

We all been there—you have this revolutionary idea for a side project or startup. You start writing code, create your repo, and set up your architecture. You spend hours searching for the most cutting-edge technologies. Two or three days pass and your initial rush of energy starts to fade. Then you start to procrastinate. You get distracted. The three hours you dedicated per day become one, until suddenly they drop to zero. And you abandon the project.

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.

Cracking Blackjack with Go: A Step-by-Step Guide to Your First Move

Ruben Alvarado — Mon, 13 Oct 2025 15:42:32 +0000

Hey there, Go enthusiasts! How's the roadmap to that desired job going? Today we're covering an interesting exercise I found on exercism.

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:

Card	Value
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
other	0

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!