Antes de sumergirte en buenas prácticas avanzadas, necesitas entender el punto de partida: un proyecto base serverless construido con Serverless Framework, AWS Lambda, DynamoDB y API Gateway. Es la columna vertebral sobre la que vas a iterar en las siguientes clases, y conocerlo a fondo te ahorra dolores de cabeza después.

Este proyecto viene de un curso previo donde armamos un CRUD completo en la nube. Ahora lo vas a llevar al siguiente nivel.

¿Qué incluye el proyecto base serverless?

El repositorio reúne los componentes mínimos para operar un CRUD funcional en AWS sin levantar servidores.

Tienes cuatro funciones Lambda, una tabla en DynamoDB y un API Gateway que se gestiona automáticamente. Cada Lambda responde a una operación específica del CRUD:

• GetUsers: lectura de usuarios mediante método HTTP GET.
• CreateUsers: inserción mediante POST.
• UpdateUsers: modificación mediante PUT o PATCH.
• DeleteUsers: eliminación mediante DELETE.

Cada función está mapeada en el archivo serverless.yaml con su evento HTTP y su endpoint, que puede llevar un slash limpio o un parámetro tipo /{id} cuando necesitas identificar un recurso puntual.

¿Qué es un CRUD en serverless? Es una aplicación con cuatro operaciones básicas (Crear, Leer, Actualizar, Eliminar) donde cada una corre en una función Lambda independiente, sin servidores que administrar.

¿Cómo se conecta DynamoDB en este proyecto?

En la sección inferior del serverless.yaml defines DynamoDB como un recurso. La configuración es mínima: una tabla de usuarios con una primary key. Eso basta para que las cuatro Lambdas lean y escriban datos.

API Gateway, en cambio, no requiere configuración explícita. Serverless Framework lo aprovisiona por ti cuando detecta eventos HTTP en las funciones [01:50].

¿Cómo clonar y preparar el proyecto desde GitHub?

El repositorio está en la sección de recursos del curso. Lo clonas con la CLI de Git y lo abres en tu editor preferido, por ejemplo Visual Studio Code.

Un detalle importante: el repositorio no incluye node_modules ni package-lock.json. Si intentas desplegar sin instalar dependencias, el framework te lanza un error porque no encuentra los paquetes necesarios.

La solución es directa:

1. Clona el repositorio con git clone y la URL.
2. Entra a la carpeta del proyecto.
3. Ejecuta npm install para que Node descargue todo lo declarado en package.json.

Como las dependencias son pocas, la instalación toma apenas unos segundos. Después verás aparecer las carpetas node_modules, .serverless y el archivo package-lock.json, que son los que el framework necesita para operar de forma fluida.

¿Por qué no se sube node_modules al repositorio? Porque pesa mucho y se regenera con npm install. Subirlo ensucia el repo y ralentiza la colaboración.

¿Cómo desplegar el proyecto en AWS con Serverless Framework?

Con las dependencias listas, ejecutas sls deploy desde la terminal. El framework empieza a hablarle a AWS y crea un stack de CloudFormation que orquesta todos los recursos.

Mientras corre, en la consola de AWS puedes ver el stack en estado Creación en progreso, generando eventos por cada recurso que se va levantando. Aproximadamente tras 40 segundos comienza el upload de los archivos de cada Lambda [05:30].

Aquí entra una optimización clave: el empaquetamiento selectivo. Dentro del serverless.yaml, en la sección package > patterns, defines exactamente qué archivo handler sube cada función. Por ejemplo:

• GetUsers solo empaqueta GetUsersHandler.
• CreateUsers solo empaqueta CreateUsersHandler.
• Y así con las cuatro.

El resultado es que cada Lambda pesa muy poco, lo que mejora tiempos de arranque en frío y costos de transferencia.

¿Qué runtimes y servicios quedan activos tras el despliegue?

Cuando el stack termina, en la consola de Lambda aparecen las cuatro funciones desplegadas: tres con runtime de Node.js y una con Python. Todas conviven en el mismo ecosistema, lo que demuestra la flexibilidad de mezclar lenguajes en proyectos serverless.

¿Cómo probar los endpoints desplegados?

Una vez en la nube, cada función Lambda expone una URL pública vía API Gateway. La forma más rápida de validarlas es con curl desde la terminal.

Por ejemplo, para probar la lectura de un usuario:

bash curl https://tu-api-gateway.amazonaws.com/dev/users/1

La respuesta es un JSON con la estructura típica de DynamoDB: un objeto users, un count en cero y un scanned count en cero, indicando que la tabla está vacía pero responde correctamente.

Eso confirma tres cosas: el despliegue funciona, el stack de CloudFormation está sano y las Lambdas ya conversan con DynamoDB.

Cuéntame en los comentarios si ya habías trabajado con Serverless Framework o si esta es tu primera vez orquestando Lambdas y DynamoDB desde código.