Forem: Fredy Daniel Flores Lemus

From On-Premise Monolith to Scalable AWS Architecture: The Ticket Sales Case Study

Fredy Daniel Flores Lemus — Thu, 15 Jan 2026 20:14:41 +0000

The Problem Statement

Imagine the following scenario: a ticket sales application residing on a physical server (On-premise). Currently, the application is a monolith written in Node.js; it handles persistence in a MySQL database hosted on the same server, and stores static files (like event posters) directly on the local hard drive.

This architecture faces critical issues when tickets for a famous artis go on sale: the server crashes due to traffic, the database gets locked, and images load extremely slowly.

To address these root problems, the decision is made to migrate the application to AWS. This is where architecture planning begins, based on the following functional requirements:

High Availability (HA): If a server or zone fails, the app must continue operating without interruption.
Scalability: The system must handle user load and absorb traffic spikes during major events on demand.
Persistence: Transaction integrity is vital; no sale can be lost.
Security: The database must be protected and isolated from public internet access.

The Challenge

We need structure the solution by addressing four fundamental pillars:

Compute: Where do we run the application and how do we manage traffic?
Database: Which service do we use for MySQL and how do we optimize reads without saturating the system?
Static Storage: How do we serve poster images to ensure fast loading?
Network & Security: How do we organize the network (VPC) to protect data while allowing user access to the web?

The Architecture Proposal

For the compute layer, we can run the application on EC2 instances managed by an Auto Scaling Group. This allows us to scale horizontally on demand to handle traffic spikes. In front, we will place a Load Balancer (ALB) to distribute requests among instances, which will be spread across differente Availability Zones (AZs) to ensure high availability.

For MySQL, we will use the managed service Amazon RDS. To optimize performance, we will evaluate two strategies: using Read Replicas or implementing Amazon ElastiCache (we will define the best option later).

Static Content (poster images) will be migrated to a S3 bucket, utilizing Amazon CloudFront as a CDN to cache content and drastically reduce load times globally.

Finally, for Network Security, we will implement a three-tier architecture within the VPC:

The Load Balancer (our entry point) will reside in a public subnet.
Both the application instances and the database will be located in private subnets.
We will use Security Groups to stricly restric access between layers.

Deep Dive: Distributed Systems Challenges

The architecture above is solid and meets the infrastructure requirements. However, moving from a monolith to a distributed environment exposes our design to two critical logical problems:

1. The User Session

The original application stored the session in the server's RAM. In the new architecture, using the combination of Auto Scaling + Loab Balancer means that if the balancer routes us to different instance than the one we logged into, we lose the state, resulting in a terrible user experience (unexpected logout).

How do we solve this? We convert the application to be stateless. Instead of storing the session locally, we externalize it to Amazon ElastiCache. Beign an in-memory database, it offers sub-millisecond latency and ensures that even if the user changes instances, their session reamins centrally available.

2. Data Consistency (Race Condition)

Here we revisit the debate between using Read Replicas or ElastiCache. Image User A buys a ticket. Milliseconds later, User B checks that same seat. If we use Read Replicas, there is a small delay (replication lag) before User A's purchase is reflected in all copies. This could lead User B to attempt purchasing an already sold seat, causing an error or, worse, overbooking.

How do we handle immediate availability without saturating the database? The ideal solution is ElastiCache (Redis). Read Replicas are not ideal for real-time stock control due to the aforemetioned lag. Instead, Redis allow us to leverage its automicity. Since Redis is single-threated (processes operations one by one), it acts as a perfect control mechanism: if multiple purchase requests for the same seat arrive simultaneously, Redis "queues" them and processes them sequentially, allowing only the first transaction to succeed. This not only solves the race condition but also offloads read traffic from the main database.

Conclusion

Migrating from an on-premises environemnt to the cloud isn't just about moving servers (Lift & Shift); it's about rethinking how our application handles state and concurrency.

By integrating Amazon ElastiCache (Redis) into our architecture, we didn't just gain speed in reads-we solved two of the most complex problems in distributed systems: session management in stateless applications and data integrity during race conditions.

With this architecture, we've moved from a server that collapses under the demand of a famous artist to an elastic, robust infrastructure ready to scale automatically according to demand.

Beginner’s Guide to Kubernetes Architecture: How It All Works

Fredy Daniel Flores Lemus — Thu, 08 May 2025 23:17:28 +0000

Getting started with Kubernetes isn't easy, but a good first step is understanding its architecture at a high level. In this post, we'll walk through the different components that make Kubernetes work.

Nodes

First, Kubernetes has two types of nodes: control plane nodes (formerly called master nodes) and worker nodes. The control plane nodes are responsible for running the components that handle the orchestration of the entire cluster. These nodes manage the desired state, schedule workloads, and monitor the overall health of the system.

On the other hand, we have worker nodes, which are responsible for hosting and running applications inside containers.

The control plane nodes host the following components:

etcd
kube-scheduler
controller-Manager
kube-apiserver

The worker nodes include:

kubelet
kube-proxy
Container runtime

We'll take a closer look at each of these components next.

etcd

Starting with etcd, it is a distributed, reliable key-value store that is simple, secure, and fast.

In the context of Kubernetes, etcd is used to store the state of the cluster. It contains all the information about the resources that have been created, such as pods, services, deployments, and more.

When you run a kubectl get command, the request goes through the Kubernetes API server, which retrieves the necessary data from etcd, where the cluster state is stored.

kube-apiserver

The kube-apiserver is the central component of the control plane and serves as the primary interface to the Kubernetes cluster. All communication—whether from internal components or external users—goes through the API server.

Whether you use the kubectl CLI or send an HTTP request to the Kubernetes API, both are handled by the kube-apiserver, which acts as the entry point to the cluster and validates and processes all API requests.

controller-manager

The controller-manager runs a set of controllers that constantly observe the current state of the cluster and make the necessary changes to ensure it matches the desired state defined in the configuration.

For example, the Node Controller monitors the status of nodes, and the Replication Controller ensures that the desired number of pod replicas are running—if a pod dies, it automatically creates a new one.

kube-scheduler

The kube-scheduler is responsible for deciding which pod should run on which node. It's important to note that the scheduler doesn't actually place the pod on the node—it only assigns the pod to a suitable node based on resource availability, scheduling policies, and criteria.

kubelet

On the worker node side, we have the kubelet. This component is responsible for registering the node with the Kubernetes cluster and enabling communication between the node and the control plane.

It is also responsible for instructing the container runtime to pull the required image, run the container inside a pod, and monitor its state.

kube-proxy

Within a Kubernetes cluster, every pod can communicate with other pods thanks to the underlying pod network. A pod can reach another pod using its IP address, but this is not a reliable approach since pod IPs can change over time.

To solve this, Kubernetes introduces Services, which provide stable networking endpoints for accessing pods. However, Services don't exist within the pod network themselves—they require a mechanism to route traffic. That's where kube-proxy comes in.

kube-proxy is a network component that runs on each node. Based on the configured Services, it creates the necessary networking rules to forward traffic.

So, when a pod tries to reach another pod through a Service, kube-proxy handles the traffic routing under the hood—forwarding it from the Service's virtual IP to the correct pod's IP address.

Container Runtime

Finally, we have the container runtime. This component is responsible for running our applications as containers inside pods. The most commonly used container runtime in Kubernetes is containerd.

This is just the beginning of your journey into the world of Kubernetes. There's a lot more to learn, but remember—one step at a time is the best way forward.

my LinkedIn

Cómo configurar un Path en API Gateway con AWS SAM sin Lambda Proxy Integration

Fredy Daniel Flores Lemus — Fri, 24 Jan 2025 03:20:38 +0000

¿Sabías que con API Gateway puedes manejar solicitudes HTTP sin necesidad de preocuparte por servidores? En arquitecturas serverless, este servicio no solo expone tus endpoints, sino que también transforma y controla cómo llegan los datos a tu backend. En este tutorial, te enseñaré cómo llevarlo al siguiente nivel configurando integraciones personalizadas con OpenAPI.

¿Qué es Lambda Proxy Integration y cuándo evitarlo?

Cuando utilizamos AWS SAM para definir nuestra arquitectura serverless, la integración predeterminada entre Lambda y API Gateway es Lambda Proxy Integration. Esto significa que toda la solicitud HTTP (headers, body, query parameters) se pasa directamente como un evento JSON a la función Lambda.

Aunque este enfoque es conveniente, no siempre es ideal. Si necesitas transformar las solicitudes o conectarte a otros servicios directamente desde API Gateway, una integración personalizada es la mejor opción.

1. Definiendo la función Lambda

Comencemos creando nuestra función Lambda en el template de AWS SAM. Configuraremos sus propiedades principales. Como queremos usar una integración personalizada, omitiremos la propiedad Events.

Resources:
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      Handler: app.lambdaHandler
      Runtime: nodejs18.x
      CodeUri: ./src/
      Timeout: 10

2. Definiendo el API Gateway

A continuación, configuraremos nuestro API Gateway manualmente para evitar el comportamiento por defecto de Lambda Proxy Integration. Utilizaremos la propiedad DefinitionBody para definir la API en formato OpenAPI:

Resources:
  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      Name: MyCustomApi
      StageName: Prod
      DefinitionBody:
        openapi: 3.0.1
        info:
          title: My API
          version: 3.0.1
        paths:
          /example:

3. Configurando una integración personalizada

Ahora especificaremos la integración personalizada para nuestro path. Usaremos la extensión x-amazon-apigateway-integration:

paths:
  /example:
    get:
      x-amazon-apigateway-integration:
        type: "AWS" # Tipo de integración personalizada para servicios AWS
        uri: !Sub "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${MyFunction.Arn}/invocations" # URI de la Lambda
        httpMethod: "POST" # Método HTTP usado para invocar el backend
        passthroughBehavior: "WHEN_NO_MATCH" # Manejo de solicitudes sin modelo de mapeo definido
        requestTemplates: # Mapping template que nos ayuda a transformar la data para luego pasarla a nuestro backend
          application/json: |
            {
              "statusCode": 200
            }
        responses: # Tambien es posible mapear la respuesta que nos devuelve nuestro backend 
          default:
            statusCode: "200"

Conclusión

Con esta configuración, hemos configurado una integración personalizada que nos permite un control total sobre cómo se manejan las solicitudes y respuestas. Esto nos abre la puerta a arquitecturas más avanzadas y flexibles en AWS.

Si deseas profundizar más en las propiedades como passthroughBehavior o x-amazon-apigateway-integration, consulta la documentación oficial de AWS.

Si tienes dudas o comentarios, ¡déjalos abajo!

Estrategias Avanzadas: Cómo Implementar el Patrón Strategy en Tus Proyectos NestJS

Fredy Daniel Flores Lemus — Wed, 07 Feb 2024 22:36:20 +0000

LinkedIn
Github
Instagram

Uno de los patrones de diseño que más me llamó la atención al aprender TypeScript fue el Strategy Pattern. Aunque no es exclusivo de TypeScript, este patrón enriquece significativamente el código al promover la reusabilidad y el desacoplamiento.

En que consiste el patrón?

El patrón Strategy permite que una clase modifique el algoritmo o comportamiento que emplea durante la ejecución. Esto se logra definiendo una serie de algoritmos, cada uno encapsulado en su propia clase y siguiendo una interfaz común. De esta manera, se pueden intercambiar comportamientos de forma sencilla sin necesidad de alterar la clase que los implementa.

Un ejemplo en la vida real

Imagina una aplicación que envía notificaciones a los usuarios, con métodos de notificación variables, como correo electrónico, SMS o notificaciones push. En lugar de codificar un único método de envío, tu aplicación puede adoptar diferentes estrategias de notificación según las necesidades del momento. Esto se consigue mediante la implementación de una interfaz común para las estrategias de notificación, asegurando que tu aplicación sepa cómo enviarlas, independientemente del método elegido. Este enfoque permite cambiar los métodos de notificación fácilmente, sin afectar el funcionamiento general de la aplicación.
Al principio suena un poco confuso, así que mejor vayamos a un ejemplo con código

Código donde no se esta usando Strategy Pattern

En el contexto del ejemplo anterior y utilizando NestJS, consideremos el servicio NotificationService. Este servicio es responsable de enviar distintos tipos de notificaciones, seleccionando el método apropiado basado en un argumento pasado al método notify. La selección del método de notificación se realiza mediante condicionales, determinando si se envía un correo electrónico, un SMS o una notificación push según el caso:

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

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

El siguiente fragmento de código demuestra cómo utilizaríamos el NotificationService para enviar dos notificaciones, una por correo electrónico y otra por SMS. En este escenario, el método de notificación se decide en tiempo de ejecución, lo que muestra la flexibilidad de nuestro servicio para adaptarse a diferentes requisitos de notificación:

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

  async sendNotification() {
    const user = { email: 'user@example.com', phone: '+1234567890' };
    const message = 'This is a test message.';

    // Decidir el método en tiempo de ejecución
    await this.notificationService.notify(user, message, 'email');
    await this.notificationService.notify(user, message, 'sms');
  }
}

Este enfoque revela varias desventajas significativas que merecen atención:

Alto Acoplamiento: La selección y ejecución de los métodos de notificación están estrechamente integradas dentro de una sola clase o función, complicando la gestión y expansión del código. Este alto grado de acoplamiento reduce la flexibilidad y aumenta la complejidad del mantenimiento.
Violación del Principio de Abierto/Cerrado (OCP): Incorporar un nuevo método de notificación implica modificar la clase NotificationService directamente, añadiendo más condiciones. Esto contraviene el principio OCP, según el cual las entidades de software deben permitir su extensión sin necesidad de modificar su contenido existente, promoviendo así una mayor escalabilidad y mantenibilidad.
Complejidad en las Pruebas: Verificar el correcto funcionamiento de NotificationService se vuelve más arduo. Cada condición necesita ser probada individualmente para confirmar su operatividad, incrementando el esfuerzo y la complejidad de las pruebas."

Refactorizando el código

Para aplicar el patrón Strategy en nuestra refactorización del NotificationService, eliminaremos las condicionales de la clase. En su lugar, modificaremos la clase para que acepte un objeto a través de su constructor. Este objeto debe adherirse a una interfaz específica que incluya un método send. Este método será responsable de ejecutar la lógica de envío para el tipo de notificación correspondiente, permitiendo así que NotificationService delegue la responsabilidad de enviar la notificación, desacoplando el servicio de los detalles de implementación específicos de cada método de envío. De esta manera, NotificationService actúa meramente como un contexto para el envío de notificaciones, sin estar ligado a ningún método de envío en particular.

Empezaremos por definir la interfaz común que deben cumplir todos los objetos destinados a ser utilizados como estrategias de notificación. Esta interfaz garantiza que cualquier estrategia de notificación proporcione una implementación del método send, que es responsable de ejecutar la lógica específica de envío de notificaciones.

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

Tras definir la interfaz NotificationStrategy, procedemos a integrarla en nuestro NotificationService. Este cambio implica ajustar el constructor de NotificationService para aceptar un objeto que cumpla con NotificationStrategy. Al hacer esto, eliminamos la necesidad de condicionales dentro del servicio, delegando la responsabilidad de la lógica de envío al método send del objeto estrategia inyectado. La función notify del servicio, por lo tanto, se simplifica significativamente, limitándose a invocar send sobre la estrategia proporcionada.

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

@Injectable()
export class NotificationService {

  constructor(private strategy: NotificationStrategy) {}

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

Finalmente, para completar nuestra implementación del patrón de estrategia, creamos diferentes tipos de estrategias de notificación que NotificationService puede utilizar. Específicamente, desarrollaremos EmailNotificationStrategy y SmsNotificationStrategy, cada una con su respectivo método send. Estas estrategias concretas encapsulan la lógica específica para enviar notificaciones por correo electrónico y SMS, respectivamente.

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

@Injectable()
export class EmailNotificationStrategy implements NotificationStrategy {
  async send(user: User, message: string): Promise<void> {
    console.log(`Sending email to ${user.email}: ${message}`);
    // Aquí iría la lógica para enviar el correo electrónico
  }
}

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

@Injectable()
export class SmsNotificationStrategy implements NotificationStrategy {
  async send(user: User, message: string): Promise<void> {
    console.log(`Sending SMS to ${user.phone}: ${message}`);
    // Aquí iría la lógica para enviar el SMS
  }
}

Para maximizar la flexibilidad de NotificationService y permitir que cambie su estrategia de notificación en tiempo de ejecución, introducimos un método setter, setStrategy. Este método permite actualizar la estrategia de notificación que utiliza NotificationService, facilitando la adaptación a diferentes necesidades sin comprometer la instancia actual del servicio.

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

@Injectable()
export class NotificationService {

  constructor(private strategy: NotificationStrategy) {}

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

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

Con la implementación del patrón de estrategia en nuestro sistema de notificaciones, hemos demostrado cómo se puede aumentar significativamente la flexibilidad y la mantenibilidad del código. El siguiente ejemplo ilustra cómo AppService puede cambiar dinámicamente la estrategia de notificación de EmailNotificationStrategy a SmsNotificationStrategy, adaptándose a diferentes necesidades de notificación en tiempo de ejecución:

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

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

  async sendNotification() {
    const user = { email: 'user@example.com', phone: '+1234567890' };
    const message = 'This is a test message.';

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

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

Este enfoque no solo valida la versatilidad del patrón de estrategia, sino que también subraya su valor en la creación de aplicaciones modulares y extensibles. Al separar la lógica de notificación en estrategias concretas e intercambiables, facilitamos la adición de nuevos métodos de notificación y mejoramos la capacidad de prueba del sistema. Además, adherimos al principio de abierto/cerrado, permitiendo que nuestro sistema evolucione con cambios mínimos en el código existente."

"En resumen, la aplicación del patrón de estrategia en la gestión de notificaciones en TypeScript con NestJS demuestra cómo los principios de diseño de software pueden llevarse a la práctica para construir sistemas robustos, flexibles y mantenibles. La capacidad de cambiar estrategias en tiempo de ejecución no solo enriquece nuestra aplicación con flexibilidad operativa, sino que también destaca la importancia de un diseño de software pensado para el futuro.

Decoupling Code: Why Dependency Injection is a Must-Have in Programming?

Fredy Daniel Flores Lemus — Sun, 24 Sep 2023 15:35:01 +0000

https://linktr.ee/fredyflemus

Dependency Injection is a design pattern adopted by prominent frameworks such as Angular and NestJS. If you've ever worked with these frameworks, you've likely encountered Dependency Injection and grasped 'how' to implement it. But have you delved into the 'why' behind its incorporation into these frameworks?

Dependencies

We refer to a 'dependency' when, for instance, we have a class that requires an instance of another class to function – in other words, it depends on another class. For example:

class Engine {
    start() {
        return "Engine started";
    }
}

class Car {
    engine: Engine;

    constructor() {
        this.engine = new Engine();
    }

    drive() {
        return `Driving with ${this.engine.start()}`;
    }
}

// Use:
const myCar = new Car();
console.log(myCar.drive());  // Outputs: "Driving with Engine started"

In this example, the Car class has a dependency on the Engine class. When we create an instance of Car, we also need to create an instance of Engine for it to operate correctly. That is, Car relies on Engine to execute its drive() function.

However, by creating an instance of the Engine class within the Car class constructor, we are violating one of the main principles in software development: the Inversion of Control Principle.

Inversion of Control (IoC)

This principle dictates that if you want to achieve reusable code, you should write classes that don't instantiate their dependencies on their own. To accomplish this, I'll show you two different approaches:

Firstly, instead of creating the instance of the Engine class within the Car class as we did in the previous code, we'll pass the instance as an argument to the Car class constructor.

class Engine {
    start() {
        return "Engine started";
    }
}

class Car {
    engine: Engine

    constructor(engine) {
        this.engine = engine;
    }

    drive() {
        return `Driving with ${this.engine.start()}`;
    }
}

// Use:
const myEngine = new Engine();
const myCar = new Car(myEngine);
console.log(myCar.drive());  // Outputs: "Driving with Engine started"

The significant downside to this method is that we specifically have to pass an instance of the Engine class. This limitation is what the next approach aims to address. Instead of passing an explicit Engine instance, we'll define an interface. Then, whenever we create an instance of the Car class, all we need to provide is an object that fulfills that interface.

interface IEngine{
    start();
}

class Engine {
    start() {
        return "Engine started";
    }
}

class Car {
    engine: IEngine

    constructor(engine) {
        this.engine = engine;
    }

    drive() {
        return `Driving with ${this.engine.start()}`;
    }
}

// Use:
const myEngine = new Engine();
const myCar = new Car(myEngine);
console.log(myCar.drive());  // Outputs: "Driving with Engine started"

This approach shines because it isn't rigid about the kind of dependency it needs. It just looks for any object that fits the defined 'blueprint' or interface. For example, it simply asks for something with a start() method. In the real application, this might be our Engine class. But when testing, it allows us the flexibility to use a mock object, making unit tests smoother and more adaptable.

However, Inversion of Control isn't without its drawbacks. For instance, when you need to create an instance of a class that relies on another class, which in turn has its own dependencies, the code can become quite verbose as you find yourself having to instantiate each class manually.

const myBattery = new Battery();
const myEngine = new ElectricEngine(myBattery);
const myCar = new Car(myEngine);

In this usage example, you can see the step-by-step instantiation of each dependent class, which emphasizes the potential verbosity Inversion of Control can introduce.

Dependency Injection

Dependency injection is a technique that allows us to adhere to the Inversion of Control principle without the need to manually create different instances every time we require a service, component, or controller, which, in the end, are just classes in the previously mentioned frameworks.

Dependency Injection operates through something called the DI container (or Injector). This container is an object with various properties. To simplify the explanation, we'll focus on it holding two types of information.

List of classes and their dependencies
List of instances that I have created

The DI container acts like a registry, cataloging all the classes along with their associated dependencies. When it's time to instantiate a particular class, the Dependency Injection system takes charge. It automatically recognizes and creates all the necessary instances for the class's dependencies, ensuring everything is in place for smooth operation.

In summary, the DI Container follows this flow:

Upon startup, all classes are registered with the container.
The container analyzes and determines the dependencies for each class.
We request the container to instantiate a specific class for us.
The container autonomously creates all the necessary dependencies and provides us with the desired instance.
For efficiency, the container retains these instantiated dependencies, reusing them as required.

This last step, where the container retains and reuses instantiated dependencies, is commonly known as the Singleton pattern. In essence, it ensures that a class has just one instance and provides a point of access to that instance from any other part of the application.

Dependency Injection (DI) serves as a testament to the evolution of software design, placing emphasis on modular, decoupled, and testable code. Through the utilization of the DI container, we streamline the process of managing class dependencies, freeing developers from the intricacies of manual instantiation. As we embrace patterns like Singleton within this realm, we further enhance efficiency and maintainability. Ultimately, while Dependency Injection and its associated practices come with their learning curve, the benefits they offer in scalability, testability, and organization are undeniable. Embracing DI is not just about adhering to modern coding standards, but about paving the way for sustainable, adaptable software development.

Enhance Your Angular Mastery with the Router: Change Styles According to the Route

Fredy Daniel Flores Lemus — Wed, 20 Sep 2023 16:31:59 +0000

Twitter(X): https://twitter.com/fredydlemus
Instagram: https://www.instagram.com/fredydlemus/

If you're working with Angular's Router, you might have noticed that sometimes you want to customize the styles of your components based on the route you are on. Fortunately, Angular's Router offers us a tool to accomplish this: the routerLinkActive directive. In this article, I will guide you on how to leverage the routerLinkActive directive to breathe new life into your Angular applications and ensure each route possesses its distinct style. Let's get started!

Imagine we have a menu furnished with buttons that lead us to different routes, each showcasing distinct components beneath the menu upon clicking on them.

<div class="container">
  <div class="row">
    <div class="col-xs-12 col-sm-10 col-md-8 col-sm-offset-1 col-md-offset-2">
      <ul class="nav nav-tabs">
        <li role="presentation">
          <a routerLink="/">Home</a>
        </li>
        <li role="presentation">
          <a routerLink="products">Products</a>
        </li>
        <li role="presentation">
          <a routerLink="users">Users</a>
        </li>
      </ul>
    </div>
    <div class="row">
      <div class="col-xs-12 col-sm-10 col-md-8 col-sm-offset-1 col-md-offset-2">
        <router-outlet></router-outlet>
      </div>
    </div>
  </div>
</div>

Our goal is that when a button on the menu is clicked and redirects to the corresponding route, it also changes its style to indicate to the user that it's currently active. We can add or remove css classes to achieve this, and this is where the routerLinkActive directive comes into play.

The routerLinkActive directive enables us to detect whether the route linked in the element is active and specifies one or more CSS classes. This way, we can tailor the style of our elements based on the route we are on. This directive is extremely handy for providing visual feedback to the user regarding their current location within the application and making navigation more intuitive.

To utilize the routerLinkActive directive, you need to append it to the tag linked to the route you wish to detect. The "active" CSS class will be added to the tag when the linked route is active. If the user navigates to any other route, the "active" class will be removed.

...

<ul class="nav nav-tabs">
  <li role="presentation" routerLinkActive="active">
    <a routerLink="/">Home</a>
  </li>
  <li role="presentation" routerLinkActive="active">
    <a routerLink="products">Products</a>
  </li>
  <li role="presentation" routerLinkActive="active">
    <a routerLink="users">Users</a>
  </li>
</ul>

Here it is at “/”

Here it is at “/products”

Here it is at "/users"

However, we encounter a very common issue, where the 'Home' button always appears active, even when we are navigating through other routes. This happens because the 'Home' button is linked to the "/" route, and since our other routes also contain "/", Angular's Router recognizes them as active and activates the 'Home' button.

To rectify this problem, we can utilize the routerLinkActiveOptions feature of the routerLinkActive directive. This feature allows us to specify that Angular should consider the exact route when determining when to add or remove classes. This way, we can ensure that the 'Home' button will only be activated when we are on the root route, and not when we are on other routes that contain "/".

...

<ul class="nav nav-tabs">
  <li
    role="presentation"
    routerLinkActive="active"
    [routerLinkActiveOptions]="{exact: true}"
  >
    <a routerLink="/">Home</a>
  </li>
  <li role="presentation" routerLinkActive="active">
    <a routerLink="products">Products</a>
  </li>
  <li role="presentation" routerLinkActive="active">
    <a routerLink="users">Users</a>
  </li>
</ul>

I hope this post has been beneficial and you've gleaned some insights into utilizing the routerLinkActive directive in Angular. If you have any further questions or require additional assistance, please don't hesitate to let me know. Until next time!.

Effective Validations in NestJS: Flawless Software Development!

Fredy Daniel Flores Lemus — Tue, 19 Sep 2023 02:07:17 +0000

Twitter: https://twitter.com/fredydlemus
Instagram: https://www.instagram.com/fredydlemus/

Validating the data that enters your application through your APIs stands as a pivotal task in the role of a backend developer. This procedure not only fortifies the security of your application but also enhances the user experience and fosters a robust system. Implementing data validation can mitigate potential risks and ensure the smooth operation of your application, making it a critical aspect to consider for achieving overall excellence in backend development.

NestJS offers a sophisticated system that allows developers to conduct these validations both cleanly and elegantly. In this blog post, we will delve deep into the methods of implementing such validation processes. So, without further ado, let's embark on this insightful journey.

Implementing Validations on NestJS

To kickstart our journey, we will initiate a new project utilizing the NestJS CLI. We've decided to name this venture 'validation-behind-scenes'. This descriptive name not only encapsulates the essence of our project but also paves the way for a structured and insightful exploration into the world of NestJS validation processes.

nest new validation-behind-scenes

With our project accessible in a code editor, the next step is to head to our app.controller.ts file to craft a new POST route. This is where we will extract the body contained within the request, harboring the critical intention of validating that the incoming data adheres to our established criteria.

For this demonstration, I envision this route serving a pivotal role in facilitating the creation of new user accounts, thus playing a fundamental part in expanding our application's user base.

import { Controller, Post, Body } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Post()
  createUser(@Body() body: any) {}
}

In the preceding code snippet, it's evident that we are extracting the body content through the utilization of the @body decorator. Yet, it's crucial to note that we have not instituted any form of validation at this juncture. This lapse allows users to enter any data into our application indiscriminately, presenting a significant security risk. To fortify our application's defenses and initiate the implementation of validations, we are compelled to integrate two vital libraries into our project: 'class-transformer' and 'class-validator'. These libraries will serve as the cornerstone for establishing a secure and reliable validation process.

npm i --save class-validator class-transformer

Upon successful installation of these two pivotal libraries, we will advance to the next step of crafting a class referred to as a DTO, or Data Transfer Object. Within this specialized class, we undertake the task of delineating the specific properties and types that the body of our request should embody when we are in the process of creating a new user. This structured approach ensures a coherent and secure data handling procedure, paving the way for a smooth user creation process.

A DTO, or Data Transfer Object, is a simple object that is used to transfer data between software application layers. It does not contain any business logic but only attributes (data fields) with their respective getters and setters (methods to retrieve and update the values of these attributes).

Think of it as a container for data that needs to be moved from one place to another within a system. It helps to streamline and simplify the data transfer process, promoting cleaner code and easier maintenance.

Within the 'src' directory, I am set to establish a new folder denominated as 'dtos'. Nestled within this folder, I will forge a file dubbed 'create-user.dto.ts'. This file will house a class, which will bear the straightforward yet descriptive name 'CreateUserDTO'. This naming convention maintains clarity and directly reflects the purpose and functionality of the class, facilitating ease of understanding and future reference in the project.

import { IsEmail, IsString } from 'class-validator';

export class CreateUserDto {
  @IsEmail()
  email: string;

  @IsString()
  password: string;
}

As illustrated in the code, we import the decorators @IsEmail and @IsString from the 'class-validator' package. These decorators play a crucial role in specifying the validation criteria that the attributes within our DTO class must adhere to. They facilitate a streamlined validation process by enforcing the respective data types and formats that are expected, thus ensuring the integrity and security of the data handled within our application.

Now comes the pivotal moment where we synthesize all the elements to forge an effective validation mechanism. This endeavor entails two additional steps to fully realize our objective. Initially, we must incorporate the 'CreateUserDTO' into our controller, establishing it as the designated type for our body parameter. This action facilitates the meticulous screening of input data, aligning it with the criteria we have set forth in the DTO class.

import { Controller, Post, Body } from '@nestjs/common';
import { AppService } from './app.service';
import { CreateUserDto } from './dtos/create-user.dto';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Post()
  createUser(@Body() body: CreateUserDto) {}
}

As a result, it is imperative that the body of our request encapsulates an email that conforms to a valid email format, along with a password represented as a string. Failing to meet these criteria will trigger the system to return a '400 Bad Request' response to the user, indicating that the input does not satisfy the necessary conditions, and urging the user to amend the input accordingly

The culmination of our setup process involves one final, vital step. In our main.ts file, we need to implement a global pipe, aptly named 'ValidationPipe', which is sourced from the @nestjs/common package. This particular pipe functions as a facilitator, enabling the validations defined in our body to be actively executed, thereby ensuring that the input data adheres strictly to the established criteria.

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { ValidationPipe } from '@nestjs/common';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalPipes(
    new ValidationPipe({
      whitelist: true,
    }),
  );
  await app.listen(3000);
}
bootstrap();

We utilize the 'whitelist: true' setting as a means to guide NestJS in managing unexpected properties in the request body. Specifically, if the body contains properties beyond those stipulated in our DTO (like a 'name' field appearing alongside the 'email' and 'password' fields), this setting will ensure such surplus properties are automatically removed. Consequently, the validation process focuses solely on the parameters defined within our DTO, promoting a clean and streamlined data handling process that adheres to our established structure.

In this blog post, we have navigated through the intricacies of implementing validations within NestJS. Yet, one may wonder, how does specifying our body as our DTO facilitate achieving the desired validation? This underlying mechanism, which forms the crux of the validation process, warrants further exploration. Stay tuned, as we unravel this concept in greater depth in my forthcoming blog post. 😎

Protect Your Routes in Angular with Guards: Control Access and Exit of Routes Efficiently!

Fredy Daniel Flores Lemus — Sat, 16 Sep 2023 18:59:41 +0000

Looking for a way to manage access to your routes in Angular? Guards are the perfect tool for this task. In this blog post, I'll break down how Guards operate and how you can implement them to enhance your application's security. With Guards, you'll be able to specify who can access which routes and redirect unauthorized users to different sections of your application!

Creating Access Guard

To create a Guard in Angular, the first step is to establish a new service that will house the code for your Guard. In my case, I will name the service "AuthGuard".

It's crucial to note that, in order to utilize Guards in your application, you need to import the CanActivate class from the @angular/router module and apply it as an interface to the service you have created.

import { Injectable } from "@angular/core";
import { CanActivate } from "@angular/router";

@Injectable({ provideIn: "root" })
export class AuthGuard implements CanActive {
  canActivate(): boolean {}
}

When you create the Guard service in Angular, you must implement a method called canActivate() within it. This method is responsible for determining whether a user has access to a specific route or not. It should return a boolean value: true if the user can access the route and false otherwise.

Therefore, within the canActivate() method, you will need to write the necessary code to check if the user meets the access requirements for the particular route. For instance, you can check if the user is logged in, or if they have certain permissions or roles, etc.

If the user fulfills the access requirements, the canActivate() method should return true. Otherwise, you should redirect the user to another route and return false.

canActivate(route: ActivatedRouteSnapshot, state:
RouterStateSnapshot): Observable<boolean> | Promise<boolean> | boolean{
    return this.authService.isAuthenticated()
        .then(
            (authenticated: boolean) =>{
                if (authenticated){
                    return true;
                }else{
                    this.router.navigate(['/']);
                    return false;
                }
            }
        )
}

Implementing Access Guard

Lastly, to use a Guard on a specific route in Angular, you need to add the canActivate property to the configuration of the respective route. This property is an array that should include the service you created to implement the Guard.

const appRoutes: Routes = [
  {
    path: "servers",
    canActivate: [AuthGuard],
    component: ServersComponent,
  },
];

Exit Guard

With this, we will manage to have a protected route that executes a guard to confirm whether or not it is accessible, but often we also want to secure the exits of our routes.

Angular Guards also allow you to control whether a user can leave a route or not. This is useful, for instance, to prevent a user from closing a page in the middle of an important process without saving the changes.

To control the exit of a route in Angular, you need to create a Guard in a new service that implements the CanDeactivate interface. This interface is similar to CanActivate, but it triggers when a user attempts to leave a route instead of accessing it.

import { Injectable } from "@angular/core";
import {
  ActivatedRouteSnapshot,
  CanDeactivate,
  RouterStateSnapshot,
} from "@angular/router";
import { Observable } from "rxjs";

export interface CanComponentDeactivate {
  canDeactivate: () => Observable<boolean> | Promise<boolean> | boolean;
}

@Injectable({ provideIn: "root" })
export class CanDeactivateGuard
  implements CanDeactivate<CanComponentDeactivate>
{
  canDeactivate(component: CanComponentDeactivate) boolean{
    return component.canDeactivate();
  }
}

As you can see, the CanDeactivate method receives the component that is being rendered on the route as a parameter, and within this component, adds a method called canDeactivate() that contains the necessary code to verify if the user can leave the route or not. This method should return a boolean value: true if the user can exit the route and false otherwise.

Important! When you use a Guard that implements the CanDeactivate interface to control the exit of a route in Angular, you have the option to execute the access verification code either in the service implementing the Guard or in the component being rendered on the route.

The advantage of executing the access verification code in the component is that you can use the component's attributes to define your verification logic. This allows you to have greater control over the verification process and make it more specific for each component.

On the other hand, if you execute the access verification code in the service implementing the Guard, you can reuse the same code for several different components. This can be more efficient and maintainable, especially if you have multiple components that share the same access verification requirements.

In summary, the choice of where to execute the access verification code depends on your needs and preferences. You can do it in the component to have greater control over the process or in the service to reuse the code across various components.

canDeactivate(): boolean | Observable<boolean> | Promise<boolean>{
    if(!this.allowEdit){
        return true;
    }
    if((this.serverName !== this.server.name || this.serverStatus !== this.server.status) && !this.changesSaved){
        return confirm('Do you want to discard the changes?')
    }else{
        return true;
    }
}

Here you can see the canDeactivate method applied in the component that is rendered according to the route, which in my example returns true if the user has saved changes or, in the other case, returns a confirm dialog asking the user if they wish to leave the route without saving their changes.

Lastly, in the route configuration, add the canDeactivate property and pass the service you created to implement the Guard as an argument.

const appRoutes: Routes = [
  {
    path: "servers/edit",
    canDeactivate: [CanDeactivateGuard],
    component: EditServerComponent,
  },
];

In this post, we have learned how to secure our routes in Angular using Guards. We've explored how to use the CanActivate and CanDeactivate Guards to control access to and exit from routes, respectively. Additionally, we've discussed how to implement these Guards and how to apply them in route configurations.

With this knowledge, you now know how to protect your routes in Angular and can employ this technique to ensure that a route is accessed or left only under specific conditions. This will grant you greater control over the flow of your application and guarantee that certain areas are accessed or certain actions are carried out only if predefined requirements are met. I hope you enjoyed learning about this topic!

Basic concepts of Routing and Navigation in Web Applications with Angular

Fredy Daniel Flores Lemus — Wed, 13 Sep 2023 22:20:28 +0000

creating our router

When you develop an application with Angular, you are creating a SPA (Single Page Application). This means that the server sends us an empty HTML file, and then the content of the application is rendered through JavaScript. If you want to add different pages, you must use the Angular router to control which components are displayed according to the route in the browser.

To organize the paths and the different sections that will be shown in your application, start by establishing a constant in the file called app.module.ts, where you'll detail an array of different routes. Each item in this array indicates a specific path and the matching section or component that should appear when that path is visited in the browser. This method clearly lays out the navigation structure of your application, indicating what users will see at each step.

import { Routes } from "@angular/router";

const appRoutes: Routes = [
  { path: "", component: AppComponent },
  { path: "users", component: UsersComponent },
];

After you've created your list of paths or routes, bring it into the app.module.ts file. Here, you'll use a tool called RouterModule and a method named 'forRoot' to apply your list of routes as a guiding parameter. This step helps in effortlessly steering through your application, showing users the right sections or components depending on the path they are on at any given time.

import {
    Routes,
    RouterModule }
from "@angular/router";

const appRoutes: Routes = [
  { path: "", component: AppComponent },
  { path: "users", component: UsersComponent },
];

@NgModule({
    declarations: [
        AppComponent
    ],
    imports: [
        BrowserModule,
        RouterModule.forRoot(appRoutes)
    ],
    providers: [],
    bootstrap: [AppComponent]
});
export class AppModule {}

To get your routing system up and running, you need to insert a special instruction called the 'router-outlet directive' from Angular in the area where you'd like the matching components for each path to appear. This instruction looks at the current browser's path and alters the displayed component in that area based on the path setup you created earlier. In my case, I'll be adding this instruction into the main viewing area of my principal component, which is found in the file named app.component.html.

<router-outlet></router-outlet>

When someone visits the main address of your website (like "mydomain.com") without adding any extra path, they will see the main, or 'HomeComponent', section. If they specifically go to "mydomain.com/users", they will instead see the 'UsersComponent' section. Basically, the router looks at the part of the web address after the domain name to decide which part of your site to show them.

Navigating with our router

When you want to create clickable links that lead from one section to another on your website, use Angular's 'routerLink' feature instead of the regular 'href' attribute that you would use in an HTML tag. This feature lets users click through to different parts of the site without causing the whole page to reload each time, keeping the navigation smooth and fast.

<a routerLink="/users">Go to Users</a>

navigate through events

To wrap up this article, we'll explore how to move to a different section by triggering an event, like clicking a button. You'll need to set up an 'event binding' on the button, which is a way to connect the button click to a function that you've defined in the respective component's script file (so if your button is located in the 'home.component.html' file, the function it triggers would be found in the 'home.component.ts' file).

<button (click)="onNavigate()">
    Go to other page
</button>

In this file, you'll also need to incorporate the Router module within the component's constructor. Doing this allows you to make use of the Router's functions within the component itself.

After you've incorporated the Router module, you set up a function that activates when the event happens (like a click). In this function, you use the 'navigate' method from the Router module and specify the path you want to head to, formatted as an array. This setup allows you to steer the navigation in your web app smoothly, showing users different sections depending on which path they are on at that moment.

import { Routes } from "@angular/router";

...

export class AppComponent {
    constructor(private router: Router){}

    onNavigate(){
        this.router.navigate(['/servers']);
    }
}

We've come to the end, but really, we've only just scratched the surface when it comes to using Angular's router for navigation! There's so much more to explore and learn about managing your web application's navigation and showcasing different sections to users depending on the paths they visit. Keep an eye out for future posts where we'll dig even deeper into all the functionalities the Angular router can provide!

Thanks a lot for reading.