DEV Community: Alexis Polo

DynamoDB + Lambda en Python: la guía que hubiera querido encontrar

Alexis Polo — Tue, 24 Mar 2026 20:27:56 +0000

Hace un tiempo me tocó integrar DynamoDB con Lambda en un proyecto pequeño: un backend serverless para registrar eventos de usuario. Nada del otro mundo en papel, pero me demoré un poco más de lo esperado por eso esta guía cubre desde qué es DynamoDB hasta cómo exponerlo con API Gateway, con una sección de debugging real, optimización de costos, y un FAQ con las preguntas que más se repiten en el grupo de la comunidad.

¿Qué es DynamoDB y cuándo usarlo?

DynamoDB es el servicio de base de datos NoSQL administrado de AWS. "Administrado" significa que no hay servidor que configurar, parches que aplicar ni réplicas que coordinar. Tú defines la tabla, insertas datos, y AWS gestiona el resto: replicación multi-AZ, backups, escalabilidad.

A diferencia de una base relacional, en DynamoDB no defines un esquema estricto con columnas fijas. Cada ítem puede tener atributos distintos. Lo que sí es obligatorio al crear la tabla es definir la clave primaria, que puede ser:

Partition Key (PK) — clave simple, identifica de forma única cada ítem.
Partition Key + Sort Key (PK + SK) — clave compuesta, útil para agrupar múltiples ítems bajo una misma partición (ej: todos los pedidos de un usuario).

Modelo mental correcto
El diseño en DynamoDB gira alrededor del patrón de acceso, no del modelo de datos. Primero define cómo vas a consultar, luego diseña la tabla. Es al revés que en SQL, y eso confunde al principio.

¿Cuándo tiene sentido? Cuando el patrón de acceso es predecible, necesitas escala sin fricción, y especialmente cuando estás construyendo arquitecturas serverless. Ambos son stateless, ambos escalan automáticamente, y ninguno requiere conexiones persistentes.

⚠️ Cuándo NO usarlo
Si necesitas JOINs complejos, consultas ad-hoc frecuentes sobre múltiples atributos, o transacciones ACID complejas entre varias entidades, considera RDS o Aurora. DynamoDB brilla en acceso de clave-valor y patrones bien definidos, no en exploración libre de datos.

El flujo que vamos a construir

Vamos a construir dos versiones: la primera es solo Lambda + DynamoDB (ideal para aprender los conceptos sin ruido). La segunda agrega API Gateway para tener un endpoint HTTP real.

Paso a paso: desde cero hasta funcional

1. Crear la tabla en DynamoDB
Desde la consola de AWS → DynamoDB → Create table. Configuración mínima:

Table name: usuarios
Partition key: userId — tipo String
Capacity mode: On-demand (para pruebas y carga impredecible)

On-demand vs Provisionado
On-demand: pagas por cada unidad de lectura/escritura. Ideal para tráfico variable o proyectos nuevos donde no conoces el volumen.
Provisionado: defines RCUs y WCUs fijas. Más barato a escala predecible, pero si te quedas corto pagas con throttling.

2. Crear el rol IAM para Lambda
Este paso define qué puede hacer tu función Lambda. La regla de oro es least privilege: solo los permisos necesarios, nada más.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DynamoDBUsuariosAccess",
    "Effect": "Allow",
    "Action": [
      "dynamodb:PutItem",
      "dynamodb:GetItem",
      "dynamodb:UpdateItem",
      "dynamodb:DeleteItem",
      "dynamodb:Query"
    ],
    // ARN específico de tu tabla — OJO, NO uses "*"
    "Resource": "arn:aws:dynamodb:us-east-1:TU_ACCOUNT_ID:table/usuarios"
  }]
}

Pilas con este error clásico de seguridad
No uses "Resource": "*" en producción. El ARN lo encuentras en la consola de DynamoDB en la pestaña "Additional info" de la tabla. Cópialo desde ahí, no lo construyas a mano.

función Lambda — CRUD completo

Lambda → Create function → Python 3.12, asigna el rol del paso anterior. El código cubre las cuatro operaciones básicas con manejo de errores real:

import json
import os
import logging
import boto3
from botocore.exceptions import ClientError

logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)

# --- Inicializar fuera del handler ---
# Lambda reutiliza el entorno entre invocaciones calientes (warm start).
# Inicializar boto3 una sola vez evita el overhead de reconexión en cada
# llamada. En producción con alta concurrencia, esto reduce latencia real.
dynamodb = boto3.resource('dynamodb')
TABLE_NAME = os.environ.get('TABLE_NAME', 'usuarios')  # variable de entorno
table = dynamodb.Table(TABLE_NAME)


def lambda_handler(event, context):
    """
    Dispatcher principal. Acepta invocación directa (tests) y via API Gateway.
    El campo 'accion' determina qué función se ejecuta.
    """
    # Compatibilidad con API Gateway (body llega como string JSON)
    if 'httpMethod' in event or 'requestContext' in event:
        try:
            payload = json.loads(event.get('body') or '{}')
        except json.JSONDecodeError:
            return _resp(400, {'error': 'Body no es JSON válido'})
    else:
        payload = event  # invocación directa desde consola o test

    accion = payload.get('accion')
    logger.info("Acción: %s", accion)

    handlers = {
        'crear':    crear_usuario,
        'obtener':   obtener_usuario,
        'actualizar': actualizar_usuario,
        'eliminar':  eliminar_usuario,
    }

    fn = handlers.get(accion)
    if not fn:
        return _resp(400, {
            'error': f'Acción "{accion}" no reconocida',
            'acciones_validas': list(handlers.keys())
        })

    try:
        return fn(payload)
    except ClientError as e:
        code = e.response['Error']['Code']
        logger.error("ClientError [%s]: %s", code, e)
        return _resp(500, {'error': f'Error AWS: {code}'})
    except Exception as e:
        logger.error("Error inesperado", exc_info=True)
        return _resp(500, {'error': 'Error interno del servidor'})


# --- CREAR ---
def crear_usuario(payload):
    user_id = payload.get('userId')
    nombre  = payload.get('nombre')
    if not user_id or not nombre:
        return _resp(400, {'error': 'userId y nombre son campos requeridos'})

    item = {'userId': user_id, 'nombre': nombre}
    for campo in ['email', 'rol', 'activo']:
        if payload.get(campo) is not None:
            item[campo] = payload[campo]

    try:
        # attribute_not_exists(userId) lanza ConditionalCheckFailedException
        # si el ítem ya existe. Así evitamos sobrescrituras silenciosas.
        table.put_item(
            Item=item,
            ConditionExpression='attribute_not_exists(userId)'
        )
    except ClientError as e:
        if e.response['Error']['Code'] == 'ConditionalCheckFailedException':
            return _resp(409, {'error': f'El userId "{user_id}" ya existe'})
        raise  # re-lanza si es otro ClientError

    logger.info("Usuario creado: %s", user_id)
    return _resp(201, {'mensaje': f'Usuario {user_id} creado', 'item': item})


# --- OBTENER ---
def obtener_usuario(payload):
    user_id = payload.get('userId')
    if not user_id:
        return _resp(400, {'error': 'userId es requerido'})

    response = table.get_item(
        Key={'userId': user_id},
        # ProjectionExpression: solo los atributos necesarios.
        # Menos bytes transferidos = menos RCUs consumidas = menor costo.
        ProjectionExpression='userId, nombre, email, rol, activo'
    )
    usuario = response.get('Item')
    if not usuario:
        return _resp(404, {'error': f'Usuario "{user_id}" no encontrado'})
    return _resp(200, usuario)


# --- ACTUALIZAR ---
def actualizar_usuario(payload):
    user_id = payload.get('userId')
    # Extraer campos a actualizar, excluyendo metadatos del request
    campos = {
        k: v for k, v in payload.items()
        if k not in ('accion', 'userId')
    }

    if not user_id or not campos:
        return _resp(400, {'error': 'userId y al menos un campo son requeridos'})

    # ExpressionAttributeNames escapa palabras reservadas de DynamoDB
    # (name, status, role, count, etc.). Siempre usarlo en UpdateExpression.
    update_expr = 'SET ' + ', '.join([f'#{k} = :{k}' for k in campos])
    attr_names  = {f'#{k}': k for k in campos}
    attr_values = {f':{k}': v for k, v in campos.items()}

    try:
        table.update_item(
            Key={'userId': user_id},
            UpdateExpression=update_expr,
            ExpressionAttributeNames=attr_names,
            ExpressionAttributeValues=attr_values,
            # Falla si el usuario no existe — mejor que actualizar nada silenciosamente
            ConditionExpression='attribute_exists(userId)'
        )
    except ClientError as e:
        if e.response['Error']['Code'] == 'ConditionalCheckFailedException':
            return _resp(404, {'error': f'Usuario "{user_id}" no existe'})
        raise

    return _resp(200, {'mensaje': f'Usuario {user_id} actualizado', 'campos': list(campos.keys())})


# --- ELIMINAR ---
def eliminar_usuario(payload):
    user_id = payload.get('userId')
    if not user_id:
        return _resp(400, {'error': 'userId es requerido'})

    # delete_item no lanza error si el ítem no existe — es idempotente por diseño
    table.delete_item(Key={'userId': user_id})
    return _resp(200, {'mensaje': f'Usuario {user_id} eliminado'})


# --- HELPER ---
def _resp(status_code: int, body: dict) -> dict:
    """Formato de respuesta compatible con API Gateway Lambda Proxy."""
    return {
        'statusCode': status_code,
        'headers': {
            'Content-Type': 'application/json',
            'Access-Control-Allow-Origin': '*'  # ajustar a dominio específico en prod
        },
        'body': json.dumps(body, ensure_ascii=False, default=str)
    }

Probar la función — requests y respuestas reales

Lambda → pestaña Test → Create new event. Acá va cada operación con su request y la respuesta esperada. Si algo falla, la sección de debugging más abajo tiene el flujo de diagnóstico.

{
  "accion": "crear",
  "userId": "usr-001",
  "nombre": "Ana Suárez",
  "email": "ana@ejemplo.com",
  "rol": "admin",
  "activo": true
}

¿Qué es una API y cómo uso Lambda?

Alexis Polo — Wed, 11 Mar 2026 17:16:57 +0000

¿Qué es una API y cómo la conecto con Lambda?
Una guía para los que recién están entrando al mundo del backend y no quieren leer documentación de 40 páginas.

¿Qué es una API?
Mira, una API no es nada del otro mundo. Es simplemente la forma en que dos programas se comunican. Uno pregunta, el otro responde. Eso es todo.

Le decis a tu hermano: "Oye, anda donde la tía Marlene y tráeme un seco de pollo que me guardo." Él va, donde la tía Marlene y te trae la comida y tu ni cuenta te diste cómo llegó allá.
Una API es ese hermano — tu solo pedis, el hace el proceso y te trae lo que necesitás. así nada más.

Cuando abres una app del clima, esa app no tiene los datos del tiempo guardados en tu celular. Le pregunta a un servidor externo a través de una API y ese servidor le responde con la información. Todo eso pasa en milisegundos y tú nunca lo ves.
Las APIs que vamos a usar aquí son REST APIs. Básicamente funcionan sobre internet, se comunican con verbos simples (GET, POST, PUT, DELETE) y responden en JSON, que es un formato de texto fácil de leer tanto para humanos como para máquinas.

Los verbos HTTP: cómo le dices a la API qué quieres
Cada vez que haces una petición a una API, usas un verbo que indica la intención. Son cuatro y tienen mucho sentido:

GET: Trae información Ver la lista de usuarios.
POST: Crea algo nuevo Registrar un usuario.
PUT: Modifica algo que ya existe cómo cambiar el nombre de un usuario.
DELETE: Borra algo, cómo Eliminar una cuenta.

La URL que apuntas se llama endpoint. Por ejemplo {midominio.com}/usuarios es un endpoint. El verbo le dice qué hacer con ese recurso.

¿Qué es AWS Lambda?
Aquí está la parte que más me gusta explicar porque cuando la entiendes, cambia cómo ves el desarrollo.
Normalmente para tener código corriendo en internet necesitas un servidor. Una máquina prendida todo el día esperando peticiones, aunque nadie las haga. Eso cuesta plata y alguien tiene que mantenerlo.
Lambda cambia eso completamente. Tú escribes tu función, la subes a AWS, y te olvidas del servidor. Lambda la mantiene dormida hasta que llegue una petición. Cuando llega, despierta, corre tu código, responde, y vuelve a dormir. Pagas solo por los milisegundos que estuvo activa.
Una función Lambda luce así:

export const handler = async (event) => {
  const nombre = event.queryStringParameters?.nombre || 'Mundo';

  return {
    statusCode: 200,
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      mensaje: `Hola, ${nombre}!`
    })
  };
};

URL: https://{Id_Lambda}.lambda-url.us-west-2.on.aws/?nombre=Alexis

Resultado

Sin configurar puertos. Sin instalar nada. Solo la lógica que importa.

¿Y para qué API Gateway?

Lambda sola no tiene una URL pública. Nadie puede llegar a ella desde internet directamente. API Gateway es lo que le da esa puerta de entrada.

Tú defines las rutas, los métodos que acepta cada una, y a qué función Lambda apuntan. Así de simple:

GET    /usuarios         → función que lista usuarios
GET    /usuarios/{id}    → función que trae uno
POST   /usuarios         → función que crea uno
PUT    /usuarios/{id}    → función que lo actualiza
DELETE /usuarios/{id}    → función que lo borra

Código real: CRUD sin base de datos
Para no complicar todo desde el inicio, vamos a guardar los datos en memoria dentro de Lambda. No persisten para siempre, pero sirven perfecto para probar que todo funciona antes de conectar una base de datos real.

export const handler = async (event) => {
  const metodo = event.requestContext?.http?.method;

  //obtiene id desde la URL
  const path = event.rawPath; // /usuarios/1
  const partes = path.split('/');
  const id = partes[2];

  let usuarios = [
    { id: '1', nombre: 'Alexis' },
    { id: '2', nombre: 'Ana' },
    { id: '3', nombre: 'Luis' },
  ];

  const data = event.body ? JSON.parse(event.body) : {};

  // GET todos
  if (metodo === 'GET' && !id) {
    return res(usuarios);
  }

  // GET uno
  if (metodo === 'GET' && id) {
    const user = usuarios.find(u => u.id === id);
    return res(user || {});
  }

  // POST
  if (metodo === 'POST') {
    usuarios.push({ id: '4', ...data });
    return res({ mensaje: 'Usuario creado' });
  }

  // PUT
  if (metodo === 'PUT' && id) {
    return res({ mensaje: `Usuario ${id} actualizado` });
  }

  // DELETE
  if (metodo === 'DELETE' && id) {
    return res({ mensaje: `Usuario ${id} eliminado` });
  }

  return res({ mensaje: 'OK' });
};

const res = (body) => ({
  statusCode: 200,
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(body),
});

Subirlo a AWS en 5 pasos

Crear la función Lambda AWS Console → Lambda → Crear función. Nombre: api-usuarios, runtime: Node.js 24.x
Pegar el código y hacer Deploy Copia el código en el editor en línea, clic en Deploy. Listo.
Crear el API Gateway API Gateway → Crear API → HTTP API. Conectas tu Lambda como integración.
Definir las rutas Agregas las cinco rutas de arriba. Todas apuntan a la misma función.
Probar Te dan una URL tipo https://abc123.execute-api.us-east-1.amazonaws.com/dev. La pegas en Postman y empiezas a hacer peticiones.

Para Terminar
Con esto ya tienes una API funcionando en la nube, sin servidor propio, sin base de datos, y sin gastar nada relevante. El siguiente paso cuando estés cómodo con esto es reemplazar el array en memoria por DynamoDB, que es la base de datos serverless de AWS. La estructura del código no cambia mucho, solo agregas las llamadas al SDK.
Pero eso para el siguiente post xD

Llevando AWS a la Universidad de Guayaquil: así fue la experiencia

Alexis Polo — Mon, 09 Mar 2026 14:47:44 +0000

Hace unos días tuve el placer de dar una charla para estudiantes de la Facultad de Ciencias Matemáticas y Físicas de la carrera en Ing. En sistemas de la Universidad de Guayaquil. El evento fue parte del programa AWS Cloud Clubs UG y la verdad no esperaba la respuesta que tuvo.
El tema era sencillo: introducción a Cloud Computing y un recorrido por la consola de AWS. Algo que para mí ya es muy pero muy cotidiano, pero para muchos estudiantes era completamente nuevo.

Empecé desde cero, sin asumir nada. Primero expliqué qué es la nube con un ejemplo simple: antes para lanzar una app necesitabas comprar servidores físicos, instalarlos, configurar todo... y eso costaba tiempo y mucho dinero. Hoy simplemente alquilas esos recursos por internet y pagas solo lo que usas.
Después pasé sobre que AWS y los servicios fundamentales que realmente vas a usar para proyectos reales.

EC2 — un servidor virtual listo en minutos
S3 — almacenamiento casi ilimitado y muy barato
IAM — el guardián de la seguridad de tu cuenta
RDS — bases de datos gestionadas sin que tengas que preocuparte por backups
Lambda — mi favorito, código serverless que solo paga cuando se ejecuta

Y cerré con el tour en vivo por la consola. Ese fue el momento que más gustó.

Compartí pantalla y fui mostrando la consola real: cómo funciona la barra de búsqueda, cómo se cambia de región, cómo se ve IAM por dentro, dónde está la facturación y cómo configurar alertas para no llevarte sorpresas.
Esa parte práctica fue la que generó más preguntas. La gente quería saber cómo crear su primera cuenta, si de verdad es gratis al principio... y ahí vino uno de los momentos más interesantes de la noche.

Hablamos del Free Tier de AWS — la capa gratuita que te da hasta $200 en créditos cuando creas una cuenta nueva. Eso significa que puedes levantar servidores, crear bases de datos, guardar archivos en S3, todo sin pagar un centavo mientras estás aprendiendo. Muchos no sabían que eso existía.

Y no nos quedamos solo en teoría: varios estudiantes crearon su cuenta de AWS en ese momento, ahí mismo durante la charla. Verlos navegar la consola por primera vez, explorar los servicios, entender que ya tenían infraestructura cloud disponible para usar...

Ver a estudiantes genuinamente curiosos sobre cloud es algo que no tiene precio. Muchos no sabían que podían tener un servidor corriendo en minutos desde su laptop. Esa cara de "ah, ¿eso es todo?" cuando les muestro lo fácil que es empezar... vale cada minuto de preparación.
También reconfirmé algo que siempre digo: la mejor forma de aprender cloud es abrir la consola y construir algo. No hay curso ni charla que reemplace eso. (Adrenalina pura!!)

Gracias a la Facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil por la invitación, a AWS Cloud Clubs UG por la invitación y a todos los que se conectaron esa noche.

Si eres estudiante y quieres empezar con AWS, la puerta de entrada es simple: crea tu cuenta en aws.amazon.com, usa los créditos gratuitos, y explora.

Y si estás en Ecuador, búscanos — somos AWS User Group Ecuador y siempre hay algo nuevo que aprender juntos.

Eso es todo. Sin misterio, sin fórmulas mágicas. Solo ganas de compartir lo que uno sabe con gente que está empezando. Esto es lo aporte mas importante que podemos hacer como comunidad.

AWS Bootcamp Practitioner || AWS UG Ecuador

Alexis Polo — Wed, 30 Apr 2025 13:00:21 +0000

Como fundador y líder de AWS User Group Ecuador, me siento profundamente honrado y emocionado de compartir que más de 200 personas de Ecuador se han unido a nuestro AWS Bootcamp Cloud Practitioner.

Este bootcamp no solo representa una oportunidad de certificarse y fortalecer habilidades en cloud. Estamos viendo a estudiantes, profesionales y apasionados de la tecnología salir de su zona de confort, tomar acción y comprometerse con su desarrollo en un campo que define el futuro: la computación en la nube.

¿Qué estamos logrando juntos?
🌍 Crear una red nacional de aprendizaje colaborativo
💬 Espacios de mentoría y charlas técnicas abiertas
🧠 Preparación práctica y acompañamiento para la certificación
🤝 Una comunidad que apoya, comparte y celebra cada avance

Este esfuerzo es una muestra clara de que cuando la comunidad se une con un propósito claro, los resultados son poderosos. Ver el compromiso de cada participante me inspira y me recuerda por qué comenzamos este camino: para empoderar talento local y abrir puertas a nuevas oportunidades.

Quiero agradecer profundamente a nuestros speakers por su invaluable aporte a la comunidad y por compartir generosamente sus conocimientos y experiencias.

Hazel Saenz AWS HERO
Kevin Lupera
Andres Solorzano
Hernán Villavicencio
Gabriel Torres
Camila Vinza

¿Quieres unirte o apoyar esta iniciativa?
Visita www.awsugecuador.com o síguenos en nuestras redes sociales https://linktr.ee/awsecuador para más información.

AWS Bedrock

Alexis Polo — Mon, 18 Nov 2024 13:10:42 +0000

¿Qué es AWS Bedrock y para qué sirve?
Bueno, por dónde empezar... Si llevas un tiempo trabajando con AWS, seguro que en algún momento te topaste con el nombre Bedrock y dijiste "a ver, ¿esto qué es?". Yo también pasé por eso, y la verdad es que cuando lo empecé a entender me pareció bastante interesante, especialmente para los que no somos especialistas en Machine Learning pero queremos meter IA en nuestros proyectos sin que sea un dolor de cabeza.
En términos simples: Bedrock es el servicio de Amazon para consumir modelos de inteligencia artificial generativa sin tener que armar toda la infraestructura por tu cuenta. Sin servidores, sin entrenar modelos desde cero. Consumes lo que necesitas a través de una API y ya. Así de sencillo en concepto, aunque como todo en AWS, los detalles siempre tienen su cosa.

Lo que ofrece, y lo que más me llamó la atención
Lo primero que noté cuando entré a explorar Bedrock es que no estás limitado solo a los modelos de Amazon — que son la familia Titan, por si no los conoces. También puedes usar modelos de Anthropic, de AI21 Labs, Stability AI... hay opciones. Y eso importa, porque no todos los modelos sirven igual para todo. Si necesitas generar texto, tienes unas opciones. Si necesitas crear imágenes, otras. Resumir documentos, otras. La idea es que eliges según lo que realmente necesitas.
Hay también algo que se llama fine-tuning, que básicamente es ajustar el modelo con tus propios datos. Ojo, esto no es cosa de media tarde — requiere tener los datos bien organizados y tener claro qué resultado quieres obtener. No es imposible, pero tampoco lo recomendaría como primer paso si recién estás empezando con Bedrock.
Y al ser serverless, el escalado es automático. Si tu aplicación de repente recibe más carga, Bedrock responde solo. Para los que ya trabajamos con Lambda o con otros servicios serverless de AWS, esto no es novedad, pero siempre se agradece no tener que estar pendiente de eso.

¿Cómo se usa en la práctica?
Aquí no hay mucha ciencia, la verdad. El flujo es más o menos así:
Primero eliges el modelo que necesitas. Para texto, los modelos de Anthropic o Amazon Titan son un buen arranque. Para imágenes, Stability AI es la referencia. Después, si el modelo base no te da lo que necesitas, puedes hacer el ajuste con datos propios — ese fine-tuning que mencioné antes. Y finalmente lo conectas vía API desde tu aplicación.
Lo que sí vale recalcar es que Bedrock se integra bien con el resto del ecosistema AWS. Si ya tienes flujos armados con otros servicios, meterlo no implica rehacer todo. Y si además usas SageMaker para pipelines de ML, también hay integración disponible.

¿Dónde tiene sentido usarlo?
Esto es lo que más me preguntan en los meetups del User Group, la verdad — "oye, pero ¿dónde lo aplico yo?". Y bueno, depende mucho del proyecto, pero hay algunos casos donde Bedrock encaja bastante bien:

Chatbots y atención al cliente — para construir asistentes que respondan de forma coherente, que no suenen a que están leyendo un script.
Generación de contenido — descripciones de productos, borradores de campañas, ese tipo de cosas que consumen tiempo.
Análisis y resumen de documentos — cuando tienes un montón de texto y necesitas extraer lo importante sin leer todo manualmente. Esto es más útil de lo que parece.
Generación de imágenes — prototipos visuales, recursos gráficos a partir de texto. No reemplaza a un diseñador, pero para explorar ideas rápido funciona.

Al final del día, Bedrock no es la solución para todo ni pretende serlo. Pero si ya estás dentro del ecosistema AWS y quieres empezar a incorporar IA generativa en tus proyectos sin construir todo desde cero, es una opción que vale la pena revisar con calma.
Si tienes dudas o ya lo estás usando y quieres compartir tu experiencia, déjalo en los comentarios. En la comunidad siempre hay alguien que ya pasó por lo mismo. 👋