Backend Serverless en AWS para Developers - Curso Práctico

En esta clase se presentan los tres servicios principales que formarán la base del backend serverless del sistema de tickets:

API Gateway, que expondrá la API REST y gestionará los seis endpoints del CRUD:

• POST /v1/tickets

• GET /v1/tickets

• GET /v1/tickets/{id}

• PUT /v1/tickets/{id}

• PATCH /v1/tickets/{id}

• DELETE /v1/tickets/{id}

AWS Lambda, donde se ejecutará el código JavaScript bajo el runtime Node.js. La función lambda cuenta con su rol IAM asociado para integrarse de forma segura con otros servicios de AWS.

DynamoDB, la base de datos NoSQL que almacenará los tickets.

La clase explica cómo estos servicios se conectan entre sí para construir nuestro sistema.

En esta clase se introduce el enfoque API-First, una forma profesional de construir servicios donde el diseño de la API se define antes de escribir código. Para ello utilizamos OpenAPI, el estándar más adoptado en la industria para describir APIs REST mediante un contrato claro y versionable.

Se revisa el contrato OpenAPI del sistema de tickets, incluyendo los endpoints, modelos de datos (schemas) y ejemplos de solicitudes. Este contrato funciona como hoja de ruta para todo el proyecto: permite acordar la estructura de la API, validar la comunicación entre servicios y asegurar consistencia durante el desarrollo.

También se utiliza Swagger Editor para visualizar y explorar el contrato de forma interactiva.

Recursos recomendados:

• OpenAPI Specification: https://spec.openapis.org/oas/latest.html

• Swagger Editor (online): https://editor.swagger.io/

En esta clase se analiza la entidad Ticket, el recurso central de todo el sistema. Se revisa su modelo de datos según el contrato OpenAPI: campos obligatorios, valores permitidos, tipos de datos y reglas que definen cómo se representa un ticket dentro de la API. Este esquema es la base para validar solicitudes, diseñar las funciones Lambda y estructurar correctamente la tabla DynamoDB.

También se muestra cómo este modelo está documentado en OpenAPI y cómo utilizar esa definición como referencia técnica durante el desarrollo.
Se dejan enlaces al blog donde se explica paso a paso la construcción del contrato OpenAPI utilizado en este proyecto.

Actualización de AWS: Se ha actualizado la interfaz de CloudWatch.
Durante el video se verá que hay una sección llamada "Log groups". Ahora en la interfaz se verá como "Log management". Esto no cambia cómo funcionan los logs, solo cambia la forma de navegar la consola.

Desarrollamos la operación de POST /tickets en la función lambda el cual registra un objeto ticket en la tabla de tickets en DynamoDB.

En esta sección del curso realizamos el empaquetado manual del código para desplegarlo en AWS Lambda.

Este proceso no es específico de AWS, sino una práctica en backend serverless cuando no se usa un framework (SAM, Serverless Framework, CDK). Este método es educativo, más adelante existen alternativas más profesionales: CI/CD, AWS SAM, CDK, GitHubActions.

1. Uso del comando zip:

• En el curso usamos el comando zip el cual: Genera un archivo .zip con el código fuente y las dependencias.

• Está disponible por defecto en Linux y macOS

• No viene instalado en Windows clásico

Si usas Windows, debes:

• Usar WSL (Windows Subsystem for Linux)

• Usar una máquina Linux / macOS

3. Sobre el archivo deploy.sh

Requiere:

• Bash

• AWS CLI configurado

npm install @aws-sdk/client-dynamodb @aws-sdk/lib-dynamodb

1. Desarrollamos en local nuestra aplicación Node.js

2. Empaquetamos el código generando un archivo .zip llamado deployment-package.

3 Desplegamos manualmente el deployment package hacia AWS Lambda con el código de la función empaquetada en forma de zip.

Existen formas más avanzadas de hacerlo. En este tutorial pretendo explicar desde la forma más sencilla, para después ir avanzando y viendo mejores opciones.

Vemos otras formas de desplegar nuestro código en AWS Lambda. Primero usamos AWS CLI con el comando: update-function-code y luego automatizamos el proceso usando un shell script deploy.sh

Clase en construcción

Clase en construcción

Clase en construcción

En este video configuramos y usamos environment variables en AWS Lambda para evitar hardcodear valores críticos (por ejemplo, nombre de tabla DynamoDB, región, etc.). En este video se explica por qué esto es esencial para manejar ambientes (dev/stage/prod) y para mantener el código limpio y portable.

Creamos la base del domain: definimos la entidad Ticket y enums para asegurar tipos (por ejemplo, status, prioridad o tipo). Esto mejora consistencia, reduce errores y prepara el proyecto para validaciones, reglas de negocio y refactors más avanzados.

Definimos un DTO (Data Transfer Object) para modelar y transportar de forma clara los datos que llegan por HTTP con respecto a la creación de un Ticket. Esto separa "lo que llega del cliente" de "lo que usa el dominio" y de lo que se persiste en la base de datos. Además prepara el camino para validación y manejo de errores consistente.

Creamos una clase base HttpError para representar errores de manera controlada: statusCode, message y metadata útil. Esto permite que el handler responda con códigos HTTP correctos (400, 404, 500, etc.) sin mezclar lógica de negocio con formato de respuesta.

Implementamos un router simple para manejar rutas y métodos HTTP sin convertir el handler en un bloque gigante de if/else. Este router actúa como el "controlador" de entradas, permitiendo que cada endpoint se dirija a la lógica correcta de forma ordenada.

Creamos TicketService y movemos allí la lógica de negocio: reglas, construcción del ticket, valores por defecto y decisiones del dominio. Aquí se introduce el patrón Service Layer: el service no debería saber de HTTP, solo del caso de uso.

Refactorizamos el handler para que se quede únicamente con la responsabilidad de transport layer: recibir el evento HTTP, parsear, delegar al service y construir la respuesta. El handler deja de hacer negocio y empieza a actuar como un entrypoint limpio y mantenible.

En este video explicamos el "por qué" arquitectónico del cambio: Single Responsability Principle + Service Layer como criterio para decidir qué código va en el handler y qué va en el service.

En este video introducimos el Repository Pattern para desacoplar la lógica de negocio del acceso a datos. Creamos TicketRepository y el service deja de depender del SDK directamente y pasa a depender del Repository.

Terminamos el desacoplamiento: refactorizamos TicketService para consumir TicketRepository. Con esto, el service queda enfocado solo en negocio y el acceso a DynamoDB queda encapsulado en la capa repository. Esta base deja el backend listo para escalar a un sistema más profesional.

Antes de continuar, quiero pedirte un feedback breve.

Este curso busca ayudarte a aprender AWS desde una perspectiva práctica de backend developer.

Como el formato gratuito de Udemy tiene una duración limitada, estoy evaluando qué temas desarrollar en próximos contenidos para seguir profundizando con más práctica, mejores prácticas, arquitectura, seguridad, autenticación, despliegue y observabilidad.

Preparé una encuesta breve y opcional (toma menos de 3 minutos) para conocer tu experiencia con el curso y entender qué contenidos te serían más útiles después.

Puedes responderla aquí:

https://docs.google.com/forms/d/e/1FAIpQLScYTXZ-vK2yKhn_nnFpFNfFSzAu4fORyXctAJo4Naoz9iHRtg/viewform?usp=header

Tu feedback me ayudará a mejorar este curso y a crear contenido más útil con el mismo estilo práctico!