Construir una función Lambda que consulte DynamoDB con Serverless Framework es el primer paso para montar un CRUD serverless completo. Aquí aprenderás a refactorizar un proyecto base, instalar el SDK de AWS y escribir tu primera query a una base de datos NoSQL, todo administrado desde un mismo archivo de configuración.

Cómo se conecta la arquitectura serverless del proyecto CRUD

El flujo es directo y vale la pena tenerlo claro antes de tocar código. El usuario envía peticiones HTTP a API Gateway, que enruta hacia cuatro funciones Lambda, y cada Lambda conversa con DynamoDB, una base de datos 100% serverless que encaja perfecto en este stack porque también la administras con Serverless Framework [01:00].

Y aquí viene lo interesante: toda la infraestructura vive bajo la misma herramienta. Eso reduce fricción y te deja un proyecto coherente de punta a punta.

¿Qué es DynamoDB? Es una base de datos NoSQL serverless de AWS que se integra de forma nativa con Lambda y se puede provisionar desde Serverless Framework sin manejar servidores.

Cómo refactorizar el proyecto base para crear la función getUsers

Partiendo del proyecto de la clase anterior, lo primero es darle nombres con sentido. Renombra la carpeta hello-world a getUsers, porque ahora la función traerá usuarios desde una base de datos [02:05].

Después abre tu serverless.yaml y ajusta tres puntos clave:

• Cambia el service a crud-serverless-users para reflejar el objetivo del proyecto.
• Mantén el provider con Node.js y conserva el plugin serverless-offline para pruebas locales.
• Renombra la función a getUsers y define el path como users.

Este paso parece cosmético, pero te ahorra dolores de cabeza cuando el proyecto crece y aparecen más Lambdas.

Cómo instalar e importar el AWS SDK para hablar con DynamoDB

Para que tu Lambda pueda comunicarse con DynamoDB necesitas el AWS SDK, una librería oficial de Amazon Web Services que agrupa sublibrerías para interactuar con sus servicios [03:40].

Instálalo con npm:

bash npm install aws-sdk --save-dev

Luego, dentro de tu archivo handler.js, importa el SDK y crea un cliente específico para DynamoDB:

javascript const AWS = require('aws-sdk'); const dynamoDB = new AWS.DynamoDB.DocumentClient();

El truco está en usar DocumentClient en lugar del cliente base. Este cliente simplifica la sintaxis de los params y te ahorra escribir tipados de DynamoDB a mano.

¿Qué hace el DocumentClient de DynamoDB? Es un cliente que abstrae los tipos nativos de DynamoDB y te permite trabajar con objetos JavaScript planos al hacer queries, put y get.

Cómo construir el objeto params para hacer una query a DynamoDB

Un params en DynamoDB es el equivalente a una sentencia SQL, pero con la sintaxis propia que define AWS. Pueden volverse complejos, así que apoyarte en la documentación oficial es parte natural del trabajo del desarrollador serverless [05:30].

Buscando DynamoDB JavaScript SDK query encuentras el ejemplo para DocumentClient. A partir de ahí, adapta el objeto a tu caso:

javascript const params = { TableName: 'crud-serverless-users-table', KeyConditionExpression: 'pk = :pk', ExpressionAttributeValues: { ':pk': 1 } };

Lo que estás diciendo en lenguaje plano es: trae el usuario cuya primary key sea igual a 1. Conviene que el TableName siga el mismo nombre del service con un sufijo -table para mantener orden.

Cómo ejecutar la query y devolver la respuesta desde Lambda

DynamoDB expone el método .query() y, como es asíncrono, lo conviertes en promesa con .promise(). La respuesta debe seguir el formato que API Gateway espera de Lambda: un objeto con statusCode y body.

javascript module.exports.getUsers = (event, context) => { return dynamoDB.query(params).promise().then(res => ({ statusCode: 200, body: JSON.stringify({ user: res }) })); };

Fíjate que el body siempre va serializado como string. Es uno de los detalles que más errores genera al iniciar.

Qué errores aparecen al probar la Lambda en local con serverless offline

Al ejecutar serverless offline start y consumir el endpoint dev/users, aparecen tres errores muy típicos. Vale la pena reconocerlos porque te los vas a topar más de una vez [10:15].

• Handler no encontrado: ocurre cuando el handler en serverless.yaml apunta a un nombre de función que ya no existe. La regla es simple: el handler debe ser archivo.nombreDeLaFuncion exactamente igual a como exportas la función.
• Invalid KeyConditionExpression: pasa cuando dejas un # antes del nombre del atributo sin definirlo en ExpressionAttributeNames. Quitar el numeral resuelve el error.
• Resource not found: la base de datos aún no existe. Lambda intenta consultar una tabla que no ha sido creada en DynamoDB.

¿Por qué falla mi Lambda con resource not found? Porque el código intenta consultar una tabla de DynamoDB que todavía no se ha provisionado. Necesitas crear la tabla antes de ejecutar la query.

Este último error es justamente la puerta al siguiente paso: provisionar la tabla de DynamoDB desde Serverless Framework y dejarla lista para recibir consultas.

¿Te has topado con alguno de estos errores antes? Cuéntame en los comentarios cuál te dio más pelea al configurar tu primera Lambda con DynamoDB.