DEV Community: Geampiere Jaramillo

Design Patterns in Java:

Geampiere Jaramillo — Thu, 28 May 2026 15:02:20 +0000

Design patterns are reusable solutions to common software development problems. In Java, mastering these patterns is essential for building maintainable, scalable, and extensible applications.

In this blog, you will learn what design patterns are, their main categories, and practical examples applied in Java.

What Are Design Patterns?

Design patterns are proven solutions that help solve recurring software development problems.

They are not ready-to-copy code, but rather guidelines and structures that help developers write cleaner and more maintainable software.

Main Benefits

Reusable code
Low coupling
Better maintainability
Improved organization
Scalability
Clearer communication between developers

Design Pattern Categories

Design patterns are divided into three major categories:

1. Creational
2. Structural
3. Behavioral

1. Creational Patterns

Creational patterns focus on object creation.

Their goal is to abstract and control how classes are instantiated.

Singleton

The Singleton pattern ensures that only one instance of a class exists.

Java Example

public class DatabaseConnection {

    private static DatabaseConnection instance;

    private DatabaseConnection() {}

    public static DatabaseConnection getInstance() {
        if (instance == null) {
            instance = new DatabaseConnection();
        }
        return instance;
    }
}

Use Cases

Global configurations
Shared connections
Cache systems
Logging

Advantages

Full control over the instance
Reduced memory usage

Disadvantages

Can make testing harder
Risk of high coupling

Factory Method

The Factory Method pattern delegates object creation to a factory.

Example

interface Notification {
    void send();
}

class EmailNotification implements Notification {
    public void send() {
        System.out.println("Sending email");
    }
}

class SmsNotification implements Notification {
    public void send() {
        System.out.println("Sending SMS");
    }
}

class NotificationFactory {

    public static Notification create(String type) {
        if (type.equals("email")) {
            return new EmailNotification();
        }

        return new SmsNotification();
    }
}

Advantages

Reduces coupling
Easier extensibility
Better maintainability

Use Cases

APIs
Integrations
Systems with multiple implementations

Builder

Builder allows complex objects to be created step by step.

Example

public class User {

    private String name;
    private String email;
    private int age;

    public static class Builder {

        private String name;
        private String email;
        private int age;

        public Builder name(String name) {
            this.name = name;
            return this;
        }

        public Builder email(String email) {
            this.email = email;
            return this;
        }

        public Builder age(int age) {
            this.age = age;
            return this;
        }

        public User build() {
            User user = new User();
            user.name = this.name;
            user.email = this.email;
            user.age = this.age;
            return user;
        }
    }
}

Advantages

More readable objects
Avoids massive constructors
Easier immutability

Commonly Used In

Spring Boot
Lombok
Modern APIs

2. Structural Patterns

Structural patterns help organize classes and objects into more flexible structures.

Adapter

Adapter allows incompatible interfaces to work together.

Example

interface PaymentProcessor {
    void pay();
}

class PaypalService {
    public void makePayment() {
        System.out.println("Payment with PayPal");
    }
}

class PaypalAdapter implements PaymentProcessor {

    private PaypalService service;

    public PaypalAdapter(PaypalService service) {
        this.service = service;
    }

    @Override
    public void pay() {
        service.makePayment();
    }
}

Use Cases

External integrations
Legacy APIs
Microservices

Decorator

Decorator dynamically adds functionality to an object.

Example

interface Coffee {
    String description();
}

class BasicCoffee implements Coffee {
    public String description() {
        return "Basic coffee";
    }
}

class MilkDecorator implements Coffee {

    private Coffee coffee;

    public MilkDecorator(Coffee coffee) {
        this.coffee = coffee;
    }

    public String description() {
        return coffee.description() + " + milk";
    }
}

Advantages

Flexible
Avoids excessive inheritance
Easy extensibility

Facade

Facade provides a simplified interface for complex systems.

Example

class PaymentService {
    void processPayment() {}
}

class NotificationService {
    void sendEmail() {}
}

class OrderFacade {

    private PaymentService payment = new PaymentService();
    private NotificationService notification = new NotificationService();

    public void completeOrder() {
        payment.processPayment();
        notification.sendEmail();
    }
}

Use Cases

Complex systems
Enterprise APIs
Microservices

3. Behavioral Patterns

These patterns focus on communication between objects.

Observer

Observer defines a one-to-many relationship between objects.

When one object changes, the others are automatically notified.

Example

interface Observer {
    void update(String message);
}

class UserObserver implements Observer {

    public void update(String message) {
        System.out.println(message);
    }
}

Use Cases

Events
Notifications
Kafka
RabbitMQ

Strategy

Strategy allows algorithms to be changed dynamically.

Example

interface PaymentStrategy {
    void pay();
}

class CreditCardPayment implements PaymentStrategy {
    public void pay() {
        System.out.println("Payment with credit card");
    }
}

class PaypalPayment implements PaymentStrategy {
    public void pay() {
        System.out.println("Payment with PayPal");
    }
}

Advantages

Flexible code
Easy extensibility
Low coupling

Command

Command encapsulates requests as objects.

Example

interface Command {
    void execute();
}

class SaveCommand implements Command {

    public void execute() {
        System.out.println("Saving information");
    }
}

Use Cases

Task queues
Event systems
CQRS

Most Common Patterns in Spring Boot

Spring Boot internally uses many design patterns.

Examples

Pattern	Usage in Spring
Singleton	Default Beans
Factory	BeanFactory
Proxy	Spring AOP
Observer	Spring Events
Strategy	Spring Security
Template Method	JdbcTemplate
Dependency Injection	Inversion of Control

Best Practices When Using Patterns

1. Avoid Overusing Patterns

Not everything requires a design pattern.

2. Prioritize Simplicity

The best solution is often the simplest one.

3. Apply SOLID Principles

Patterns work best when combined with SOLID principles.

4. Think About Maintainability

Patterns should help the development team.

Difference Between Architecture and Patterns

These concepts are often confused.

Architecture

Defines the overall system structure.

Examples:

Microservices
Monoliths
Hexagonal Architecture
Clean Architecture

Patterns

Solve specific problems inside the code.

Examples:

Singleton
Strategy
Factory
Observer

Which Patterns Should You Learn First?

If you are starting with Java, focus on:

Singleton
Factory
Builder
Strategy
Observer

These are the most commonly used patterns in real-world applications.

Conclusion

Design patterns are essential tools for every Java developer.

Mastering these patterns helps developers build cleaner, more flexible, and maintainable applications.

The most important thing is not memorizing patterns, but understanding when they truly provide value.

A good developer does not use patterns because they are trendy, but because they solve real problems in an elegant and sustainable way.

Java Architectures

Geampiere Jaramillo — Wed, 27 May 2026 15:37:06 +0000

Java remains one of the most widely used programming languages in enterprise development thanks to its stability, mature ecosystem, and ability to build scalable systems. However, choosing the right architecture is just as important as choosing the programming language itself.

In this blog, we will explore the most commonly used architectures in Java, their advantages, disadvantages, and when each one should be used.

What Is Software Architecture?

Software architecture defines how an application is organized, how its components communicate, and how important technical decisions are made.

A good architecture provides:

Scalability
Maintainability
Security
Easier testing
Simpler deployments
Clear separation of responsibilities

In the Java ecosystem, there are multiple architectural styles depending on the type of project.

1. Monolithic Architecture

Monolithic architecture is one of the most traditional approaches in Java.

In this model, the entire application is developed and deployed as a single unit.

Typical Structure

Java Application
 ├── Controllers
 ├── Services
 ├── Repositories
 ├── Entities
 └── Configurations

Common Technologies

Spring Boot
Spring MVC
Hibernate
JPA
Maven
Gradle

Advantages

Easy to start with
Lower operational complexity
Simpler for small teams
Single deployment process

Disadvantages

Difficult to scale large systems
High coupling
Riskier deployments
Slower builds over time

When to Use It

MVPs
Startups
Small internal systems
Small development teams

2. Layered Architecture

This is probably the most commonly used architecture in enterprise Java applications.

It divides the application into clearly defined layers.

Common Layers

Presentation Layer
        ↓
Business Layer
        ↓
Persistence Layer
        ↓
Database

Example with Spring Boot

@RestController
@RequestMapping("/users")
public class UserController {

    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    @GetMapping
    public List<User> getUsers() {
        return userService.findAll();
    }
}

Advantages

Well-organized code
Easier maintenance
Clear separation of responsibilities
Easy to learn

Disadvantages

Dependencies between layers
Can generate duplicated logic
Less flexible for highly complex systems

Use Cases

Banking systems
ERP platforms
Enterprise APIs
Traditional backends

3. Hexagonal Architecture (Ports and Adapters)

Hexagonal architecture aims to decouple business logic from external technologies.

It was introduced by Alistair Cockburn.

Main Idea

Business logic should remain independent from:

Databases
Frameworks
External APIs
User interfaces
Messaging systems

Structure

         Adapters
            ↓
Ports → Domain ← Ports
            ↑
         Adapters

Simplified Example

Port

public interface PaymentRepository {
    void save(Payment payment);
}

Domain

public class PaymentService {

    private final PaymentRepository repository;

    public PaymentService(PaymentRepository repository) {
        this.repository = repository;
    }

    public void process(Payment payment) {
        repository.save(payment);
    }
}

Adapter

@Repository
public class JpaPaymentRepository implements PaymentRepository {

    @Override
    public void save(Payment payment) {
        // JPA implementation
    }
}

Advantages

Highly testable
Low coupling
Framework-independent
Easier technology migration

Disadvantages

Higher initial complexity
More abstractions
Steeper learning curve

When to Use It

Complex systems
Microservices
Critical business domains
Financial applications

4. Clean Architecture

Clean Architecture was popularized by Robert C. Martin (Uncle Bob).

Its main goal is to protect the business domain.

Core Principle

Dependencies should always point inward.

Layers

Frameworks & Drivers
Interface Adapters
Use Cases
Entities

Use Case Example

public class CreateUserUseCase {

    private final UserRepository repository;

    public CreateUserUseCase(UserRepository repository) {
        this.repository = repository;
    }

    public void execute(User user) {
        repository.save(user);
    }
}

Advantages

Scalable
Easy to test
Maintainable codebase
Excellent separation of responsibilities

Disadvantages

Significant structure overhead
Overengineering for small projects
Requires experienced developers

Ideal For

Large enterprises
Critical systems
Long-term applications
Large teams

5. Microservices Architecture

Microservices architecture divides a system into multiple small and independent services.

Each service:

Has its own business logic
Can have its own database
Can be deployed independently
Can scale independently

Example

Auth Service
User Service
Payment Service
Notification Service

Common Java Technologies

Spring Boot
Spring Cloud
Kafka
RabbitMQ
Docker
Kubernetes
Eureka
OpenFeign

Advantages

Independent scalability
Independent deployments
Better resilience
Autonomous teams

Disadvantages

Distributed system complexity
Harder observability
Complex failure handling
Higher operational costs

When to Use Microservices

Large-scale systems
Many integrations
High traffic applications
Multiple development teams
Advanced scalability requirements

6. Event-Driven Architecture

In this architecture, services communicate through events.

Example

User completes payment
        ↓
Payment Service publishes event
        ↓
Notification Service consumes event
        ↓
Email sent

Common Technologies

Apache Kafka
RabbitMQ
AWS SQS
AWS SNS

Advantages

Loosely coupled systems
High scalability
Excellent performance
Asynchronous communication

Disadvantages

Complex debugging
Eventual consistency challenges
Requires advanced observability

Use Cases

Fintech platforms
E-commerce systems
Real-time systems
Notification systems

7. Serverless Architecture in Java

Java can also run in serverless environments.

In this model, the cloud provider manages the infrastructure.

Popular Services

AWS Lambda
Azure Functions
Google Cloud Functions

Advantages

Automatic scaling
Reduced infrastructure management
Pay-per-use pricing
Ideal for event processing

Disadvantages

Cold starts
Execution limitations
Harder debugging

Ideal Use Cases

Event processing
Automation tasks
Small APIs
Scheduled jobs

Architecture Comparison

Architecture	Complexity	Scalability	Maintainability	Best For
Monolithic	Low	Medium	Medium	MVPs
Layered	Low	Medium	High	Enterprise systems
Hexagonal	Medium	High	High	Complex systems
Clean Architecture	High	High	Very High	Large projects
Microservices	High	Very High	High	Distributed systems
Event-Driven	High	Very High	Medium	Real-time systems
Serverless	Medium	High	High	Automation and events

Which Architecture Should You Choose?

There is no perfect architecture for every scenario.

The best architecture depends on:

Project size
Number of users
Budget
Development timeline
Team experience
Scalability requirements

Practical Recommendation

If You Are Starting Out

Use:

Monolith
Layered architecture
Spring Boot

If the System Grows

Gradually migrate toward:

Hexagonal architecture
Clean Architecture
Microservices

If You Handle High Concurrency

Combine:

Microservices
Kafka
Event-driven systems
Kubernetes

Best Practices for Java Architectures

1. Apply SOLID Principles

SOLID principles help create maintainable systems.

2. Use Dependency Injection

Spring Framework simplifies decoupling.

3. Separate Domain from Infrastructure

Avoid mixing business logic with frameworks.

4. Implement Observability

Use:

Structured logs
Prometheus
Grafana
OpenTelemetry

5. Automate Deployments

Implement CI/CD using:

GitHub Actions
Jenkins
GitLab CI

Recommended Technologies to Learn

Backend

Spring Boot
Spring Security
Spring Cloud
Hibernate
JPA
Quarkus

Messaging

Kafka
RabbitMQ

DevOps

Docker
Kubernetes
Terraform
AWS

Testing

JUnit
Mockito
Testcontainers

Observability

Grafana
Prometheus
OpenTelemetry

Conclusion

Java provides an extremely powerful ecosystem for building modern and scalable applications.

Choosing the right architecture can make the difference between a system that is easy to maintain and one that becomes difficult to evolve.

For small projects, a well-structured monolith is often enough. For large enterprise systems, architectures such as Hexagonal Architecture, Clean Architecture, and Microservices provide significant advantages in scalability and maintainability.

The most important thing is not to follow trends blindly, but to understand the real business needs and build sustainable solutions.

React vs Next.js: Two tools, a different purpose

Geampiere Jaramillo — Sat, 16 May 2026 18:58:40 +0000

For a long time I used React for everything. It worked. Until it wasn't enough.

There were projects where React solved exactly what I needed. Dynamic interfaces, manageable state, reusable components. The workflow was comfortable and I knew it well.

But then came projects where those same patterns started generating friction. SEO was a constant headache. Load times weren't what they should be. The setup before writing any useful code kept feeling longer and longer.

When I started working with Next.js day to day, a lot of that friction simply disappeared. Not because Next.js is better — but because it answers questions React never set out to answer.

What is each one?

React

React is a JavaScript library for building user interfaces. It's not a complete framework — it's just the view layer. It gives you components, a state system, and rendering. Everything else — routing, data fetching, optimization, folder structure — is up to you.

That flexibility is its greatest strength. And also its biggest trap.

Next.js

Next.js is a framework built on top of React. It takes React as its foundation and adds everything it's missing: file-based routing, server-side rendering, static generation, image optimization, API routes, and much more.

It doesn't replace React — it extends it. Everything you know about React works in Next.js.

The differences you feel most day to day

Routing

With plain React you need to install and configure React Router manually:

// React — manual route configuration
import { BrowserRouter, Routes, Route } from 'react-router-dom';

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
        <Route path="/blog/:id" element={<BlogPost />} />
      </Routes>
    </BrowserRouter>
  );
}

With Next.js you simply create files inside the app/ or pages/ folder and the routes exist automatically:

app/
├── page.tsx          →  /
├── about/
│   └── page.tsx      →  /about
└── blog/
    └── [id]/
        └── page.tsx  →  /blog/:id

No configuration. No extra imports. The file system is the router.

Rendering

This is the most important difference for real applications.

React (CSR — Client Side Rendering):
The server sends a nearly empty HTML. The browser downloads the JavaScript, executes it, and only then renders the interface. The user sees a blank screen in the meantime.

// React — data loads on the client
function BlogPost({ id }) {
  const [post, setPost] = useState(null);

  useEffect(() => {
    fetch(`/api/posts/${id}`)
      .then(res => res.json())
      .then(data => setPost(data));
  }, [id]);

  if (!post) return <div>Loading...</div>;
  return <article>{post.content}</article>;
}

Next.js (SSR / SSG):
The server generates the complete HTML before sending it to the browser. The user sees real content from the very first moment.

// Next.js — data is fetched on the server
async function BlogPost({ params }: { params: { id: string } }) {
  const post = await fetch(`https://api.example.com/posts/${params.id}`);
  const data = await post.json();

  return <article>{data.content}</article>;
}

No loading state. No blank screen. No useEffect for data that should have been there from the start.

SEO

This is critical for any project that needs to be found on Google.

With plain React, search engines receive an empty HTML and have to wait for JavaScript to execute before they can see any content. Many crawlers don't wait — they simply index an empty page.

With Next.js, the complete HTML reaches the crawler on the first request. The content is there, ready to be indexed.

// Next.js — SEO metadata directly in the component
export const metadata = {
  title: 'My Article | Blog',
  description: 'A clear description for search engines',
  openGraph: {
    title: 'My Article',
    images: ['/og-image.jpg'],
  },
};

Head-to-head comparison

Criteria	React	Next.js
Type	UI Library	Full-stack framework
Routing	Manual (React Router)	Automatic (file-based)
Rendering	Client only (CSR)	CSR, SSR, SSG, ISR
SEO	Hard without extra setup	Native and optimized
API Routes	Not included	Included
Image optimization	Manual	Automatic with `<Image>`
Learning curve	Low	Medium (requires knowing React first)
Structure flexibility	Total	Opinionated
Best for	SPAs, internal dashboards	Public sites, e-commerce, blogs, apps

Next.js rendering modes

One of the reasons Next.js stands out is that it doesn't force you to pick a single rendering mode. You can mix them within the same project depending on what each page needs.

SSG — Static Site Generation
HTML is generated at build time. Ideal for content that doesn't change often: blogs, landings, documentation.

// This page is generated once at build time
async function BlogIndex() {
  const posts = await getPosts();
  return <PostList posts={posts} />;
}

SSR — Server Side Rendering
HTML is generated on every request. Ideal for personalized or constantly changing content.

// This page is regenerated on every visit
async function Dashboard() {
  const data = await getUserDashboard();
  return <DashboardView data={data} />;
}

ISR — Incremental Static Regeneration
The perfect mix: generated statically but revalidated at intervals.

// Revalidates every 60 seconds in the background
export const revalidate = 60;

async function ProductPage({ params }) {
  const product = await getProduct(params.id);
  return <ProductView product={product} />;
}

When to use plain React

React without Next.js is still the right choice in several scenarios:

Internal dashboards that don't need SEO and have authenticated users
Single page applications where content is completely dynamic
Projects where a separate backend already exists and you only need the UI layer
Teams that want full control over every architectural decision
Quick prototypes where minimal setup is the priority

When to use Next.js

Next.js is the best option when:

The project needs real SEO — blogs, e-commerce, marketing pages
You want better performance from the very first render
You need API routes without setting up a separate server
The project includes both public pages and authenticated areas
You want image, font, and script optimization without manual work
You're building something that will grow and you need a solid foundation

What nobody tells you

Next.js has a real learning curve. The App Router, Server Components, the difference between 'use client' and 'use server', hydration, nested layouts — these are concepts that take time to fully understand.

Going straight to Next.js without a solid React foundation can be confusing. Order matters:

1. Understand React → components, props, state, hooks
2. Build something real with plain React
3. Hit its limitations (SEO, performance, routing)
4. Then Next.js will make complete sense

It's not that one is better than the other in absolute terms. It's that Next.js solves problems that plain React doesn't address by design.

Conclusion

React and Next.js are not rivals. Next.js is React with specific superpowers: server-side rendering, automatic routing, native SEO, and an architecture built for production from day one.

If you're building an internal SPA or a prototype, plain React is enough. If you're building something public that needs to load fast, rank in search engines, and scale — Next.js is the right call.

The question isn't which one is better. The question is what problem are you solving.

"React gives you the pieces. Next.js gives you the board where they fit."

Are you using React, Next.js, or both in your projects? I'd love to read your experience in the comments.

Vibe Coding: What It Is and How It's Changing Development

Geampiere Jaramillo — Fri, 15 May 2026 20:30:18 +0000

Before I made it part of my daily workflow, I thought it was just another trend. I was wrong.

For years I wrote code the traditional way: editor open, documentation in another tab, Stack Overflow in another. It worked, but it was slow. Every new feature meant hours of setup, searching, trial and error.

Then I started experimenting with Vibe Coding and my workflow changed completely.

Andrej Karpathy — one of the co-founders of OpenAI — was the one who gave this a name with a tweet that sparked debate across the entire tech community:

"There's a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

At first I read it with skepticism. Today it's part of how I work every single day.

What is Vibe Coding?

Vibe Coding is a way of programming where you describe what you want in natural language — as if you were talking to a person — and an AI generates the code for you.

You don't write for loops. You don't memorize syntax. You don't spend hours debugging a missing semicolon.

You say: "I want a web page that shows a task list, where I can add and delete items, and that looks modern."

And the AI builds it.

Tools like Cursor, Claude Code, Higgsfield, and OpenCode make this possible right now.

Why does this matter?

Traditionally, learning to code meant:

Learning the syntax of a language
Understanding data structures and algorithms
Months or years of practice before building something "real"

Vibe Coding changes that order. Now you can:

Build something real from day one
Learn the theory while reading the generated code
Iterate fast and see immediate results

It doesn't replace learning to code — but it does lower the entry barrier to almost zero.

How does it work in practice?

Say you want to build a simple app to track your personal expenses. Here's what the process looks like:

Without Vibe Coding (traditional way)

Week 1-2: Learn basic HTML and CSS
Week 3-4: Learn JavaScript
Week 5-6: Learn DOM manipulation
Week 7:   Finally build something functional

With Vibe Coding

Day 1: Describe your idea to the AI
        → "Build an expense tracker app with categories,
           totals, and a clean design"

        The AI generates the complete code.
        You review it, ask what each part does,
        request changes, learn along the way.

The tools shaping the ecosystem

There are several tools being used today for Vibe Coding oriented toward web pages and apps. Each one approaches the problem from a different angle.

1. Cursor

A code editor with deeply integrated AI. It runs on top of VS Code, so the environment feels familiar. It lets you interact with code in natural language — ask questions, request changes, understand specific sections — without leaving the editor.

2. Claude Code

An agent that operates from the terminal. It reads the full project context — files, dependencies, structure — and generates or modifies code accordingly. Primarily used in projects where coherence across different parts of the codebase matters.

3. Higgsfield

Focused on generating visual interfaces. From a description, it produces components and layouts ready to integrate. Widely used for the design and layout phase of web pages and apps.

4. OpenCode

An open source code agent that runs in the terminal. Unlike the other options, it's configurable and lets you connect to different AI models. An alternative for those who prefer more control over the tools they use.

What Vibe Coding is NOT

Here's the honest part most articles skip.

It's not magic. AI makes mistakes. Sometimes it generates code that doesn't work, has bugs, or doesn't do exactly what you asked. You need to learn to identify those errors.

It doesn't replace understanding the basics. The more you know about programming, the better instructions you'll give the AI and the better you'll be able to evaluate what it generates. The best Vibe Coding users are experienced developers, not people who have never touched code.

It doesn't work for everything. Complex systems, high-security code, performance optimizations — the AI has clear limits there.

The perfect analogy: Vibe Coding is like having a GPS. It gets you from point A to point B without knowing every street. But if the GPS fails, if there's an unexpected detour, you need to understand at least the basics of navigation to not get lost.

The ideal workflow

1. Describe clearly what you want

The more specific you are, the better the result.

❌ "Make me an app"
✅ "Build a web app with React that has a task list. Each task should have a checkbox to mark it as completed and a button to delete it. Use a minimalist design with a white background."

2. Read the code the AI generates

Don't copy and paste without reading. Ask the AI to explain each part. That's where the real learning happens.

3. Request incremental changes

Don't try to build everything at once. Go piece by piece.

4. Break things on purpose

Modify the generated code, experiment, see what happens. Errors are your best teacher.

5. Learn the theory in parallel

Use platforms like freeCodeCamp, The Odin Project, or roadmap.sh to understand the concepts behind the code you're seeing.

Will Vibe Coding replace developers?

Short answer: no.

Long answer: it will radically change what kind of developers are most valuable.

Developers who know how to use AI as an amplification tool — who can provide precise context, evaluate the output, catch errors, and make architectural decisions — are going to be more productive than ever.

Those who ignore these tools will fall behind.

The message is clear: learn to code AND learn to use AI. They're not opposing paths — they're complementary.

Where to start

If you want to take your first step with Vibe Coding this week, here's a concrete plan:

Pick one of the tools mentioned and install it or open it in your browser
Describe a simple app you'd like to have — a task list, a habit tracker, a tip calculator
Read the generated code and ask the AI to explain the parts you don't understand
Request a change — change a color, add a new feature, modify some text
Repeat with something slightly more complex each time

The goal isn't to understand everything from the start. The goal is to start building and learn in the process.

Conclusion

Vibe Coding isn't the future — it's the present. It represents a genuine shift in how software gets built: faster, more accessible, and increasingly driven by intent rather than syntax.

Use it as a launching pad, not a crutch. Build, ask questions, learn, break things. That curiosity is what separates a developer who grows from one who stagnates.

"The best way to learn to code has always been by building things. Vibe Coding just makes that first step a lot smaller."

Have you tried any Vibe Coding tools? What was your experience? Tell me in the comments.

Modular Monolith vs Microservices in NestJS

Geampiere Jaramillo — Fri, 15 May 2026 02:52:55 +0000

NestJS was deliberately designed so you can start simple and grow without rewriting. Here's how to take full advantage of that.

When you start a new backend project, one of the first debates that comes up is: monolith or microservices?

What are we actually talking about?

Before comparing, let's align on definitions:

Modular Monolith: a single application deployed as one unit, but with code organized into modules with clear boundaries. One module per business domain.
Microservices: multiple independent applications that communicate over the network (HTTP, messaging, gRPC). Each service is deployed, scaled, and updated autonomously.

The most common misconception is thinking "monolith" means "messy code." It doesn't. A monolith can be perfectly structured — and in NestJS, that's the norm, not the exception.

Modular Monolith with NestJS

NestJS was built for the modular monolith. Its module system forces you to think in terms of domains from day one.

Typical folder structure

src/
├── app.module.ts
├── users/
│   ├── users.module.ts
│   ├── users.controller.ts
│   ├── users.service.ts
│   └── entities/user.entity.ts
├── orders/
│   ├── orders.module.ts
│   ├── orders.controller.ts
│   ├── orders.service.ts
│   └── entities/order.entity.ts
└── payments/
    ├── payments.module.ts
    ├── payments.service.ts
    └── dto/payment.dto.ts

Each domain lives in its own module with its controllers, services, and entities. Communication between modules happens through dependency injection — no network involved.

Inter-module communication

// orders.module.ts — imports UsersModule to use its service
@Module({
  imports: [UsersModule],
  controllers: [OrdersController],
  providers: [OrdersService],
})
export class OrdersModule {}

// orders.service.ts
@Injectable()
export class OrdersService {
  constructor(
    private readonly usersService: UsersService,
  ) {}

  async createOrder(userId: string, items: OrderItem[]) {
    // Direct in-memory call — no network latency
    const user = await this.usersService.findOne(userId);
    if (!user) throw new NotFoundException('User not found');
    // ... business logic
  }
}

The call to usersService.findOne() is an in-memory function call. No serialization, no latency, no network failure points.

Pros and cons

✅ Advantages:

Fast initial development, single repository
Simple local debugging — one process, one log
Zero latency between modules
Native database transactions (no Saga needed)
Single CI/CD pipeline

⚠️ Disadvantages:

Scales as a whole unit (you can't scale just the payments module)
Slower builds and deploys as it grows
An uncaught failure can bring down the entire process

Microservices with NestJS

NestJS has first-class support for microservices through @nestjs/microservices, supporting TCP, Redis, RabbitMQ, Kafka, gRPC, NATS, and more.

General architecture

                  ┌─────────────────┐
                  │   API Gateway   │
                  └────────┬────────┘
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
   ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
   │users-service │ │orders-service│ │payments-svc  │
   │   :3001      │ │   :3002      │ │   :3003      │
   └──────────────┘ └──────────────┘ └──────────────┘
           │               │               │
           └───────────────┴───────────────┘
                           │
                  ┌────────▼────────┐
                  │  RabbitMQ/Kafka │
                  └─────────────────┘

Setting up a microservice

// users-service/main.ts
import { NestFactory } from '@nestjs/core';
import { Transport, MicroserviceOptions } from '@nestjs/microservices';

async function bootstrap() {
  const app = await NestFactory.createMicroservice<MicroserviceOptions>(
    AppModule,
    {
      transport: Transport.RMQ,
      options: {
        urls: ['amqp://localhost:5672'],
        queue: 'users_queue',
        queueOptions: { durable: false },
      },
    },
  );
  await app.listen();
}
bootstrap();

Inter-service communication

// orders-service: calls users-service via MessagePattern
@Injectable()
export class OrdersService implements OnModuleInit {
  private usersClient: ClientProxy;

  onModuleInit() {
    this.usersClient = this.clientProxy.get('USERS_SERVICE');
  }

  async createOrder(userId: string) {
    // Async call to the users microservice
    const user = await firstValueFrom(
      this.usersClient.send({ cmd: 'get_user' }, { userId }),
    );
    // ... continue with the order
  }
}

// users-service: exposes the MessagePattern
@Controller()
export class UsersController {
  @MessagePattern({ cmd: 'get_user' })
  getUser(data: { userId: string }) {
    return this.usersService.findOne(data.userId);
  }
}

Pros and cons

✅ Advantages:

Independent scaling per service
Independent deployment — the payments team deploys without coordinating with users
Fault isolation
Autonomous, parallel teams

⚠️ Disadvantages:

High operational complexity (orchestration, service discovery, distributed observability)
Network latency between services
Complex distributed transactions — you need the Saga pattern
Infrastructure overhead: Kubernetes, message brokers, tracing

Head-to-head comparison

Criteria	Modular Monolith	Microservices
Initial development speed	✅ High	❌ Low
Independent scaling	❌ All or nothing	✅ Per service
Internal latency	✅ Zero (in-memory)	❌ Network + serialization
ACID transactions	✅ Native	❌ Saga / 2PC required
Local testing	✅ Simple	⚠️ Requires orchestration
Learning curve	✅ Low	❌ High
Fault isolation	❌ One crash affects everything	✅ Contained failures
Observability	✅ Single log stream	❌ Requires distributed tracing
Ideal for small teams	✅ Yes	❌ Not recommended

When to use each one?

Choose a modular monolith if…

The team has fewer than 10 engineers
The business domain is still evolving (you don't know the boundaries yet)
You need to ship fast — MVP, startup, market validation
You don't have a dedicated DevOps/SRE team
Modules share a lot of data with each other
Infrastructure costs are a real constraint

Choose microservices if…

The system has been in production for a while and domain boundaries are very clear
Different teams need to deploy without coordinating with each other
Some components have radically different scaling demands
You have compliance requirements that require data isolation
You have a dedicated DevOps/SRE team with distributed systems experience

Classic antipattern — Distributed Monolith: starting with microservices without knowing the domain boundaries results in services that call each other synchronously for every operation, distributed transactions that can't fail, and deployments that must be coordinated just like in a monolith. The worst of both worlds. Martin Fowler documents this extensively.

Migration strategy: from monolith to microservice

NestJS's biggest advantage is that the same modular structure you use in the monolith is the foundation for extracting microservices. The safest strategy is the Strangler Fig pattern: you extract modules incrementally without stopping the system.

Step 1 — Start with a well-modularized monolith

// app.module.ts
@Module({
  imports: [
    UsersModule,
    OrdersModule,
    PaymentsModule,
  ],
})
export class AppModule {}

Step 2 — Abstract communication with interfaces

The key is that service consumers shouldn't know whether they're talking to a local or remote implementation.

// Transport-agnostic interface
export interface IUsersService {
  findOne(id: string): Promise<User>;
  create(dto: CreateUserDto): Promise<User>;
}

// Local implementation (monolith)
@Injectable()
export class UsersService implements IUsersService { ... }

// Remote implementation (microservice) — same contract
@Injectable()
export class UsersClientService implements IUsersService {
  findOne(id: string) {
    return firstValueFrom(
      this.client.send({ cmd: 'get_user' }, { id }),
    );
  }
}

Step 3 — Swap in the module without touching consumers

@Module({
  providers: [
    {
      provide: 'IUsersService',
      // Monolith:  useClass: UsersService
      useClass: UsersClientService, // ← now it's a microservice
    },
  ],
})
export class OrdersModule {}

OrdersService keeps injecting IUsersService without changing a single line. You only change the provider in the module.

With this pattern you can extract services gradually, validate in production, and roll back if something goes wrong — no big bang migration needed.

Conclusion

There is no universally superior architecture. The right question isn't "microservices or monolith?" but "what architecture solves the problems I have today?"

The modular monolith is the right choice for most projects in their early stages. It lets you move fast, maintain coherence, and reduce the team's cognitive load.

Microservices are a solution to specific organizational and scaling problems — not a goal in themselves. Introduce that complexity only when the pain of not having it outweighs the cost of operating it.

And NestJS, with its modular architecture, native support for multiple transports, and the abstraction pattern shown here, gives you the luxury of starting simple and evolving without rewriting. That's its greatest advantage.

Golden rule: "Start with the cleanest modular monolith you can build. Your future microservices are already defined in your modules."

Have you migrated from a monolith to microservices in NestJS? I'd love to read your story in the comments.

SQL vs NoSQL: Which one to choose for your next project?

Geampiere Jaramillo — Thu, 16 Apr 2026 14:56:25 +0000

When it comes to databases, two of the most popular options are SQL (Structured Query Language) and NoSQL (Not Only SQL). Both have advantages and disadvantages, and the choice between them depends on the specific needs of your application. In this blog, we'll explore the key differences between SQL and NoSQL databases, their use cases, and how to choose the right one for your project.

What is SQL?

SQL (Structured Query Language) refers to relational databases that organize data into related tables. SQL databases are highly structured, meaning that each piece of data must follow a predefined schema with clear relationships between tables. SQL databases are known for their ability to handle complex transactions and advanced queries.

Examples of SQL databases:

MySQL
PostgreSQL
SQL Server
SQLite

Main features of SQL:

Relational Model: Data is organized into tables with rows and columns. Each table can have relationships with other tables, and data can be retrieved using SQL queries.
Fixed Schema: The database schema must be defined before data is inserted, and tables must follow a predictable structure.
ACID: SQL offers ACID transactions (Atomicity, Consistency, Isolation, Durability), meaning that database operations are safe and reliable.
Complex Queries: SQL databases allow for complex queries using joins, subqueries, aggregations, and other operations.

SQL Use Cases:

Enterprise applications requiring high consistency and transactions.
Banking systems where data integrity is crucial.
Management applications that require complex relationships between data (e.g., inventory management systems, ERPs).
Applications that require regulatory compliance (such as GDPR, HIPAA) and need to maintain data integrity and control.

What is NoSQL?

NoSQL (Not Only SQL) refers to non-relational databases that offer greater flexibility in data storage and querying. Unlike SQL databases, NoSQL does not use a rigid schema or relationships between tables. Instead, it focuses on storing data in documents, key-value pairs, columns, or graphs.

Examples of NoSQL databases:

MongoDB (document-oriented)
Redis (key-value)
Cassandra (column-based)
Neo4j (graph-based)

Main features of NoSQL:

Flexible Data Model: NoSQL allows for the storage of unstructured or semi-structured data. Documents can have different fields without adhering to a fixed schema.
Horizontal Scalability: NoSQL databases are designed to scale horizontally, meaning they can be distributed across multiple servers to handle large volumes of data.
High Availability: NoSQL often employs replication and partitioning techniques to ensure data is available even when some nodes fail.
Eventual Consistency: Instead of guaranteeing strong consistency like SQL databases, NoSQL typically opts for eventual consistency, meaning that data may not be fully synchronized across all database nodes at any given time.

NoSQL Use Cases:

Real-time web applications, such as instant messaging or push notifications.
Big Data and real-time analytics of large volumes of unstructured data (e.g., logs, IoT sensors).
Social networks and content platforms that require scalability and flexibility in data storage.
Distributed and high-availability systems that need rapid failure recovery.

Diferencias clave entre SQL y NoSQL

When to choose SQL?

You should choose an SQL database when your application:

Requires data integrity and ACID-compliant transactions (e.g., financial or banking systems).
Has a well-defined data structure with clear relationships between entities (users, products, orders).
Requires complex queries involving multiple tables with relationships (joins, subqueries, etc.).
Doesn't need massive horizontal scalability, but rather vertical scalability (increasing the resources of a single server).

When to choose NoSQL?

You should choose a NoSQL database when your application:

Handles large volumes of unstructured or semi-structured data, such as logs, IoT sensor data, or multimedia content.
Requires high horizontal scalability, as NoSQL databases are designed to be distributed and handle large amounts of traffic and data.
Requires high availability and fast recovery from failures (ideal for distributed applications with large numbers of concurrent users).
Handle changing data without requiring a rigid schema or predefined structure.

Conclusion

The choice between SQL and NoSQL largely depends on the specific needs of your application. If your project requires complex transactions, data integrity, and well-defined relationships, SQL is the best option. On the other hand, if your application needs to handle large volumes of data with a flexible schema and requires horizontal scalability, NoSQL may be more suitable.

There is no one-size-fits-all answer; some applications can even benefit from a hybrid approach, using both technologies depending on the requirements of each part of the system. For example, you could use an SQL database to handle financial transactions and a NoSQL database to store logs or real-time data.

By understanding the strengths and limitations of both options, you can make a more informed decision about which type of database to use for your project.

SOLID Principles in NestJS

Geampiere Jaramillo — Wed, 28 May 2025 15:12:09 +0000

When building software, keeping your code organized and scalable is key. SOLID is a set of principles that help improve code quality. In this blog, we’ll explore how to apply SOLID in NestJS to write clean, maintainable, and extendable code.

1. Single Responsibility Principle (SRP)

Every class should have one responsibility. This makes your code easier to understand and modify.

Example in NestJS:

@Injectable()
export class UserService {
  constructor(private readonly userRepository: UserRepository) {}

  createUser(data: CreateUserDto) {
    this.userRepository.save(data); // Responsible only for user logic
  }
}

Here, UserService only handles user logic. Validation and other concerns should be separated.

2. Open/Closed Principle (OCP)

Classes should be open for extension, but closed for modification. You can add new features without changing existing code.

Example in NestJS:

interface PaymentStrategy {
  processPayment(amount: number): void;
}

class CreditCardPayment implements PaymentStrategy {
  processPayment(amount: number) {
    console.log(`Processing $${amount} via Credit Card`);
  }
}

@Injectable()
export class PaymentService {
  constructor(private paymentStrategy: PaymentStrategy) {}

  executePayment(amount: number) {
    this.paymentStrategy.processPayment(amount);
  }
}

You can add more payment methods by extending PaymentStrategy without changing PaymentService.

3. Liskov Substitution Principle (LSP)

Derived classes should be substitutable for their base classes without breaking the application.

Example in NestJS:

class Animal {
  makeSound() {}
}

class Dog extends Animal {
  makeSound() {
    console.log('Bark');
  }
}

You can use a Dog wherever an Animal is expected, without issues.

Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they don’t use. Split large interfaces into smaller, specific ones.

Example in NestJS:

interface PaymentProcessor {
  processPayment(amount: number): void;
}

class CreditCardProcessor implements PaymentProcessor {
  processPayment(amount: number) {
    console.log(`Processing $${amount} via Credit Card`);
  }
}

class PaypalProcessor implements PaymentProcessor {
  processPayment(amount: number) {
    console.log(`Processing $${amount} via PayPal`);
  }
}

Each class only implements what it needs, making the code cleaner and easier to manage.

5. Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Example in NestJS:

interface Logger {
  log(message: string): void;
}

@Injectable()
export class MyService {
  constructor(private readonly logger: Logger) {}

  executeAction() {
    this.logger.log('Action executed');
  }
}

Here, MyService depends on the Logger interface, not a specific implementation. This improves flexibility and testability.

Conclusion

Applying SOLID principles in NestJS helps you write clean, flexible, and maintainable code. These principles make it easier to test, scale, and evolve your applications without introducing bugs.

Design Patterns in NestJS

Geampiere Jaramillo — Tue, 27 May 2025 15:41:55 +0000

When developing backend applications with NestJS, one of the biggest challenges is creating an architecture that is scalable, maintainable, and extensible. One effective way to achieve this is by using design patterns, which allow us to build more flexible, decoupled, and reusable solutions.

We will explore the most common design patterns you can implement in your NestJS applications, such as Dependency Injection, Singleton, Decorators, Strategy, and others. You will learn how to apply these patterns to improve code quality and long-term maintainability.

1. Dependency Injection (DI)

Dependency Injection is one of the core principles of NestJS. This pattern allows classes to depend on other objects without creating them explicitly, which facilitates decoupling and component reusability.

How it works in NestJS:
NestJS uses TypeScript's dependency injection container. Whenever you inject a service into another via the constructor, NestJS handles the instantiation and passes the dependency.

@Injectable()
export class MyService {
  getHello(): string {
    return 'Hello, World!';
  }
}

@Controller()
export class MyController {
  constructor(private readonly myService: MyService) {}

  @Get()
  getHello(): string {
    return this.myService.getHello();
  }
}

Advantages:

Decoupling: Classes do not need to know the implementation of their dependencies.
Scalability: Easy to scale and maintain when adding new dependencies.
Testing: Enables mocking services during unit testing.

2. Singleton

The Singleton pattern ensures a class has only one instance and provides a global point of access. NestJS uses this by default for services.

@Injectable()
export class MySingletonService {
  private counter = 0;

  increment() {
    this.counter++;
    return this.counter;
  }

  getCounter() {
    return this.counter;
  }
}

Advantages:

Consistency: Maintains shared state throughout the application.
Resource Management: Ideal for managing resources like database connections.

3. Decorator Pattern

Decorators are fundamental in NestJS. They allow you to add functionality to classes and methods without modifying their structure.

@Controller('users')
export class UserController {
  @Get(':id')
  getUser(@Param('id') id: string): string {
    return `User ID: ${id}`;
  }
}

Advantages:

Readability: Decorators make code more readable and organized.
Flexibility: Adds functionality in a modular way.

4. Strategy Pattern

The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. It is useful when you need different behaviors for a service.

interface PaymentStrategy {
  pay(amount: number): string;
}

@Injectable()
export class CreditCardPayment implements PaymentStrategy {
  pay(amount: number): string {
    return `Paid ${amount} using Credit Card`;
  }
}

@Injectable()
export class PayPalPayment implements PaymentStrategy {
  pay(amount: number): string {
    return `Paid ${amount} using PayPal`;
  }
}

@Injectable()
export class PaymentService {
  constructor(private readonly paymentStrategy: PaymentStrategy) {}

  processPayment(amount: number): string {
    return this.paymentStrategy.pay(amount);
  }
}

Advantages:

Flexibility: Easily change system behavior without altering the structure.
Extensibility: New strategies can be added without affecting existing code.

5. Observer Pattern

The Observer pattern is useful when multiple objects need to be notified of changes in another object's state. In NestJS, this can be implemented using events.

@Injectable()
export class MyService {
  private eventEmitter = new EventEmitter();

  constructor() {
    this.eventEmitter.on('userCreated', (user) => {
      console.log('User Created:', user);
    });
  }

  createUser(user: any) {
    this.eventEmitter.emit('userCreated', user);
  }
}

Advantages:

Decoupling: Observers react to events without needing to know the subject's internal logic.
Scalability: Easy to add new functionalities by subscribing to events.

6. Command Pattern

The Command pattern encapsulates a request as an object, allowing you to parameterize clients with different requests.

class CreateUserCommand {
  constructor(public readonly username: string, public readonly email: string) {}
}

@Injectable()
export class UserService {
  executeCreateUserCommand(command: CreateUserCommand): void {
    console.log(`Creating user with username: ${command.username} and email: ${command.email}`);
  }
}

Advantages:

Decoupling: Separates the request from its execution.
Reusability: Commands can be reused in different parts of the app.

Conclusion

Design patterns are powerful tools for building scalable and maintainable backend applications. In NestJS, you can take full advantage of these patterns to structure your code in a modular, decoupled, and efficient way.

The key is to understand when and how to apply each pattern based on your project’s requirements. Start experimenting with them and see how your NestJS architecture improves.

Operators and Methods to Manipulate Arrays in JavaScript

Geampiere Jaramillo — Tue, 13 May 2025 15:29:44 +0000

When working with JavaScript—whether on the frontend with frameworks like React or on the backend with NestJS—one of the most common data structures is the array. Arrays allow us to store collections of data and offer a wide range of operators and methods to manipulate them efficiently.

In this article, we'll explore the main operators and methods you can use with arrays to transform, filter, combine, and analyze information.

📌 What Is an Array?

An array in JavaScript is an ordered collection of items. It can contain any type of data: numbers, strings, objects, or even other arrays.

const numbers = [1, 2, 3, 4, 5];
const mixed = [1, 'text', true, null, [6, 7]];

🧹 Useful Operators for Arrays

1. Spread Operator (...)

Allows cloning or combining arrays in a very readable way.

const a = [1, 2];
const b = [3, 4];
const combined = [...a, ...b]; // [1, 2, 3, 4]

2. Destructuring

Extracts individual elements from an array easily.

const [first, second] = [10, 20, 30]; // first = 10, second = 20

🔄 Common Methods to Manipulate Arrays

🔹 Mutation Methods (modify the original array)

Method	Description
`push()`	Adds elements to the end.
`pop()`	Removes the last element.
`shift()`	Removes the first element.
`unshift()`	Adds elements to the beginning.
`splice()`	Adds/removes elements at a position.
`sort()`	Sorts the array.
`reverse()`	Reverses the array order.

const fruits = ['apple', 'banana'];
fruits.push('orange'); // ['apple', 'banana', 'orange']
fruits.splice(1, 1, 'pear'); // ['apple', 'pear', 'orange']

🔹 Iteration & Transformation Methods

Method	Primary Use
`forEach()`	Executes a function for each element.
`map()`	Transforms elements and returns a new array.
`filter()`	Returns elements that meet a condition.
`reduce()`	Reduces array to a single value.
`find()`	Returns the first matching element.
`some()`	Checks if some elements match a condition.
`every()`	Checks if all elements match a condition.

const numbers = [1, 2, 3, 4, 5];

const doubled = numbers.map(n => n * 2); // [2, 4, 6, 8, 10]
const evens = numbers.filter(n => n % 2 === 0); // [2, 4]
const total = numbers.reduce((acc, n) => acc + n, 0); // 15

🔹 Search Methods

const letters = ['a', 'b', 'c'];
letters.includes('b');  // true
letters.indexOf('c');   // 2

🔹 Conversion Methods

const words = ['hello', 'world'];
words.join(' ');  // 'hello world'

🧠 Tip: Non-Destructive vs Destructive Methods

Non-destructive: map(), filter(), slice(), concat(), etc.
Destructive: push(), pop(), splice(), sort(), etc.

Prefer non-destructive methods when aiming for immutability—a key principle in functional programming and modern frameworks.

🔪 Bonus: Advanced Methods

flat() and flatMap()

const nested = [1, [2, 3], [4, 5]];
nested.flat(); // [1, 2, 3, 4, 5]

const duplicated = [1, 2, 3].flatMap(n => [n, n]); // [1, 1, 2, 2, 3, 3]

🚀 Conclusion

Mastering array manipulation is essential for any JavaScript developer. Whether you're building APIs with NestJS or transforming data in the frontend, understanding these operators and methods will help you write cleaner, more efficient code.

Do you have a favorite array method or a cool tip? Let me know in the comments!

Method Binding in NestJS: What It Is and When to Use It

Geampiere Jaramillo — Thu, 08 May 2025 15:03:34 +0000

In NestJS development—a Node.js framework focused on modular architecture and class-based design—one concept that can confuse developers is method binding. This blog post explains what it is, when it matters, and how to handle it properly.

What Is Method Binding?

In JavaScript and TypeScript, the value of this inside a method can change depending on how and where the method is called. Method binding refers to ensuring that this inside the method always points to the correct class instance, especially when the method is passed as a callback.

Classic Problem: Callback with `setInterval`


@Injectable()
export class MyService {
  private count = 0;

  increment() {
    this.count++;
    console.log('Count:', this.count);
  }

  start() {
    setInterval(this.increment, 1000); // 'this' is undefined here
  }
}

In this example, this.increment loses its class context when passed as a callback to setInterval, resulting in an error or unexpected behavior.

Common Solutions in NestJS

1. Use bind(this)

start() {
  setInterval(this.increment.bind(this), 1000);
}

bind ensures that this inside increment continues to refer to the MyService instance.

2. Use Arrow Functions

increment = () => {
  this.count++;
  console.log('Count:', this.count);
};

Arrow functions do not have their own this; they inherit it from their creation context, which avoids the problem without needing bind.

When You Need to Bind Methods

When passing methods as callbacks to async functions like setTimeout, setInterval, or event handlers.
When using methods in custom listeners.
When using methods as middleware or hooks where context is lost.

Best Practices

In services or controllers, consider using arrow functions to preserve this context.
Use bind(this) if you need to pass a method as a callback and prefer not to redefine it.
Avoid overusing arrow functions in classes if you rely on inheritance or unit testing that depends on traditional methods.

Conclusion

NestJS makes dependency and state management easy, but the behavior of this in JavaScript still needs attention. Understanding and properly applying method binding helps avoid subtle bugs and leads to cleaner, more maintainable code. Whether through bind(this) or arrow functions, choosing the right strategy depends on your application's context and design.

Mastering Functional Programming: Immutability, Composition, Pure and Arrow Functions

Geampiere Jaramillo — Wed, 07 May 2025 16:02:48 +0000

Functional programming has gained traction in modern development due to its ability to produce more predictable, modular, and testable code. In this post, we explore four fundamental principles: immutability, function composition, pure functions, and arrow functions.

🧊 Immutability: Protect Your State

Immutability means that once a value is created, it cannot be changed. Instead of mutating data, we return new versions with the desired updates.

✅ Why is it useful?

Prevents unpredictable side effects
Easier debugging and testing
Ideal for concurrent environments (like React or Redux)

❌ Mutable example:

const user = { name: 'Alice', age: 25 };
user.age = 26; // Mutation

✅ Immutable example:

const user = { name: 'Alice', age: 25 };
const updatedUser = { ...user, age: 26 }; // New copy with changes

🔁 Function Composition: Chain Your Logic

Function composition means combining small, reusable functions to build more complex logic.

const trim = str => str.trim();
const toUpper = str => str.toUpperCase();

const cleanAndCapitalize = str => toUpper(trim(str));

cleanAndCapitalize("  hello  "); // "HELLO"

Or dynamically compose using a helper:

const compose = (...fns) => x => fns.reduce((acc, fn) => fn(acc), x);

const cleanAndCapitalize = compose(trim, toUpper);

📌 Benefit: cleaner, modular, and easily testable code.

🦼 Pure Functions: No Surprises

A pure function follows two rules:

Always returns the same output for the same inputs
Has no side effects (doesn't modify external variables or interact with I/O)

✅ Pure function:

const add = (a, b) => a + b;

❌ Impure function:

let counter = 0;
const increment = () => ++counter;

Advantages:

Easier to test
Fewer hidden dependencies
Can be memoized or cached

🌽 Arrow Functions: Elegant and Contextual

Arrow functions (=>) offer a concise way to declare functions in JavaScript and TypeScript. They also don’t have their own this, making them perfect for callbacks.

✅ Simple example:

const double = n => n * 2;

🧠 Implicit return:

const sum = (a, b) => a + b;

🎯 this behavior:

function Timer() {
  this.seconds = 0;

  setInterval(() => {
    this.seconds++;
    console.log(this.seconds);
  }, 1000); // `this` works correctly
}

🧹 Conclusion

Adopting functional principles like immutability, composition, and pure functions (along with arrow functions) helps you write more declarative, maintainable, and robust code. These ideas are especially powerful in modern frameworks like React, NestJS, or Redux, where predictable data flow is crucial.

Test-Driven Development (TDD) and Domain-Driven Design (DDD): The Perfect Duo for Robust NestJS Applications

Geampiere Jaramillo — Tue, 06 May 2025 14:37:53 +0000

When working on complex applications, especially in the backend world, keeping domain clarity and code quality is a constant challenge. That's where DDD (Domain-Driven Design) and TDD (Test-Driven Development) shine as complementary approaches. In this article, I'll show you how to combine them in a project using NestJS with modern best practices.

🧠 What is DDD?

Domain-Driven Design is a software development philosophy that focuses on the business domain. Instead of forcing the domain to fit the code, we adapt the code to represent the domain.

Key components of DDD:

Entities: Objects with identity (e.g., a User).
Value Objects: Objects without identity, defined by their attributes (Email, Money).
Aggregates: Consistency boundaries grouping related entities.
Repositories: Abstractions for accessing aggregates.
Domain/Application Services.

🔀 What is TDD?

Test-Driven Development is a software development practice following this cycle:

Write a failing test (Red).
Write the minimum code to pass it (Green).
Refactor the code (Refactor).

TDD not only ensures your code works, but it also forces clean API and logic design from the beginning.

🤝 How Do DDD and TDD Complement Each Other?

DDD helps define what needs to be built and how to model it.
TDD ensures what is built is correct, testable, and maintainable.

With DDD, you design a rich domain model; with TDD, you continuously validate its expected behavior.

🛠️ Example: Changing a User's Name in NestJS using DDD + TDD

Step 1: Write the Test First (TDD)

// change-user-name.use-case.spec.ts

describe('ChangeUserNameUseCase', () => {
  it('should change the user name', async () => {
    const user = new User('1', 'John', 'john@example.com');
    const userRepository = {
      findById: jest.fn().mockResolvedValue(user),
      save: jest.fn(),
    };

    const useCase = new ChangeUserNameUseCase(userRepository);
    await useCase.execute('1', 'Jane');

    expect(user.name).toBe('Jane');
    expect(userRepository.save).toHaveBeenCalledWith(user);
  });
});

Step 2: Domain Logic with DDD

// user.entity.ts
export class User {
  constructor(
    public readonly id: string,
    public name: string,
    public readonly email: string
  ) {}

  changeName(newName: string) {
    if (!newName) throw new Error('Name cannot be empty');
    this.name = newName;
  }
}

Step 3: Application Layer Use Case

// change-user-name.use-case.ts

export class ChangeUserNameUseCase {
  constructor(private readonly userRepository: UserRepository) {}

  async execute(userId: string, newName: string) {
    const user = await this.userRepository.findById(userId);
    user.changeName(newName);
    await this.userRepository.save(user);
  }
}

🧹 Benefits of Combining DDD + TDD

Testable domain models from day one.
Better interface design thanks to the "test-first" approach.
High cohesion in business logic.
Low coupling between layers (presentation, application, domain, infrastructure).

🧼 Best Practices

✅ Use interfaces in repositories to decouple infrastructure from domain.
✅ Keep Value Objects immutable.
✅ Use case tests are more valuable than controller tests.
✅ Avoid domain logic in controllers: delegate to use cases.
✅ If a business rule changes, only the aggregate should be updated.

🏁 Conclusion

Adopting DDD to model your domain properly and using TDD to continuously validate its behavior not only improves code quality but also makes your app more scalable and maintainable. In NestJS, this combination is natural thanks to its modular architecture and built-in testing support.

Building a complex or critical product? Then DDD + TDD isn't optional it's essential.