Construir una API serverless que consulte usuarios desde una base de datos requiere conectar varias piezas: API Gateway, Lambda y DynamoDB. Aquí se aborda paso a paso cómo refactorizar un proyecto básico para convertirlo en la primera función real de un CRUD, instalando el SDK de AWS, configurando el cliente de DynamoDB y resolviendo los errores más comunes al probar en local.
¿Cómo se estructura el proyecto CRUD serverless?
El proyecto parte de un diagrama claro [0:27]: el usuario envía peticiones HTTP a API Gateway, que se conecta a cuatro funciones Lambda. Estas lambdas se comunican con DynamoDB, una base de datos completamente serverless que encaja de forma natural porque toda la infraestructura se administra con Serverless Framework.
Para arrancar, se refactoriza el proyecto anterior:
- Se renombra la carpeta del proyecto de "Holamundo" a get users [1:25].
- En el archivo
serverless.yml, el service pasa a llamarse crud_serverless_users [1:48].
- El path del endpoint se actualiza a
/users [2:15].
- El provider sigue siendo Node.js y se mantiene el plugin serverless offline para pruebas locales.
¿Qué es el SDK de AWS y cómo se instala?
El SDK de AWS [2:48] es una librería que Amazon Web Services provee con múltiples sublibrerías para comunicarse con sus servicios, incluyendo DynamoDB. Se instala con un solo comando:
bash
npm install aws-sdk --save-dev
Una vez instalado, se importa en el código:
javascript
const aws = require('aws-sdk');
Pero no se necesita todo el SDK, solo el cliente de DynamoDB. Para eso se crea una instancia del Document Client [3:27], que simplifica las consultas y reduce la cantidad de código necesario para armar los parámetros:
javascript
const dynamodb = new aws.DynamoDB.DocumentClient();
¿Cómo se construyen los params para consultar DynamoDB?
Los params son el equivalente a una sentencia SQL adaptada a la sintaxis propietaria de DynamoDB [4:12]. Para la función get users, se consulta la documentación oficial buscando la sección de querying a table con el Document Client.
El objeto de parámetros queda así [5:42]:
javascript
const params = {
TableName: 'crud_serverless_users-table',
KeyConditionExpression: 'pk = :pk',
ExpressionAttributeValues: {
':pk': 1
}
};
Esto le indica a DynamoDB que debe obtener un usuario cuyo primary key sea igual a uno.
¿Cómo se ejecuta la consulta y se retorna la respuesta?
Se utiliza el método .query() del cliente, encadenando .promise() para manejar la naturaleza asíncrona de JavaScript [6:38]:
javascript
module.exports.getusers = (event, context) => {
dynamodb.query(params).promise()
.then(res => {
console.log(res);
return {
statusCode: 200,
body: JSON.stringify({ user: res })
};
});
};
La estructura de respuesta de Lambda exige siempre un statusCode y un body [7:05]. Respetar este formato es fundamental para que API Gateway procese correctamente la salida.
¿Cuáles son los errores más comunes al probar en local?
Al ejecutar serverless offline start [7:30] aparecen tres errores típicos que vale la pena conocer:
- Handler no encontrado: el archivo
serverless.yml referenciaba la función antigua hello en lugar de getusers. El handler debe coincidir exactamente con el nombre exportado en el archivo JavaScript [8:12].
- Invalid key condition: un símbolo
# sobrante en el KeyConditionExpression causaba un error de atributo. Al eliminarlo, la sintaxis queda correcta [8:55].
- Resource not found: DynamoDB no encuentra la tabla porque aún no se ha creado [9:20]. La base de datos todavía no existe ni en la nube ni en el entorno local.
Estos tres errores ilustran un flujo de depuración muy habitual en desarrollo serverless: verificar nombres de handlers, validar la sintaxis de las consultas y confirmar que los recursos existan antes de consumirlos.
Si has enfrentado alguno de estos errores o tienes otra forma de resolverlos, comparte tu experiencia en los comentarios.
